How technical interviews could work

Because the current state of the art is broken

Recently, there’s been a spat of articles about how the hiring process is broken in our industry. One in particular was rather popular. Over the weekend, I commented on joke about technical interviews, and how we do it at my work, and I got a relatively strong response.

Clearly, there’s something to this idea. So let me show you how we try to do it where I work.

I work at an agency.

We have a standardized stack. (I’ve mentioned before some of the benefits of it.) We use Django (and therefore Python) on the backend and Bootstrap and jQuery on the frontend. If we need to do something SPA-like, we use React.

Because these things are true, we can offer a small, standardized project (like a recipe database), tell applicants to do it in our specific tools, and then do a code review of that project.

So our interview process looks like this:

1. You apply

2. You get screened for the minimum years of programming experience by the screener; we aren’t opinionated about what that means exactly.

3. You complete the standardized project. The project is intentionally on the small and easy size — an hour or two if you’re proficient in the language and framework.

4. A developer reviews that project internally and makes comments on it.

5. Finally, the reviewing developer walks through an interview with you. You explain your decisions, and provided you followed the spec, wrote quality code, and can discuss what you wrote, congrats! You’ve passed the technical interview.

Guess what’s missing in all this. No white board puzzles. No silly algorithm tests. No quizzing you about abstruse language features. No dumb brain teasers. Basically, it’s a code review.

This entire ordeal is relatively straightforward, and guess what? It actually relates to the job you’ll do.

I realize this may not work for all circumstances, but I think it’s worth others thinking about.