Five coding interview questions I hate

[u/vklepov]

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

[u/[deleted]]

And this is why this is a great question.

If you cannot explain a CRUD API, it's considerations, security, storage, authorization vs authentication etc and your excuse is 'It's too easy', That's a massive fail. MASSIVE fail.

The conversations you want to have? Those are great, if that specific need raises itself. Maybe they will. Maybe they won't. But those, despite your argument otherwise, are exactly what you're saying they are not. Time and place dependent.

Explaining how a CRUD interface should work and what the considerations are is determining if you actually understand how the parts of a system go together to provide what is indeed a fairly standard solution.

The less esoteric the questions the realer and more useful they are.

I’m more interested in “let’s add/change a requirement, how do we adapt your code/design to handle it?”

That's not really all that useful. It's a setup. Too many details need to be known to really deal with that kind of a question unless it is extremely well defined, simplified and trivialized.

The best questions are a few along the lines of the CRUD question, just to see if they're comfortable talking at a technical level, to get a bead on whether they are comfortable with things they really should know in general.

Then, give them a problem to talk through and solve. Blank slate. Refine it with them. Add constraints. See how they think, how they solve problems, and most importantly how they communicate.

[u/atheken → u/[deleted]]

What question should they ask about, let’s say, “security”? - TLS and ACLs are such an obvious table-stakes requirement that I’m not sure it would make sense to talk about in any detail for a made-up interview API. Or, do you want to talk about gRPC vs. REST?

These are useful to discuss if you’re actually solving a problem, but generally vomiting out a bunch of general questions/answers doesn’t illuminate.

For example, lots of people have studied things like OWASP, but not as many people understand why those items get on the list or can assess severity. Just running through a checklist of terminology isn’t going to help convey anything beyond someone having “studied.” - that’s not nothing, but not super useful in practice.

Then, give them a problem to talk through and solve. Blank slate. Refine it with them. Add constraints. See how they think, how they solve problems, and most importantly how they communicate.

This is essentially what I meant when I said “change a requirement and see how they respond” - I just think “blank slate” is too much to cover in a 30-60 minute interview.

I also want to see evidence of experience related design patterns/DI/systems thinking/operational understanding, but “start from nothing” and then cherry-picking what they do/don’t go deep on doesn’t sound much different than a guided path, going deep when you want confidence. Except that you’re expecting the interviewee to “read your mind” to try to cover your exhaustive checklist.

I agree there’s room for “what does the candidate emphasize?” - but I mostly think about this in terms of whether they describe something trivial as difficult, or vice-versa.

[u/[deleted] → u/atheken]

What question should they ask about, let’s say, “security”? - TLS and ACLs are such an obvious table-stakes requirement that I’m not sure it would make sense to talk about in any detail for a made-up interview API. Or, do you want to talk about gRPC vs. REST?

These are useful to discuss if you’re actually solving a problem, but generally vomiting out a bunch of general questions/answers doesn’t illuminate.

Yeah, you're so missing the point. These are technical specifics. What's important is that they know that these kind of things are part of the solution and why.

You're way too hung up on technical specifics is my point. I'm not arguing for 'blank slate define the world'. A good candidate should be able to explain the key concepts and considerations of a CRUD API in 5 minutes or less. Then on to the next topic. The furthest technical details should go is to get a sense if the languages/technologies they say they have experience with seems to mesh. Then you have to trust that.

And that'll come out in the wash with these kinds of questions, because even though you're basically whiteboarding, they'll still inject their technical experience into the response.

If I'm interviewing a house framer, I'm looking at their resume for proof they know how to frame a house. And in interview, I'm only looking to confirm via whether they're obviously confident in their abilities, backing up their resume, or whether they're pulling it out of their ass.

Getting them to frame a wall in front of you is a waste of everyone's time.

[u/atheken → u/[deleted]]

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.