Fixing the Technical Interview

Anyone who has gone through a round of technical interviews understands how gruesome and unfair they can be. Interviewers ask brain-teaser style coding problems that:

1. give a huge advantage to those who have seen it before, and

2. don't mirror the actual working conditions of the position

So interviewees are incentivized to "grind out Leetcode" and spend too much time memorizing solutions.

On the other hand, interviewers have to wade through many unqualified candidates (I've seen this firsthand), and those same unfair coding questions provide an easy, standardized way of weeding out unprepared candidates. (Personally, I started resorting to less open-ended/more traditional coding questions after a particularly nasty reaction from a candidate who did not pass to the next round.)

So what's the solution here?

We need a fair, somewhat standardized way to guage technical ability that mirrors the expectation of the job.

Here's what I've come up with:

Do a pair-programming style "ticket" on a new, somewhat large codebase (one unrelated to the company). This would be very similar to the candidate's first week on the job. With this setup, the interviewee would have an hour to do a straightforward task like "fix this copy" or "add in form validation" depending on their skill level. The interviewer would be there to answer architectural questions, let them know where certain logic exists, and act as an extended Google.

The goal here would be to make sure that the candidate can take a task, ask the necessary questions, and go ahead an implement it. It would be simple enough to be easily done in an hour (not a test of typing speed), and open-ended enough to allow the candidate's curiosity to shine.

What do you think?