[ellius]

Here's mine:

1. I ask about prior experience, following up on any interesting resume items or comments. I try to act like a "biographer" (per the book "Who") and just learn their story.

2. I ask them to describe data flow in a basic web app. If I push this UI submit button, explain the progression of data from the client to the database.

3. I ask for an explanation of core concepts of the framework I'm interviewing for or any one they've used.

4. I ask about version control concepts and some specific git commands.

5. I ask about prior team practices, e.g. what types of meetings they have and what the interviewee thinks of their effectiveness.

6. I ask about their knowledge of ops/DevOps, e.g. explain how a pipeline works.

7. I ask about basic CS/object orientation/language concepts, e.g. static vs. dynamic typing.

8. I ask what their most interesting project or story was and why it resonated with them.

9. I ask what their toughest debug was and how they solved it.

10. I ask about their experience with testing and opinions on how best to do it.

Between all that you get a pretty decent picture of what level they're at and what is their capacity to learn.

[MperorM]

My problem with this style of interview, is that someone like me, who is a mediocre programmer, but stellar communicator will fare MUCH better than someone who is a brilliant programmer but poor communicator.

I spend lots of time reading about smart people's opinions on programming, and will be able to recite that knowledge and play it off as my own hard-earned experience. I could talk for an hour about tradeoffs between Vagrant and Docker, without ever having spent more than a few hours actually working with Docker.

If the interviewer is really sharp they could maybe dig deep enough until they see that there's nothing beneath the surface, but I suspect most wouldn't do so even if they were capable.

[ellius]

It depends on what you need. If I need a Docker expert, you can be sure I'll tailor my interview to a Docker deep dive with very precise and detailed questions about commands, concepts, etc. The first step in any interview process should be to think very clearly about what you need and to then adjust any template you have to those needs.

[MperorM]

Yeah, I was mostly thinking in the context of a junior role. Generally bullshitting of any kind will be caught out. My point is not that someone could bullshit their way through an interview of this style. It's rather that I think it unfairly favours people with a lot of general and high-level knowledge, over someone with strong fundamentals.

[cjohnson318]

This is a very good list. I especially like asking number 8. If they can't talk about something they were passionate about, then that's a red flag.

I also ask people to implement the Blum Mental Hash, which I heard about on NPR in 2014. It's easy enough to explain in five minutes or so, but difficult enough to write out in a half hour or so.

https://scilogs.spektrum.de/hlf/mental-cryptography-and-good...

[sh87]

This is good, no doubt, but judging programming ability based on how they answer these questions is severely prone to fail because 1) this relies heavily on the interviewer's skills and 2) its so easy to game this system.

I've had so many co-workers talk, passionately, about stuff they don't have the faintest scent about. It's shocking.

Unless you actually oversee a candidate work and reason through a representative problem, implement it and articulate it, there's no good way to gauge competence.

[ellius]

I actually agree with that and think that's something I need to mix in. But I will say it's hard to bullshit your way through every one of those questions. I've had people BS through 3-4 but pretty much inevitably they fell apart on the others.