We are excited to bring Transform 2022 back in-person July 19 and virtually July 20 – 28. Join AI and data leaders for insightful talks and exciting networking opportunities. Register today!
I’d been doing professional web development for nearly a decade when I had a horrible interview. It was with a well-known company, I’d met the founder and to say I was super excited about it is an understatement. I did well on the first whiteboard. Then my next interviewer came in and asked me to implement a Lisp parser also on a whiteboard.
Given the time, space and a familiar set of tools, I knew I could have gotten it right. But at the moment, I was thrown off. Writing code on a whiteboard isn’t how you typically code — you can’t test or execute as you write it. If you make a mistake, you can’t just add a new line in the middle like you do with an IDE — you have to erase it and adjust manually. As I struggled, I got no help from the interviewer either. I watched him walk out, speak to my next interviewer and then a recruiter came in to say I could go home.
Between implementing a Lisp parser on a whiteboard versus a more intuitive environment and a total lack of interviewer engagement, it was a terrible experience. But it turned out for the best — while I was walking around Union Square completely dejected, a recruiter for HotelTonight happened to call and I got a great job after an impromptu interview the same day. But it taught me a lasting lesson about technical interviews: they should be relevant to the job you’re hiring for and designed to understand the whole person.
Today, in the time of the Great Resignation and talent migration, it’s even more crucial to get your hiring process dialed in because talented technical staff can go anywhere they like. You must be able to make a compelling case for your team and company — they’re interviewing you, it’s not just you interviewing them.
After interviewing hundreds of technical candidates, here’s what I think about.
Target engineers that resonate with your product
If you’re a small company, you can’t compete with the FAANG companies on salary or mobility — and there’s a certain kind of engineer who will always choose them anyway (which is cool!). But if you’re not Amazon or Facebook, prioritize candidates who are interested in solving your kinds of problems.
For example, HotelTonight practically sold itself — people love free hotel rooms and it was a great product. For us, our engineers have all been through the grinder with previous job interviews, so they’re clear on what sucks about interviewing and how they’d like to fix it. Orient around your use cases as a differentiator.
We also love highlighting that the ownership over innovation and problem-solving is much bigger than a thousand-person engineering organization. You will have an outsized impact on the direction of the product and therefore the company — and that’s an incredible feeling.
Be transparent about the business
Ensuring a positive experience for both hiring managers and candidates means showing what it’s like to work at your company daily. That doesn’t mean being completely and inauthentically rosy. It means being clear on what problems you’re trying to solve, where the business is strong (and where it’s not) and the technical roadmap.
I’ve found that having these conversations earlier on in the process is better. That way, you know the people who choose to continue on really are interested in the work and feel like your company could be the place for them. The right people will be excited to tackle problems with you.
Be aware of bias — and create a system to counteract it
The software engineering community is slowly getting less homogeneous — which is great — but there is still a lot of work to do. It’s the responsibility of businesses and hiring managers to create a fair process where all candidates can do their best. Sure, it’s challenging — but completely worth it because you end up with much better products and processes.
Openly discuss bias as you refine your hiring process. Maybe you remove names and other demographic information at the screener level. You should standardize questions so that everyone applying for the job can be compared based on the same criteria.
There should be clear criteria for what makes a good or bad answer. And talk through how you will help candidates in the process. At what point, for example, will you step in and help a struggling candidate with some clarifying detail? As much as possible, candidates need to have the same process and experiences.
Account for the non-technical elements in an engineer hire
Yes, technical acumen is huge — but if you use the right assessment tools, you know you’re going to get an accurate read on a candidate’s ability to code. In fact, an accurate technical evaluation forms a strong baseline so that a shiny personality doesn’t blind you to a candidate who doesn’t have the skills that you need.
But the non-technical stuff is just as important. You have to figure out if this is a person you’d want to work with (and this goes both ways, by the way — candidates have to make a similar calculus). How do they prefer to communicate with coworkers and customers? What management style will empower them to do their best work? What are their career goals and passions? How do they handle constructive feedback?
Soft skills and personality matter significantly. After all, even if someone is an exceptional technical talent, do you really want them on the team if they’re an arrogant, morale-killing, toxic presence? Of course not. It’s much better to invest time into figuring out if a candidate will add to — or detract from — team cohesiveness than, say, asking them to create a Lisp parser on a whiteboard.
Candidates, curious what’s stood out for you (good or bad) in your recent interviews? And hiring managers, have you tried anything particularly innovative in your quest to stand out to new talent?
Jonathan Geggatt, VP of engineering at CoderPad.
