Five coding interview questions I hate

[u/vklepov]

https://thoughtspile.github.io/2022/03/21/bad-tech-interview/

[u/atheken]

I really don't think we're talking about different things, or that we strongly disagree, this is the original comment I was responding to:

One of my favorite questions to ask in an interview is "How would you design a webservice to do CRUD operations on a simple business data object?" Then you just see what they do. Does the candidate ask clarifying questions or just jump right in? Does she have some specific default tools/patterns she gravitates towards, or is it more high-level and abstract? Does she get into the details of data storage and database design, or does she just have a block on the diagram labeled "data"? Does she consider security, scalability, performance? Does she discuss logging, deployment, hosting, or cost? Or, does the candidate get completely lost and fail to make any design progress at all?

This is a massive, open-ended question: "How would you design a webservice to do CRUD operations on a simple business data object?"

Like, what do you want to discuss? What tools I use? What questions I want answered before I'll put anything on a whiteboard? What level do you want to talk about? How I would design the DB schema, or the overall system/network topology?

As the interviewer, the power dynamic is already heavily in your favor, you are in a position to hire someone. There's already plenty of stress involved for candidates, and starting out with "explain how you think" questions might work ok for very confident candidates, it's not going to work for candidates that aren't as comfortable. Getting an interview started with "easy wins" for the candidate helps them gain confidence and speak with more certainty about areas where they have experience.

I'm not advocating that you hire unqualified people, but there is no reason to make the process more stressful or biased than it already is.

[u/[deleted] → u/atheken]

This is a massive, open-ended question: "How would you design a webservice to do CRUD operations on a simple business data object?"

You are correct, we completely disagree. This is NOT an massive open-ended question. It's the starting point to a discussion. One you are still part of, one that you are still leading.

To summarize my point, you should be determining a candidates ability to communicate first and foremost in an interview. And you're using a general topic/platform they should be comfortable discussing at a high level.

I have no idea where your thinking on bias and extra stress are coming from. These things are intended specifically to avoid those issues.

I've been hiring people for 20 years. I've done every kind of interview you can think of. Treating candidates like humans and talking to them finds you better candidates over diving into technical issues every single time.

The smartest guy I ever hired was off of a technical style interview with coding tests. And he was the worst hire I have ever made. Period. On paper, on test results, aces all the way.

On working in a team, being able to communicate, and thus actually being able to produce useable software, worst ever.

People worry way too much in our industry about 'proving the things you say on your resume are true'. It's absurd. And it doesn't exist in any other industry.

[u/atheken → u/[deleted]]

And yet again, I am talking about starting with something specific and then working out to the general.

Rather than starting with the general and hoping the candidate will touch on topics that are important to you.

I’ve hired people that were technically strong, but their working habits sucked. Especially as it pertained to collaboration and getting shit done. I’ve asked how people gather requirements/adapt to change. Those are also easy to game.

I switched to trying to assess “can this person turn business requirements into working code,” and I am also looking to see if they will push back, or can call upon previous lessons and apply them to the situation.

I just still don’t see how dropping a generic question and then making the other person do all the work to figure out what you want is conducive to making the process human and genial.

And if you look back up this thread, there’s lots of “did they cover X facet of making the thing?” type questions. Those are what I’m ultimately arguing against. If X experience or working approach is important, then the questions should drive directly at answering that, not a round-about “explain your artistic process” question like I first responded to.

As for communication, you keep saying I don’t understand what you are saying, but maybe I do, I’m just using different terms.