What it takes to get hired

Sun, 19 Jan 2025 00:00:00 +0000

I’ve been on both sides of the hiring table enough times now to have some opinions about this whole process, and honestly, most of them are pretty depressing. The way we hire engineers is fundamentally broken, but it’s broken in predictable ways that you can game if you understand the system.

Which is itself part of the problem.

Let me start with the obvious stuff that everyone knows but nobody wants to admit: technical interviews don’t really test your ability to do the job. They test your ability to solve algorithmic puzzles on a whiteboard under pressure while someone watches you and judges your every move.

I’ve hired people who aced the leetcode-style questions but couldn’t debug a production issue to save their lives. I’ve also passed on people who struggled with the toy problems but had the kind of deep systems knowledge that comes from years of actually building and maintaining real software.

The disconnect is obvious once you think about it. When was the last time you had to implement a binary search tree at work? When was the last time you had to reverse a linked list? When was the last time you solved any problem without access to Google, Stack Overflow, and the ability to run your code to see if it works?

But we keep doing these interviews because they’re easy to standardize, easy to score, and they feel objective. They give hiring managers the illusion that they’re making rational, data-driven decisions rather than subjective judgments about whether they like a person or not.

The reality is much messier.

What actually matters for doing engineering work well? Let me think about the best engineers I’ve worked with and what made them effective:

They could break down complex problems into manageable pieces. They could debug issues systematically rather than randomly trying different things until something worked. They could read and understand existing code quickly. They could communicate technical concepts clearly to both technical and non-technical audiences. They could collaborate effectively with teammates who had different working styles and communication preferences.

They had good instincts about when to optimize and when to ship. They understood the business context around their technical decisions. They could balance perfectionism with pragmatism. They could learn new technologies quickly without getting overwhelmed by choice.

Most importantly, they gave a shit. They cared about the quality of their work, about the experience of people using their software, about the maintainability of the systems they built.

None of these qualities are tested by traditional technical interviews. Some of them can’t be tested in an interview at all—they only emerge over time, through actually working with someone.

So what does get you hired? Unfortunately, it’s mostly signal rather than substance.

You need to be able to perform competence rather than just demonstrate it. You need to tell a compelling story about your background and your interests. You need to ask thoughtful questions that show you’ve researched the company and understand their challenges. You need to seem enthusiastic about their specific problems rather than just looking for any job.

You need to practice the artificial interview questions until you can solve them smoothly and confidently, even though they have nothing to do with the work you’ll actually be doing. You need to be able to explain your thought process clearly while solving these problems, which is a completely different skill from actually solving them.

And increasingly, you need to have the right keywords on your resume and the right projects in your GitHub. The screening process has become so automated that humans often never see candidates who don’t match the exact technology stack the company thinks they need.

This is particularly challenging for people whose careers don’t fit the standard narrative. If you’re changing careers, if you took time off, if you learned to code through non-traditional paths, if your experience is broad rather than deep in trendy technologies—you’re at a disadvantage regardless of your actual capabilities.

The ADHD angle makes this even more complicated. Many of us are really good at the actual work but terrible at the performance aspects of interviewing. We might nail the technical questions but struggle with the behavioral questions that require constructing coherent narratives about past experiences.

Or we might do great in casual technical conversations but freeze up when asked to solve problems on a whiteboard with someone watching. The artificial pressure and lack of normal tools can trigger anxiety that has nothing to do with technical ability.

I’ve bombed interviews for jobs I could have done in my sleep, and I’ve gotten offers for roles that were probably above my level at the time, all based on how well I performed in the interview rather than how well I could actually do the work.

The optimist in me wants to believe this is changing. Some companies are experimenting with take-home projects, pair programming sessions, code review demonstrations, and other formats that better simulate actual work. The rise of remote work and AI tools have made it easier for companies to hire based on demonstrated ability rather than cultural fit.

But the pessimist in me knows that most companies are still using the same broken process because it’s what everyone else does, and changing hiring practices is risky and expensive.

So what’s the practical advice for people trying to navigate this system?

First, accept that the game is partly artificial and prepare accordingly. Practice the leetcode problems, not because they matter, but because hiring managers think they matter. Get good at telling your story in a compelling way. Learn to project confidence even when you’re not feeling it.

Second, focus on companies and roles where you can demonstrate your actual abilities. Look for places that value take-home projects, open source contributions, or other evidence of real work. Seek out startups and smaller companies that might be more flexible about their requirements.

Third, build genuine relationships in the industry. The best opportunities often come through referrals, where someone who knows your work can vouch for your abilities rather than relying on interviews alone.

Fourth, don’t take rejection personally. The hiring process is noisy and often arbitrary. I know excellent engineers who got rejected by companies they would have thrived at, simply because the interview process didn’t capture their strengths.

Finally, (this is by far the most important step:) once you’re in a position to influence hiring-whether as a senior engineer, tech lead, or manager-try to make the process better. Push for interview formats that actually test relevant skills. Advocate for candidates whose experience doesn’t fit the standard template. Question whether you’re optimizing for interview performance or job performance.

Because ultimately, the goal should be building great teams that can solve interesting problems effectively. And that requires people with diverse backgrounds, experiences, and ways of thinking.

The current hiring process doesn’t optimize for that. But maybe we can slowly make it better.

Career on Sam's Blog

What it takes to get hired