Long Interviews are an antipattern.

For the length of my career in startups, both as an interviewee and interviewer, interviews are way too long and way too uninteresting. Today I see startups attempting to do on sites that last multiple days, or take homes that only take “3-4” hours to complete, or even worse, making a founding engineer do sets of leetcode problems to get signal.

But why are some startup interview processes are so long? What that leads to this and what we do as startups to actually hire great talent without spending 12+ hours of your time on seeing people write the same code over and over again.

The origins of long and boring interview processes

Hiring in a startup is much more unpredictable than hiring in a big company, while on the surface, the ultimate goal is to get a butt into a seat to start coding something. A startup, due to the size, has greater risks when adding a single employee to the roster, as every employee brings their own biases, skills and culture to your company. When you have 1000 employees, every new employee is only contributing a fraction of a percent to your company’s growth, versus in a startup of 4, a new employee would be seen as 20%.

That % can be extremely positive -- hiring someone who’s 20% of your company and is: extremely skilled, gets along with everyone, and can teach the team is going to much more greatly affect the overall output of the team. On the flip side, a bad 20% hire can completely disable a team, even if the other 80% are working the most optimally.

It then seems reasonable then for startup founders to spend 12-30 hours over multiple weeks interviewing the same person just to be absolutely sure they’re going to get the person they need. It seems like a fair trade, right?

Perverse incentives

The standard interview process comprises three parts, an introductory interview to validate alignment on the role, a set of technical interviews to validate ability and then a final stage, usually an onsite, full of a bunch of small interviews to check the work of the two first interviews. The phone screen and technical interview will give you 75% of the signal you really need, everything else will get you the remaining 25%. With this configuration, it is only natural that most companies traditionally only have three rounds.

But startups and even some larger companies seem to think having multiple remote technical rounds or multiple days of onsite interviews can help them get a better signal, but asking someone the same questions of different flavor over and over again will ultimately reduce the amount of signal you can get from someone every time; and it leads to a great filtering. The more you ask and prod, the more time you waste for the engineer, who could go for someone else in the meantime. You may only get the most desperate of engineers.

There’s nothing wrong for an engineer to be desperate inherently, we all need to pay bills and sometimes you get unlucky with interviewing, but desperate engineers are also going to the engineers who will take bigger risks to get hired, this could be as simple as cheating, or even worse not actually even wanting to work at your company since they just want to get paid by someone.

For both a big and small company, someone who lies about their qualifications is bad; but for a startup, a disinterested employee can be its own level of destructive.

The more steps and stages, and the more time you take between interview spots, the fewer people will be interested in working with you, not because your product Is bad or not interesting, but because either there are limitations to how much time people can take off from their current job, or another startup that is as equally as interesting has a shorter interview loop that will get them the offer instead.

If you have things like multi day on-sites, even if they’re paid, your sample of people who will do this is much smaller and mostly will consist of people who aren’t working right now. Which, again isn’t a negative signal, but you lose the ability to hire people who do have a current job, so you just lose access to people who you might like more.

What’s the fix?

On the surface, the fix is just do the standard three phase interview: Phone screen, online technical, and onsite. Nothing else; but we don’t fix the boring part here, we don’t want you to waste your time as well with low signal interviews.

Identifying your values and the pre-interview

Life is a set of values that you apply into the real world; the same can be said about a startup. What are the values of your startup, are they working long hours to get to a goal, are efficiency trumps time, or is it let’s build the least harmful product possible. There’s lots of values you can have in a startup, but you can bucket them into a few categories:

• How do you want engineers to spend their time?
  • Do you think most of their work should be research, should it be application, or should it be a mix
  • Engineers who are dead set on goals will show off their resume based on growing existing products, those on their learning and growth may show off new projects and verticals
• How do you determine efficiency?
  • Are efficient engineers who spend the most time on deliverables, or are they engineers who spend their time mostly on building solid fundamentals first
• Do you value implicit or explicit communication?
  • Do you need daily standups or do you want your team to update their boards where you can check them instead
• Do you value credentials?
  • Do you care if your engineers are all from a bootcamp or do they need to have a college brand or another big company
• Do you want to foster growth or do you want people who grow by themselves?

And many more, and most good hiring managers think of these things when looking at a resume before even talking to a candidate. You can take those values and map them to how a candidate portrays their work. If you see their project brief and see that tenure is shorter at companies where projects seem more simple, it probably means this engineer values challenge, or if you see them list mostly mentorship and leadership skills over code written, it probably means they’re not going to write as much code, and maybe a good fit to build team instead.

The Phone Screen

Once you’ve screened a resume, you should have already filtered out 90% of the talent that comes in, as long as you know your values.

The phone screen then becomes the fastest way to figure out if someone is actually going to join your team or not. Many times I’ve done phone screens, I can almost exactly tell if someone is going to pass the onsite then and there and who’s not, and I’m sure most of you feel the same.

What should you be asking then?

You should take the values you have, and try to figure out if your assumptions of them are true, not necessarily literally asking them the questions above, but instead trying to figure out if their work behavior in the past aligns with the values your company has.

If they align with your values, you’re good to go, if not, then maybe you shouldn’t send them off for 10 more rounds.

The Technical

The online technique is probably the worst implemented part of any interview process. Some companies believe that a generic coding challenge is good enough to qualify someone to be on your team. And for a huge company, this makes sense, you don’t necessarily need someone who knows anything broader than how to program to work with you, as large companies have ramp up times that people can become accustomed to, even if it’s different programming languages.

For you though, a startup, you want something more practical, you probably want an engineer who knows the language you coded your startup in, and probably more than you hopefully too. Many startups have begun to believe that the most equitable and simple task is giving a developer a prompt or a codebase and telling them to spend between 8-36 hours building them something to present. This sounds good, if you want to hire someone desperate or a contracting firm.

Most people don’t want to waste time, even if they think your company is great at building a whole app in their free or paid time. Your scope of hires starts shrinking as soon as you make interviews longer than standard ones. The second issue is also, you don’t actually know what they’re doing at that time; the technical interview is not just about seeing if someone can code, it's a first look at how someone thinks about problems. And you lose 50% of that in a take home interview; even if you make them present it afterwards; it’s often a negative signal, as engineers, especially those in earlier career paths are not as trained in technical presentations.

What I do nowadays is I build a project halfway: if it's for a full-stack dev, I’ll build a Next.JS app with a prebuilt sqlite db; for a platform engineer, a docker compose with some services and a working app; this halfway project will have challenges; different tasks from different skill sets you can identify from those types of engineers; a full stack engineer could be amazing at design and databases but are just ok at building APIs, construct enough different challenges for engineers to possibly do, and make sure all of them take around an hour to actually do. Now; give your candidate this codebase a few days before the interview, and tell them to pick a challenge. Tell them you can look and prod the codebase but don’t start working on anything or sharing the code.

Doing this interview style you gain a few things:

• Remove engineer stress from throwing random prompts at them as they know the challenge is, engineers don't work from black boxes in the real world, why are they here
• Give them a look at what your company is working with; sometimes you accidentally get someone who’s more suited for a different role, and they’ll let you know from just looking at the codebase
• Not making your interview super long, you keep the engineers who lose you to just time constraints
• Doing something kind of fun and entertaining that has to do with what they probably also are good at; leetcode is a drain and a grind, and most people even if they’re good at them, don’t like doing these problems, and can just lead to negative signal unnecessarily
• Give you insight on how they approach a problem; are they someone who is curious and looks at problems beforehand, or are they people who wait for the time to actually interview.

The onsite

The onsite or final stage exists for two reasons, one to check your work, and two examine culture fit. Your first two stages should have been good enough to weed out most interviewees, the onsite should only be there to validate your assumptions on their fit within your company.

To me, the best way to accomplish this is for them to run through the first two interviews parts again, but in a different format:

The start of your onsite day should be a meeting with the candidate and your team. Go over what was done on the technical and let them know they will be completing some more challenges from that interview.

The candidate has had some hands-on experience with the codebase, and you should instruct your candidate to take some time to write up an architecture doc on how they plan on tackling this next challenge.

From there; you should give them some time to write up a spec, meet with them after an hour and discuss. I never understood why system design interviews had to be drawn in front of an audience. Usually engineers are left alone when writing specs in real life. The only time they start talking to others is in the feedback phase.

From there, they should spend the rest of the day working on that challenge or challenges, similar to a work day, and in the middle of the day, you all should go out for a lunch, because then you can really vibe check someone on how they hang. Of course they might be a little nervous, as it is an interview, but as an interviewer, you should try your best to break the ice.

From there, they should have a check-in with you about progress, you should give feedback to the current work at hand, maybe suggesting changes or asking their opinion on why they did something, all this should be to derive a signal about ability but also to tie it again into your startup’s values.

At the end of the day, you should save a good hour on a discussion of the candidates work. Let them explain to you and your team what they did and what they accomplished, it doesn’t need to be super presentationally, you should make that a point, and it should be casual; you may learn something about how they implemented a feature or did something cool, this is a massive signal.

Then you send them off. And you and your team should immediately discuss them. Any time you sit on candidates, you lose your impressions of them, and two you lose time for them possibly signing with someone else. Discuss immediately, see if the values and abilities align.

Then send them the offer. That's it.

Good night