(3) is biasing the process strongly in favour of people who spin a good story. If you're looking for a certain team culture then OK but this is going to neatly screen out anyone who just wants to do their job well and doesn't particularly know how to sell the extra-curriculars they have.
Sure, they can do that. Then the average interviewer is going to recommend hiring the person who was the best at spinning a good story rather than the person who has the clearest explanation (which might easily come across as boring or simplistic). The problem here isn't getting through the interview; it is what the interviewer does next in the hiring pipeline.
Somehow this reminds me of my old physics professor, who often had simplistic, almost boring explanations of things, like jiggling atoms making friends with each other, or how a train stays on the track.
... Classic interviewing techniques of "explain how X algo works" or "write code to solve Y" will unfairly bias against interviewees that don't test well under pressure, but would otherwise be a good coworker.
... "Teach me something interesting to you" or "tell me stories about past experiences" will unfairly bias against interviewees that are shy, soft spoken, or are mildly socially awkward, but would otherwise be a good coworker.
Given the above awareness of where bias can emerge, how should the interview be done in order to get a candidate that knows what they're doing, and works well with the rest of the team?
Other comments mention relying more on recruiters and referrals, but that isn't always an option.
I don't see what useful signals are supposed to come out of an interview. If referrals and recruiters aren't an option I'd probably try to skip the interview altogether and go with a long probation period (3-6 months). Or possibly have a short 20 minute free-form interview talking about their last day job and expectations of the new one with a very short list of major red flags ("doesn't want the job", "unable to form sentences") then block candidates who raise them.
- How do they take a business problem and model it into code
- How do they debug their own code
- Is their code easy to read
- Do they name their variables/fields/methods/classes in easy to understand and consistent ways or are the names confusing or inaccurate
- How do they take constructive criticism
- How collaborative are they
- Do they think about the problem first or do they just start hacking away
- When asked to add a feature to existing code, do they start hacking or do they write out a test describing the new functionality first
- When confronted with vague requirements, how well do they ask questions to get the information they need
- How much experience do they have with algorithms, database design, systems design, building things so they scale well
If it were possible to work all that out in the interview then there wouldn't be any bad hires.
As a wishlist I like it, I just don't see how you're going to assess all that in an interview. You'll notice that the technique of the day ("teach me something") doesn't address any of the dot points and that holds for ... pretty much any technique. Interviews are a weak process for assessing anything.
The long probation approach completely ignores the very real costs of onboarding someone new.
It takes time, money and people to bring someone in, and hiring is actually quite a risk for many companies (unless they're huge and/or in a hiring frenzy).
If a candidate doesn't work out, that's a lot of time and money down the drain, and potentially lost work, and disruption to teams and timelines, etc..
Most people don't get this part, and I think that's why they don't understand why interview processes are structured the way they are.
You really want to do the best possible evaluation, on all fronts, at the start. The longer a bad candidate stays in your pipeline or company, the more expensive and disruptive it gets.
Specifically for engineering I think it could work if you really press on that it's about teaching something. A core part in an engineering team is to walk eachother through concepts, so judging how you can explain concepts to someone is actually a good thing i believe?
A big part of any engineering job is casual technical communication. This seems like it's entirely fair line of questioning. And the candidate gets to pick their strongest topic. What more do you want?
I don't think this approach favors the talkers / story spinners too much. It is the other way around!
It is a nerd test. You can get every nerd talking if you ask them to tell you about a special skill or project they really care about.
I remember quite a lot of these lunch conversations:
Me: Hey, what's up? Do you like the salad?
Introvert Nerd: Mmmm-Hmmm.
Me: Great weather outside!
Introvert Nerd: Mmmm-Hmmm.
Me: I was hiking last weekend in the mountains and got caught in a storm.
Introvert Nerd: Mmmm-Hmmm.
Me: Does your work project proceed well?
Introvert Nerd: Mmmm-Hmmm.
Me: I've heard that you regularly cook medieval dishes and you created a food medievality detector using a Raspberry Pi and a horseshoe?
Introvert Nerd: Oh, yes! You know, measuring the medievality of a dish is not as simple as it sounds! Obviously, there are no American foods like tomatoes or potatoes allowed, but did you ever think which spices were common in Europe in the High Middle Ages and why that changed in the Late Middle Ages...
...
The problem is in leaving the topic of what to teach open. To some people, this may feel like freedom. To others, in the context of an interview where the purpose is to judge the candidate, it will just lead to a bunch of stress from trying to guess which types of things to teach are currently a la mode on the interview circuit.
For a fairly casual question I'd see it more like an ice breaker or a way to build some rapport, but it's down to how you ask the question as well. Letting people know in advance (as the parent suggested) rather than dropping it on the fly is a good enough accommodation for people who would be anxious about that.
I find interviews quite tense and I generally dislike having them (on both sides of the table), but throwing in a few disarming questions here and there throughout really takes the edge off. A conversational, or more cerebral, approach like that can suit some people far better than live code tests or quick-fire Q&A.
