Technical Interviews ≠ Assigning Homework

We need to change how we interview in Tech. The demand for tech workers is skyrocketing, and interviewing cycles are still taking too long. I think this is simply due people not knowing how to easily assess someone's technical skill - and from there, you get the dreaded take-home Technical Assessment.

Here's the thing: You wouldn't ask a candidate to fix a bug in your product's code base, would you? You also wouldn't ask them to build some internal productivity tooling, or you an app that you can sell, right?

Seems wrong, doesn't it? You're benefiting from free work. That's exactly what you're doing when you give them a take-home technical assessment.

Sure - you may not be looking to productize their submission, but you are still asking them to produce something that materially benefits the company. It is free work you are capitalizing on, that addresses a problem you couldn't resolve with the resources you have. In this case, they've solved your company's problem with assessing a candidate's skill.

There's no such thing as a "throw away" assessment. If you look at their submission, you're benefiting from their work. For free.

I'll be the first to admit - I've given technical assessments in the past. And I regret doing so. Reflecting back on them, this was when:

1. I was early in my career, and assessments were considered a standard. I simply didn't know a better way.
2. Later in my career, when I didn't know the specifics of the tech stack and needed to rely on someone who couldn't join me on the interview.
3. If I was very iffy on one's skillset and couldn't get a clear answer in the interview. Maybe the candidate had a limited portfolio, or they were self-taught and couldn't communicate using shared language and key terms. Or, perhaps their overall experience was focused in a different area and they were pursuing a different skillset.

Though well intentioned - these aren't excuses. I was asking for people to compensate for my inability to evaluate them.

After years of interviewing and hiring, I'm convinced technical assessments are just lazy hiring practices that need to end.

So what do we do?

My best hires never received a technical challenge. Instead, over the course of our conversation, I could tell the candidate knew what they were doing by how naturally the spoke, and with the content of their conversation. Homework would just waste their time and prolong the hiring process.

Here are the rules I've developed for myself:

1. If the hiring manager doesn't know the domain, include someone who does - it doesn't have to be for the whole interview. Schedule around the person with knowledge most relevant to the role.
2. Be conversational when asking about prior experience. That's the best way to assess someone's skill and culture fit. It's where you'll see a candidate freely surface their passion, domain knowledge, humility, problem solving, mistakes, things learned. All of it, highlight naturally and with authenticity. That being said - depending on the comfort and depth of a candidate's experience, this may not always work.
3. Ask technical questions conversationally. This should not be a time-limited trivia show or military interrogation. Don't ask "What are the 4 principles of OOP?" instead, ask: "What are your thoughts on OOP, and how well it works when building a modern application?"
4. Be sensitive to the context of the situation. No one does well when there's money and livelihood on the line. That's high stakes. If you've ever dealt with an urgent outage - you know: everyone needs space and the ability to breathe to solve a problem. Don't assess talent in a vacuum. Collaborate. Ask what they'd Google. Maybe even Google to see what comes up, in case the search terms need to be refined.
5. Asking someone to reproduce a sorting algorithm that took a Computer Science researcher years to develop is not assessing skill, it's assessing memorization. White-board with them if you're still on the fence with their skillset. But approach this without being binary pass/fail. Measure their aptitude to learn on the job.
6. Consider having the candidate drive the conversation. Ask them, in advance of the interview, to bring some of their code to the interview to be showcased. Let them know you'll be asking questions about their choices and decisions, where they struggled, what they researched and what they produced independently, ways they could improve their solution, what they learned. Let them know while you may scrutinize their code - it is not to be critical, but only to get a gauge of their understanding.

What can you do if you're the job seeker?

If you're on the other side of the table, I think it's time to turn that table. Especially if you're an Entry-Level or Junior candidate, where the market is the most competitive and demanding.

Pre-empt any take-home assessments: Give yourself a project that you can proudly showcase (or repurpose one that you already have). One that you can re-use in different interviews, so you can get better at presenting and talking through technical concepts.

Having managed many people over the years the one recurring area I see developers continuously struggle is with presenting. How do you distill thousands of lines of code into a concise overview that keeps you from rambling?

First: Pick a project that represents the breadth of your skill and knowledge. If you're full stack, it should be full stack. If you're a front-end developer, DB engineer, whatever. It doesn't need to be a fully baked product that has thousands of users, or even thousands of lines of code. But it should be yours, and you should be able to comfortably speak to it.

Second: Pick an area you want to highlight. It should be an area that's easily quantifiable - either through benchmarking, memory usage, large data sets, if you can attach a number to it, that's great.

Third: Explain it to your grandmother. It's been a while since you called them anyway. If they can understand what you're talking about, you're on the right track. (As a quick anecdote: At times asked candidates during interviews to pretend they're having a conversation with their grandmother, and to explain to their grandmother why they're happy in their job... as strange as that may seem, as introverted as some candidates have been, I've seen them light up with the passion and confidence I was looking for.)

Finally: Bring your code with you to your interviews - on your laptop, tablet, on just print it out. Before the interview gets technical, use any lull in the conversation as an opportunity to say: "If we need to start talking about my skill, I've actually brought some code with me that I'd like to talk through what I've done to give you insight into how I problem solve. I think this will give you much more insight into me than if there's a technical challenge at the end."

If I'm hiring a carpenter, I don't give them a small blueprint and ask them to build it for me so I can assess their skill. However, they do bring photos of projects they've done, and talk about each of them.

That's how it should be.