"You know, when I did my first six week introduction to programming course, the highlight of the final day was getting to use the computer"

"Hahaha, hard core!"

"Glad you think so. This interview will be conducted under Faraday Cage Rules; this laptop runs Minix 2.0 with full source code and manuals. Here's the Book. You have one hour to complete exercise seven from Tanenbaum chapter 5."

#Tootfic #MicroFiction #PowerOnStoryToot #Title_Faraday_Rules

@Unixbigot For job purposes I don't think having an exam style coding interview is useful*. I want to know how you approach problems, how you work with people and get requirements and adapt to problems. If the tool fails you want resources do you employ? If the magic button doesn't work can you work past that or do you just keep pushing it to see if the magic will happen**.

I've bombed a coding interview because I missed something, went the wrong way and ran out of time. I wouldn't have hired me after that, but also that's an unrealistic scenario and the time pressure is not useful. In practice going the wrong way sometimes gains you understanding that leads to better results, filtering that out in interviews seems bad.

The other thing that makes giving a code interview challenging is "I know exactly what needs to be done because I've seen this before, they should do that" when there are many valid solutions and the idea is not to replicate what I would do, it's to see that they can work towards meeting requirements.

*I am not convinced by interviews in general, but that's a whole thing I am admittedly not any kind of expert in.
**there's a story here but not one I will post publicly

@abstractcode me too, my IRL hiring process is two interviews max (no gotcha questions or puzzles, and the second interview only when unsure). I've been subjected to tests that rejected me for jobs I was expert in. I've written tests and seen them give the same result, and given up on using them.

@abstractcode @Unixbigot

This is how I would hire people. Until HR declared we had to give people contrived tests to make sure they knew a thing.

In addition to your list, how have you demonstrated continuously learning? Did you learn a new language? Did you have to learn a new library? Kubernetes? Migrate things from the cloud and have to figure out how to manage hoards of servers?

Asking meta questions about how folks approach problems, learn, and so on will uncover any complete lack of knowledge of a given skill.

I still think there’s value in asking someone how a keystroke translates into a web request. Go into as much or little detail as you feel appropriate, ask questions, etc.

Giving tests is flat out lazy.