Engineers who come onsite to interview with Lob often have good things to say about the experience. We get a surprisingly consistent signal from candidates whether they accept, decline, or don’t receive offers from us:
When I hear comments like this, it tells me that we’re doing something right. It takes real commitment to take a whole day off to interview at a new company. In this post, I’ll explain how we’ve modernized our interview process to honor that commitment while getting the right signals we need to make a principled hiring decision.
We are specifically looking for two qualities in our engineering hires. We designed our whole process around finding ways to measure technical judgment and communication.
Every engineer at Lob is expected to interpret business needs into maintainable, scalable code. Lobsters need the ability to efficiently make farsighted technical decisions in a real-world context with difficult trade-offs.
Engineers with strong technical judgment:
The best people have an intuition for sizing up risk and complexity, and can run experiments to answer the most important questions before moving forward with a plan.*
Technical judgment can be developed. We help junior engineers grow by giving them ownership over projects with complexity appropriate to their experience and professional interests. Since problem-solving skills are something you develop with practice, investing in junior engineers makes them capable of taking on bigger and bigger projects over time.
*Please note: your ability to implement Dijkstra’s Algorithm from memory tells us zilch about your technical judgement.
We are bringing a technology-first, data-driven approach to a sleepy industry, which means the opportunities we’re exploring are original problems. Solving original problems takes seamless communication, teamwork, and trust. That’s why we value communication and collaboration as highly as we value technical judgment. It’s a foundational piece of our engineering culture.
Great communicators make complex ideas crystal clear, ask clarifying questions, and check in with you to see if you’re following them. They might use non-verbal communication such as diagramming to illustrate ideas that are hard to understand when spoken out loud.
Great collaborators have a track record of going above and beyond to make past colleagues and teammates better.
Communication can be developed, too. I routinely give and receive feedback with engineers on presentation, meeting, and writing skills. I don’t really think you can teach people to want to help others and feel rewarded by doing so. But you can enable those who do—and so much the better if everyone on your team is intrinsically motivated to help each other.
This is our double bar. Candidates who are incredibly strong on one pole but who don’t measure up to our standards on the other aren’t a fit for our team. On the flip side, engineers at Lob get to work on a team where they can trust every one of their colleagues to make smart technical decisions and collaborate well.
Technical judgment, communication, and collaboration can’t be faked when you ground your interview in the real world. That’s why we base our interviews on real-world problems: problems we’ve faced and had to solve, and problems that you’ve solved at other companies.
To illustrate what I mean, here’s a peek at our current onsite interview process for senior software engineers:
Our coding challenges are based on real-world problems that we’ve dealt with at Lob. They prioritize practical problem-solving over algorithmic trivia.
Your interviewer walks through the problem with you, then makes him- or herself available to you as a resource for the duration of the interview. Got more questions? They’ll answer them (within reason). Prefer to pair program? You’ve got your partner right there in the room. This person is there to clarify the problem and help you think about it, not to grill and antagonize you.
This challenge is language and environment agnostic. You can use Google and Stack Overflow if you need to. The goal of this interview is to help us understand how you approach a well-scoped problem under normal, realistic conditions.
We code review everything we ship, so this interview simulates that.
A different interviewer who is familiar with the specific coding challenge you did will sit down with you, read through your code, and have a conversation with you about it.
Topics that might be covered here include stylistic choices, refactoring and testing, what you’d do if you had more time, what you’d change if you were writing production-grade code, and other things related to the software development lifecycle.
The most important meal of the day is on us. You’ll be accompanied by two or more Lobsters, whom you can get to know in an unstructured setting.
This isn’t an interview. It’s just delicious.
This interview is a chance for you to showcase your technical judgment by walking us through a difficult project you’ve worked on. It’s a free-form interview, and we’re not looking for any specific technical or business domain.
The goal of this interview is for us to get a sense of how you communicate, your technical depth, how you make decisions in a real-world setting, how you collaborate with engineers and non-technical stakeholders, and how you connect your work to the big picture.
(Insofar as algorithms and data structures have been important to your work, this is the place to talk about it: within the context of an actual problem.)
We’ll ask clarifying questions as needed. If you’ve ever participated in a technical project kickoff or design review you’ll feel right at home.
We’ve run into some weird engineering problems that have been both challenging and fun to think about. Our favorites become design interview questions.
We’ll frame the situation by describing what we were trying to solve when we ran into this problem, then brainstorm with you on coming up with some solutions to the problem. Your interviewer can answer clarifying questions and provide additional context. Since we base these questions on realistic problems, we’ll freely give you the information we needed to design a working solution if asked.
This is a non-coding interview, but you might draw some boxes and arrows on a whiteboard.
There isn’t one solution we have in mind. We’re not actually looking for you to design the exact same solution as the one we came up with. In fact, it’s a great sign when you can apply your engineering background to design something different and persuade us that it’ll work. The goal of this interview is to see how you’d approach an open-ended problem with many moving pieces requiring important trade-offs.
The remaining interviews help us get a sense of what’s important to you, what you expect out of teammates, and what you think you could bring to Lob. As always, we tend to ask for specific, real-world examples of things you’ve experienced.
Done wrong, "culture fit" interviews become a place to shoot down candidates who don’t look or act like current employees. Since diversity and inclusion is important to us, we’ve carefully structured these interviews to look for general alignment with our core values while remaining open-minded about it looks like in practice. Building an inclusive culture means that there are different ways to express the values that we care about. For instance, people raised in different backgrounds or who come from different company cultures will find different ways to model the sort of teamwork we’re looking for with "Find Strength In The Collective", and that’s OK.
We know that you’re interviewing us as much as we’re interviewing you. Hopefully, these will feel more like a two-way conversation between you and your interviewer than anything else.
I meet with every engineering candidate at the end of the day (again) to answer remaining questions about the company, our team, and the role.
Our recruiters debrief with you at the end of the day, get feedback on how the day went so we can continue to refine the process, and determine your next steps.
Joining a new company is a huge life choice. If you end up joining Lob, we want you to do so for the right reasons. You should look forward to spending more time with the people you met. You should understand the problems that you’ll be working on, and expect them to be interesting and novel. And you should feel like the company will work as hard for you as you will for it.
By structuring our onsite as described above, we try to give you the best possible idea of what it would be like to work with us while also learning about your abilities and motivations.
