I sometimes ask candidates "what kind of interview do you feel would best bring out your strengths?" and try to adapt the interview to their response if I can. It's helpful if they want to talk about side projects or war stories, but doesn't pressure them to. I still give my coding challenge after. Wonder why no one else does this.
When hiring at scale we value consistency so this wouldn't work well. However in my company we started an initiative called "candidate experience". In one of the interviews we allocate some time for the candidate to "flex" as you put it. We ask open ended questions such as "what is your proudest achievement?" or "is there anything you wanted to tell us but didn't had a chance to?". These questions are not used to evaluate the candidate and often are no even recorded, and gives a chance for the candidate to relax and put forward their best self.
> these questions are not used to evaluate the candidate
> gives a chance for the candidate to ... put forward their best self.
How does that work? If it genuinely won't be evaluated, what's the point of getting their best self? How do you make sure things you learn in this don't affect your judgement later?
> It's helpful if they want to talk about side projects or war stories, but doesn't pressure them to.
I like leading with that, and am a big fan of the initial "what's an interesting problem you had to solve?" question, but I made the unfortunate experience that even people with good war stories are sometimes very shaky in the basics of the particular subfield I'm interviewing for. To the point of deeming someone not a good match for our team, but encouraging them and internal recruiters to interview with other teams.
There is ultimately no full substitute for getting down to brass tacks and actually do some "sample work" together. Whiteboard coding is the usual (and, I guess, often poorly implemented) approach, but I've used reading existing code, with added intentional mistakes, to great success so far.
EDIT: Just read your new reply in a sibling thread that you're doing that anyway, and project and war stories are supplemental. It seems like we're in agreement, then!
The standard coding challenge is still most of the interview, so that provides some consistency. I just want to give candidates an additional opportunity to flex, in case they feel there's an important thing that most interviews neglect. Most candidates never really thought about it, and that's totally fine, for them I just do the standard course.
As for avoiding unconscious bias, was that ever an option?
On the contrary: I like the idea, but for context, my most recent HN comment contained:
> [...] That said, I do find [it] hard in interviews [to talk] about past experience[s] and prefer to just be given a web application riddled with every type of bug and try to bingo them all in the time given to show that I understand them all. That one was my favorite interview.
Now I see johnqian suggesting to ask interviewees how to best see their skills, and it sounds great. If the interviewer doesn't have something like this on hand, we could still go into different types of bugs that they care about.
I've also had interviews that went terribly, particularly when no technical details were asked at all for a technical position (e.g. a manager just asking the standard questions where you need to give platitude answers, such as "why are you specifically excited to intern with Vodafone", methinks: "because I want that degree and you were the only option I could think of within 45 minutes commuting"... but one can't say that so I made something up.. he probed further on that... it went downhill from there), so being able to steer away from that sounds great.
But it might also be that I would feel unprepared for such a question and give a total non-answer, helping neither party.
Asking this in an email ahead of time might be better, though then the effect you're suggesting might be even stronger.
Edit: I'm not the downvoter, to be clear. I think you raise a good point even if I am not sure whether it would necessarily be that way.
Ha! One could think that the psychological screening is meaningless... until you are involved in hiring people. Of course, 95% candidates will pass, otherwise humanity would be doomed
> What are your strengths and weaknesses,.. hey what is this a psychological scan?
That's exactly what it is, and it's important. It's not helpful over the long run if we hire someone who can crank out good code, but their mindset negatively infects the rest of the team, causing morale to drop and people to leave.
I give technical interviews, but I'm also evaluating soft skills while I do it. I would rather have a team with ok-to-good technical skills, than a team with a rockstar prima donna who sabotages the cohesiveness of the whole.
Very little empirical evidence supports it, despite people parroting how "useful" it is. You're also teaching people to BS about themselves to get a job, perverting the entire thing.
If you want to psychologically analyze people, use a method which is actually supported empirically instead of the "do what every other pseudo-psychologist does" method. Big 5, for one, actually has some empirical evidence supporting it, but is barely ever used.
On the other hand, if you can actually figure people out in an hour under a single set of constraints, somehow being able to extrapolate that to the work environment as a whole, while also trying to put the work environment in a much better light than it actually is: quit your IT job now and make millions selling books.
