A better way for non-technical and technical founders alike to identify and hire top talent.
Coding interviews suck. 🤢
There are stereotypical whiteboard interviews used by big companies like Google and Facebook. These involve solving some complicated riddle on a whiteboard – in theory, using skills you’ll use on your job or pseudocode. 🤷
Because, you know, when I was programming I spent almost every day trying to calculate the speed at which 10 trains 🚂 would collide provided three were traveling at 60 km/h... you get the picture.
These tactics are successful at finding hard to work with, reclusive geniuses. 🤩They’re also an excellent way to miss out on lots of great programmers.
To combat this, many tech companies give candidates a take-home problem 📚 that more closely reflects the work they’ll be doing. This gives the interviewer a better idea of their overall skill set.
That’s problematic, too. It works better for candidates who have lots of free time, but not those with kids or other commitments. It’s also high pressure, and it can still be tough to get a sense for what the person actually knows.
When we set out to hire two new developers we wanted to find a better way. That’s when we found this method from Pete Holiday.
Start with a creative code review 🧐
The first step in this method is the most creative step. Instead of asking a candidate to write a piece of code and then reviewing it yourself, you write a piece of code and have every candidate review it. 👨💻
You intentionally build flaws 🐛 into the code and then grade candidates based on which flaws they catch. The brilliance is that this actually tells as much or more than a typical coding interview.
By having candidates review code you’ve written you learn:
📖 How capable they are of reading code (a hugely important skill)
🤬🙅 The style in which they deliver critique (are they respectful, but assertive?)
👌 Their attention to detail (do they notice small mistakes?)
🏗 Their architectural skill (do they notice larger, subtler mistakes?)
🤓 What they actually care about (they’re unlikely to point out mistakes they don’t care about)
If you have an existing technical team, code reviews should already be a natural part of your team’s process and everyone should be used to reviewing others’ code. Junior programmers can learn more from reviewing a senior’s code than they ever will stumbling along on their own.
###brif you have the code and the rubric, you don’t even have to be technical to give this interview. It certainly helps, especially if a candidate notices something that isn’t on your rubric, but you could grade a programmer without having to read through any of their code.
Note: Right now, this is almost impossible if you can’t write the code yourself. But we’re working on a set of code snippets and rubrics to make this easier for non-technical founders! If you’re interested hit reply and let us know.
Follow it up with a whiteboard interview 👨🏫
Yes.
We started this issue railing against whiteboard interviews, and now we’re advocating for them. That’s because the problem with traditional whiteboard interviews isn’t the whiteboard…it’s the interview questions.
We use whiteboards constantly. We don’t use them to write code, but we do use them to architect problems. 👷🏗 This is what you should be using them for in interviews, as well.
We had every candidate who did a technical interview walk through an architectural exercise with us. For the exercise, we imagined we had a new client who wanted to build a Slack clone. They wanted to launch their MVP in just 3 months. 🚀
We asked the candidate:
- What features would you build?
- What type of database would you use?
- How would you plan out the API?
As Pete explains in his blog post, you should use an application they’re already familiar with (like Slack or Twitter) that way they already understand the context.
These are questions that engineers will answer differently based on their experience level. Our team is still small, so we were looking for more senior engineers when we were hiring. (We plan to hire juniors next.) That meant we needed them to be able to do this kind of work on a regular basis. 💻📲
We were also looking for how well they communicated, 💬 what kinds of questions they asked, ❓and how well they could articulate the reasoning behind their decisions. 🤔
We ran three candidates through this interview process and ended up hiring two. 😄😄 Each candidate provided different responses throughout the interview, but each had deep knowledge and communicated that knowledge to us well.
We never looked at a single line of code they had written before we hired them, and they have already exceeded our expectations.
The ability to think, communicate, make smart architectural decisions, and recognize problems in code are all incredibly important in successful engineers. Much more important than solving complicated math equations in a high-stress environment. 😰
If you’re looking for a better way to hire top-notch developers, give this approach a try. We weren’t disappointed and you won’t be, either.
"I am convinced that nothing we do is more important than hiring and developing people. At the end of the day, you bet on people not on strategies." - Lawrence Bossidy
Want to see us cover a topic? Have major startup questions or sticking points? Email andrew@builtbykrit.com
