Conducting the Technical Interview

— 9 minute read

Even after a decade in web development, there's nothing in this field that scares me quite like going through a technical interview. I'm never quite sure what questions I'll be asked (theoretical or applied scenarios) or the style of interview (conversation or white-boarding) I'm walking into. I've experienced serious highs and some brutal lows.

As a senior developer, tech lead, and now engineering manager, I've also been on the other side of table. Being the interviewer can bring its own bouts of stress; the process is made even more complex when you're attempting to fill a senior-level role in a language that you maybe aren't as familiar with yourself (or perhaps don't know at all).

The process is so painful on both sides of the table - it's time for a change.

Where are we getting it wrong?

The Googles and Amazons of the world have very specific interview processes. Rounds and rounds of computer science questions followed by hypothetical "brain teasers".

"How would you go about calculating the number of tennis balls you can fit inside of this car?"

"How much should you charge to wash all the windows in New York?"

Questions like these are interesting as logic experiments, and maybe they can even give you some insight into a candidate's cognitive and problem-solving abilities, but there are plenty of well-qualified people who will struggle to answer them. On the flip side, there are hundreds of articles and websites built with the specific purpose of training candidates how to answer these questions or to successfully navigate complex recruiting processes at major tech companies. In either scenario, are hiring managers getting the right people for the job?

Good people are getting passed on because of a few key failures in the technical interview process:

"Culture fit" reinforces unconscious bias

We all want to be around people we objectively like - people who pass the "beer test": would you want to get a beer with this person after work? The problem with hiring for cultural fit, however, is that it by definition weeds out people who aren't like us, reinforcing the homogenous teams that already exist.

You aren't hiring a best friend. You're hiring the person that is best suited to perform the duties of the role available.

Organizations thrive when they bring in people from diverse backgrounds and lifestyles. Tech knows this; they've been publishing diversity reports for the last six years, but little has changed. The industry has a long history of hiring through gate-keeping and personal relationships which makes it notoriously difficult to get a foot in the door if you (or your mommy or daddy) aren't well-connected.

Even when we get a diverse set of people in the room, we still have a huge problem with the bias that's been built into our AI software. We need a more diverse workforce in every industry, but especially in tech: the singular viewpoint of straight white men is resulting in real world consequences that stand to further marginalize women, people of color, and members of the LGBTQI community.

White-boarding has it's limits

Writing code by hand is a learned skill. Hiring managers need to be very careful about the weight given to white-boarding abilities in the interview process. Writing out code in front of a room full of people who are actively judging your performance simply isn't how people work day-to-day, and it can be crippling for the introverts that dominate our field. This required performance shouldn't be used as the ultimate measure of a candidate's ability to do the job.

Even strong developers can get caught up here. Use white-boarding sparingly, if at all.

Stop trying to trick your candidates

This is especially true for junior roles. Your trick questions aren't telling you anything about how qualified a person is to take on a role. There are plenty of intelligent candidates that will get caught up on these in an interview setting.

Please stop with this humiliating nonsense.

Blanket CS degree requirements have got to go

Expecting developers to have a complete knowledge of everything taught through a computer science education is antiquated. There are plenty of highly-skilled self-taught developers out there (myself included) who didn't have access to the resources to even attend college, let alone get a CS degree. You can learn a lot of valuable things in school, but there are many unconventional paths into this field.

Is your dev actually required to build a graph data structure? If answer is yes, fine. Keep in mind though, algorithms and data structures can be taught pretty quickly.

How do we fix it?

With so much broken in the process, where do we begin? Every position is going to be different, but we all need to do a better job of setting our candidates (and frankly, ourselves) up for a more empathetic and equitable interview experience.

Test the fundamentals first, then your tech stack

Any decent developer can adapt to your coding style and stack. What you should be trying to assess is where they are currently, and if their skill set is sufficient or can be quickly built upon in order for them to be successful in the role.

Be up-front about your stack before the interview even starts. If the expectation of the job is a reliance on specific algorithms, let the candidate know; if they aren't equipped, allowing the candidate to self-select out will save everyone's time.

Pay people for their time

This one tends to be controversial, but I stand firmly in favor of it. If you are asking a candidate to spend more than an hour on a technical exercise or to commit to days-long interviews, pay them for their time.

I've spent as much as 40 hours on a single round of a technical screen. This level of commitment isn't fair to anyone. Show them you're serious about their effort and your commitment to bring the best talent on board.

Best case scenario: have the candidate complete a project in your queue. This will not only justify the cost for hourly comp, but also ensure the screening process is applicable to the day-to-day responsibilities of the job.

Coding challenges need to mirror real-world work

Here is a brief list of possible interview scenarios you can leverage dependant on your company, available time, and team size.

The first one is obviously going to take more setup, but it will get easier moving forward.

Paired programming (work on real bugs)

Set aside some stories or bugs that take a little less background and context on a project (and that are obviously less time-sensitive). Have the candidate pair up with you and/or your team to work through real issues they'd be dealing with in your actual code base.

Concerned about trade secrets or sensitive information? That's what an NDA is for. Most of us aren't working with government-level security risks, however.

Bring in, build a project (solo & with Google), and then quiz about decisions made

I consider this scenario better-suited to more senior positions due to the level of complexity required to assess senior developer's skills, but it can be done effectively for junior folks if you give them more room for error. As stated above, this is a time commitment, so pay them for their time.

Let your interviewee sit alone with internet access and have them build something, ideally similar to a product they might be working on as a member of your team. Try to make it something that hasn't been done to death (like a TODO application).

This type of exercise can illuminate how a candidate thinks through a start-to-finish project, giving you insight into coding style, project structure preferences, and where they are as a developer.

Sit down with them after their alloted time and discuss the experience. They don't have to have a finished or working product; this is your time to dive a little deeper in to the hows and whys of what they just made and understand how they would overcome common barriers.

Write unit tests to develop against

Write out some unit tests against explicit acceptance criteria. Give the interviewee the opportunity to write code to get the tests passing. Similarly to the project scenario, let them use the internet. Let's be honest: we all Google our way through roadblocks.

Write broken functions with working unit tests

Write broken code with working unit tests. Let the candidate debug the code and try to figure out what the root issue is. Do your best to stick with code that's similar to what they will be working with (or where you intend to take your stack at the very least).

Check your bias - Diversify your teams

Changing the structure of your coding assessments is the easy part. Taking the steps to seek out candidates and hire talent from diverse backgrounds takes diligent work.

Here are a few steps your company likely needs to take.

  1. Partner closely with your HR team. The first step in hiring for diversity is filling your candidate pool with women and people of color. This will require proactivity in recruiting efforts.

  2. Throw "Culture Fit" out the window. Period.

  3. Look at the candidate as a whole person, not just a degree. A 4.0 GPA from an Ivy League school just tells me you likely had a privileged upbringing. There are many unconventional paths into a tech role, and education is rarely the element of someone's background that will indicate their skills or readiness as it pertains to the job.

  4. Make connections with people who are different from you. It's human nature to gravitate toward people who are similar to us. Make an effort to open up your circle and fill it with people from diverse backgrounds. Start by identifying just one new contact with a different interest, ability, ethnicity, sexual orientation, socioeconomic status, or gender identity (conforming or non) to build a relationship and begin expanding your network.

Keep on learning

If you have the ability, run regular audits on your hiring process to make sure that it's working. Tweak as needed.

No company is perfect and I'll be the first to admit I am struggling to adopt these very changes in my own job. But we should all strive to do better for everyone, ourselves included.