Comment by magnetic | Hacker News Reader

Comment by magnetic | Hacker News Reader

Parent Full thread

I wonder if one way to help this bias is to have interviews be an exercise in teamwork rather than a lopsided relationship as it is now.

What I would suggest is that when the interviewer and candidate get reach the "quiz or coding exercise" part, have them pick a question from a website that provides a question at random, and let both work together towards a solution.

This matches more closely with what they will end up doing anyways if the candidate is hired, and will remove the "I've seen 20 different ways to solve this" bias while also generating empathy for the candidate when the interviewer him/herself also struggles with a fresh problem.

Of course, the interviewer can try to lead the candidate and can hold back from telling the solution right away if s/he can clearly see it, but if not this could set the stage for a fairly realistic way to sample all kinds of qualities, from technical, to communication, to empathy, to teamwork, etc...

I think it would also be less stressful from the candidate's point of view: a candidate often feels like an interview seems unfair because s/he is being asked about something that the interviewer has had a chance to review and prepare much in advance.

When interviewers ask trick/complicated questions, I sometimes wonder what would happen if they were to ask the same question to the rest of their own team. Are they expected to answer it well? Would they know? Think about the places you've worked and the questions you've given at interviews: do you think your own colleagues would have aced them?

Obviously, this doesn't completely remove the additional stress on the candidate, since the interviewer's job isn't on the line, but I think it would provide a more balanced assessment of the candidate's abilities and personality traits.

In practice, I'm not sure interviewers would be very receptive to such method, as it could turn an interview into a stressful event for them.

I've had a very similar idea to this as well.

It all stemmed from one particular interview I had years ago. The interviewer presented me with a very simple problem, I solved it. He then stepped up the difficulty a bit. This kept happening and as it got harder he started acting more like a co-worker where we bounced ideas off of each other.

Granted he knew the solution, but the mere fact that he presented himself not as an interviewer judging my performance but as a co-worker helping to solve a shared problem made that one of my favorite interviews.

That does sound pretty good - what company was it at?

It was for Amazon. I will say I had 4 or 5 other interviews at Amazon that day and most of them weren't nearly as good, one was actually atrociously bad.

They may have changed their interview process at this point though, I only interviewed for them that one time and it was quite a few years ago.

I’ve had two very similar experiences as well. They were back-to-back interviews and in both the interviewers started simple, then stepped up the difficulty. During the whole process the interviewers worked with me, not against me. Of course the questions became hard and they were clearly looking for a good answer, but the whole process did not feel antagonistic at all.

You don't even need to randomly select a question to do something like this.

In the past I was hired on the back of simply sitting down with the team lead, and us pair programming to implement what he happened to be working on at the time.

That gave a good idea of how quickly I could start contributing, how easy I was to communicate with, whether I was going to be a snob about the existing code, whether I have relevant pre-existing knowledge about the technologies being used and whether I had any interesting insights to offer. There was also a more standard interview process accompanying this (which I doubt I excelled at) but the pair programming excercise gave a real world insight into exactly what I had to offer and what I was like to work with.

I once saw a company that interviewed like this. The also paid the candidate for the afternoon. The thinking was if you are working on our codebase you should be compensated.

For the record, half of the technical part of Canonical's engineering interview track is collaborative; multiple candidates join in to troubleshoot in real time a system that is malfunctioning. We gain from that a lot of insight into how people work together and what strengths they bring to a team. I haven't seen something like this used anywhere else.

As an interviewer I'm going to give this method a try. I will also add a step to our hiring process where we solicit opinions from the team about how well they felt the interviewee did at communicating during the exercise, as this is a major part of any real world work.

I don't think the fact that the interviewer choose the same quiz all the time is the culprit (on the contrary i would say, because it helps establish a benchmark and understand the pitfalls of that particular question).

The problem is that getting the answer correctly shouldn't be the main goal of the quiz question. Rather, it is the opportunity to see how the candidate think, and how the person is able to work with someone else (aka the interviewer) to solve a given problem.

It could also be a way to make sure the candidate understands a few concepts of its field (complexity, memory pointers, etc).

Mainly what matters is the process, not the solution.

Back when a was a tech lead and made hiring decisions for my team I would run the questions I asked candidates by the rest of the team in a 1:1 setting. We were checking that people could answer the questions well -- and sometimes when they couldn't it could show us weak points and give us ideas for training.

I always ended those 1:1 sessions by asking if the team member would be comfortable working with people who couldn't get to the correct answer. And if they could, what they would want to see from a candidate working on the question.

I really like the idea of picking a problem together and working through it. I might try that in my next interview!

Reply on news.ycombinator.com