Interview for the Work

I have been doing a few interviews recently and, to be completely frank, most companies are winging their hiring process.

That sounds harsher than it is meant to be, but only slightly. The problem is not that people are malicious. It is that very few hiring processes seem to begin with the question that should matter most: what are we actually trying to learn?

Instead, the process is inherited. This is how I was hired. This is what the last company did. This is what someone heard Google does. So the company ends up with whiteboard questions, adversarial technical rounds, panel interviews, algorithm trivia, and candidates being forced to defend every decision as if they wandered into a courtroom instead of a job interview.

It is dull, anti-collaborative, and produces a lot of false negatives.

The strange part is that engineering work is rarely like this. Good engineering is not usually one person standing alone in front of a panel trying to remember the approved answer while four people silently decide whether their discomfort looks like incompetence. Real work is messier and more collaborative. You clarify the objective. You ask questions. You make trade-offs. You use tools. You talk to people. You decide what matters now and what can be improved later. You ship something useful under constraints.

If that is the job, then the interview should test that.

I am good at finding and hiring engineering talent. I do not say that as some personal-brand puffery, because everyone is apparently a “talent magnet” now if they survived two hiring cycles and discovered Calendly. I say it because I have had to do it in environments where a bad hire was not just annoying, but expensive. Startups do not have room for much dead weight. When the team is small, every person changes the shape of the system.

At a previous company, I needed a senior engineer to balance out two juniors on the team. It was taking a while. People were coming through interviews, but nobody was getting hired. The GM became frustrated and told me, essentially, to just hire someone.

I pushed back.

That would have been the easy thing to do. It would have reduced the immediate pressure, filled the empty seat, and made the hiring dashboard look less embarrassing. But hiring someone who is nearly right into a small team is often worse than leaving the seat empty. The wrong person does not merely fail to contribute. They consume attention, create drag, distort the team, and turn leadership into cleanup work.

Eventually I found the right person. Rare, unassuming, very capable. Technically strong, but also able to work with the other humans in the team, which remains surprisingly important despite software’s heroic effort to pretend otherwise. He was one of those people others would call a “10x developer,” even though I dislike the term because it usually turns into mythology for people who make everyone else miserable.

He was the right hire.

I found the same kind of person again later in a CTO role. Different company, different context, shorter search, same underlying process. Each time I have had to hire, the quality of the resulting candidate has improved because the process has become more focused on what actually matters.

My interview process has three stages: phone screen, technical evaluation, and culture fit.

The names are ordinary. The execution is not.

The first principle is that one person should own the process. Not four people with equal standing taking turns asking safe questions and arriving at the safest possible committee decision. One person should be responsible for the hire. That person should guide the candidate through the process, make the final decision, and own the consequences of that decision.

Usually that person should also be the candidate’s future manager, because the interview is not just a test of skill. It is also a test of whether I can lead this person and whether we can work together. If I am going to be responsible for their success inside the company, then I should be the one evaluating whether that success is likely.

That does not mean nobody else can be involved. Observers are useful. Senior people can help assess specific risks. Future teammates can provide signal. But the process should not become hiring by committee. When everyone owns the decision equally, nobody owns it properly. The group drifts toward the least controversial answer, and the least controversial answer is often not the best hire. It is just the easiest one to defend.

The second principle is that probation exists for a reason.

I am not afraid to fire people. That does not mean I enjoy it or treat people casually. It means I understand that the interview process is imperfect and the cost of pretending otherwise is enormous. I would rather run a shorter, more useful interview process and then continue evaluating the person in the job than run five rounds of artificial assessment and still be wrong.

If something serious was missed, or if the working relationship clearly fails in the first week or two, then ending it quickly is kinder and more honest than dragging everyone through months of denial. The alternative is the modern hiring ritual where a company spends weeks interviewing someone, involves half the org, performs a theatrical level of due diligence, and then still discovers the person cannot do the job. Apparently bureaucracy is more comforting when it arrives with calendar invites.

I find the Silicon Valley adage “hire slow and fire fast” a little silly. The intent is fine, but in practice it often turns into endless interviewing because people are scared to make a decision. I should be spending my time building the product, not talking to people about building the product. Find someone who can do the job, give them the environment to prove it, and let the work speak.

The phone screen has one job: find out whether the candidate is basically real.

I am not trying to run a miniature trial. I am trying to clear up misunderstandings, understand why they applied, and see whether there is enough signal to continue. There is no sacred list of questions. It is a conversation between peers. I want to know what they think the role is, what they are looking for, what they have done, and whether the story they tell about themselves holds together under light pressure.

I am also listening for motivation. Why software? Why this role? Is it just a job, or is there something deeper driving them? Neither answer is automatically wrong, but the answer changes what kind of environment they are likely to thrive in. Some people want stability. Some want craft. Some want money. Some want status. Some want to solve hard problems. Some want to hide in a large organisation and be left alone. Again, not all wrong. Just different. When the role needs someone who can work across the company, not just inside an engineering corner, that last preference is a mismatch I take seriously.

The phone screen also saves time by catching mismatches early. Sometimes the candidate has misunderstood the role. Sometimes the company has advertised it badly. Sometimes the person wants something I cannot offer. Better to discover that in a direct conversation than after three more rounds of everyone politely pretending the mismatch is not obvious.

The technical evaluation is where most companies lose their minds.

They ask algorithm trivia. They ask candidates to recite Big O notation. They ask how many boxes fit on a plane. They ask people to solve abstract puzzles under artificial pressure, then mistake anxiety for incompetence and memorisation for skill. Sometimes they ask questions because the interviewer knows the answer and enjoys being on the warm side of the table. Tiny little dominance ritual, very dignified.

I do not care if a candidate can list sorting algorithms on command. I do not care whether they can solve the same whiteboard problem that has been circulating through interview prep sites for a decade. I care whether they can do the job.

So I get them to do the job.

For a senior software engineer, I put aside two hours and sit with them while they complete a task. I give them an objective, some rough constraints, and access to me as a resource. Then I watch how they work. Not in a creepy surveillance way, although apparently we do need to clarify these things now. I work alongside them. I answer questions. I observe their approach. I watch how they clarify requirements, choose tools, manage time, make trade-offs, and recover when something does not go smoothly.

The task depends on the role, but it should be small, straightforward, and representative of the work. It should contain enough depth to reveal judgement, but not so much that it becomes a take-home project disguised as an interview. For a senior engineer, one example I use is a simple race timer.

I present a fictional scenario where we need to build a timer for timekeeping a race. On paper, I draw a crude wireframe and describe the function of the application. In two hours, they need to build it, deploy it, and present it. They can use whatever language, tools, libraries, or framework they want. I am not there to dictate the how. At senior level, choosing the how is part of the job.

That freedom matters. It removes a lot of artificial stress because the candidate can work in an environment they know. I do not care if they know my preferred stack. I care whether they can execute. If they are most comfortable in Python, use Python. If they want TypeScript, use TypeScript. If they want to reach for a framework because it saves time, fine. If they want to keep it simple because the problem does not need ceremony, even better.

The timer is deceptively deep as an assessment.

On the surface, it looks simple. Start, stop, reset, display elapsed time. Most people can imagine the shape of it quickly, which is the point. I do not want them spending the first hour trying to understand some tortured domain puzzle invented by a bored senior engineer with too much coffee.

But timers reveal experience. Accuracy matters. Browser timing is not as simple as it looks. Synchronising a timer across multiple devices introduces subtle problems. The moment someone reaches for setInterval and treats it as truth, I learn something. If they have been in the browser long enough, they know to distrust it. If they have built real systems under real constraints, they start asking better questions.

Do we need server authority? Is this single-device or multi-device? What happens on refresh? What happens if the display sleeps? Are we measuring elapsed time from a recorded start timestamp or incrementing a counter and praying the JavaScript gods remain benevolent? What does accurate enough mean for this race? Does the operator need correction controls? Where is it deployed? Who is using it? What does failure look like?

Those questions tell me more than a whiteboard algorithm ever will.

The two-hour limit is also part of the test. The task can become large if they let it. You could spend days handling edge cases, polishing the interface, synchronising clients, storing results, managing operators, adding audit logs, and making the whole thing robust. But they do not have days. They have two hours. That constraint forces prioritisation.

Can they identify the core? Can they produce something working? Can they decide what not to do? Can they communicate trade-offs clearly rather than disappear into the code and emerge at the end with half a cathedral and no roof?

A senior engineer should understand that shipping is not the same as doing everything. It is making deliberate choices under constraints. The technical evaluation should reveal whether they can do that.

The task also tests collaboration. I explicitly tell them I am available as a resource. They can ask questions. They can clarify. They can push back. They can even ask me to help with something if that is the best use of time.

If a candidate says, “Can you set up the deployment target while I focus on the timer logic?” that is excellent signal. It means they understand they are working inside a team, not performing rugged individualism for applause. It means they can allocate work, use available resources, and keep the objective in view.

This is what most adversarial interviews destroy. They create an environment where candidates believe asking for help is weakness, uncertainty is failure, and collaboration is cheating. Then companies act surprised when they hire people who hide problems until they explode. Stunning little mystery.

The final stage is culture and fit, although I dislike the phrase because it has been abused into meaning “do they seem like us?” That is not what I am testing.

By this point, I already know whether I want to hire them. The final conversation is usually about exposing the candidate to the broader company and giving senior leadership a chance to identify any serious concern I may have missed. I will often invite the most senior relevant person I can into a conversation with the candidate. Not to restart the process. Not to perform another full interview. To give them a chance to meet, ask questions, and veto if something outstanding appears.

That veto should be rare. If the process has been run properly, the final stage should not be where the real decision happens. It should be where the company confirms there is no hidden mismatch large enough to matter.

The goal of an interview process is not to make the company feel rigorous. It is to identify whether this person can do the work, whether I can lead them, whether they can function inside the team, and whether the trade makes sense for both sides.

That does not require five rounds. It does not require algorithm theatre. It does not require a panel of people asking questions they copied from somewhere else because thinking from first principles was apparently too large an ask.

It requires knowing what you are hiring for.

It requires designing the process around the actual job.

It requires enough courage to make a decision and enough humility to keep evaluating once the person starts.

Most companies do not have a hiring process. They have inherited rituals. They copy what looks professional, add more steps when they get scared, and mistake friction for quality. Then they complain that good people are hard to find.

Good people are hard to find.

Making them perform nonsense does not help.