Silly abstract questions in tech interviews

posted by Jeff | Monday, July 8, 2019, 7:58 PM | comments: 0

I encountered yet another Twitter post where a guy is super proud of the abstract brain teaser question he asks of interviews. Why is this still even a thing?

If you're not familiar, there is a long history of the big and famous tech companies having interview processes with all kinds of ridiculous and abstract questions. The justification for this usually goes along the lines of, "It shows how people think," or, "We want to filter out people who aren't good at critical thinking." It's usually splashed with some arrogance about how great their process and company is, and how important the job of software development is. And nothing proves that you're innovative like explaining why manhole covers are round!

Learning how to interview software people is often like learning how to exist in a relationship. So if your parents engaged in a toxic relationship, that might seem normal to you. Similarly, this interviewing process is learned behavior and I'm surprised at how often smart people persist doing things in a way that ultimately probably doesn't serve them. Microsoft used to be that way, and I know Google and Amazon often still do it. Valley startup types are known to take it one step further by testing to see if you'll even donate blood and work 80-hour weeks for a cash-out that won't happen.

I've been hiring and interviewing people on and off my whole career, and I've been a part of some really amazing, high-functioning, innovative teams (and only one of them was on the West Coast). My interviews in every one of those situations was consistent: I was quizzed on practical knowledge, applied to real situations. I was also probed for soft skills as appropriate, but never for some nebulous "culture fit," which tends to be code for "drinking buddy" or "not better than us." I was often tested for broad conceptual knowledge, but rarely for encyclopedic knowledge that was easy to look up.

Let's break it down. Hiring people is hard, because the indicators for success are really only discovered in the course of a person actually doing the job. You can usually sniff out the fakers and bullshit, but sometimes they show up and you know pretty quickly that you made a mistake. It's certainly happened to me. So your best bet is to test the ability of a developer by seeing if they can... wait for it... write code. The depth to which you do this depends in part on the career level that you're hiring for. It's not inappropriate to have a junior or mid-level developer actually write code in front of you. For more senior people, at the very least you want them to look at actual code and see if they can identify anti-patterns and ways to optimize things or design a larger system. At every level, you need to ascertain what they actually did at previous jobs, and be on the look out for "we" and "they" and no context that includes "I."

If you're a manager and accountable for a development team, then you are probably measured on things like the volume of work performed, the quality of the work, the overall execution. You aren't going to be judged on whether or not your devs know why manhole covers are round. That's not a proxy to the ability to deliver code that advances the business, so why would you assess that in your interview process? The ability of a candidate to answer abstract nonsense is only indicative of their ability to interview, not perform the job.


Comments

No comments yet.


Post your comment: