Do technical interviews tend to be subjective? [closed]

I think your own blind spots are leading you to an assumption that is invalid as to why you don't get the job.

It is possible to answer everything correctly in a job interview and not get the job because you are competing against other people who may also have gotten everything correct. When you only have 1 job and three people you think can do the job, you still can only hire one. It's a tough market out there and lots of experienced people are looking. You never know just how well your competition did in their interviews.

Yes interviews are subjective, they are looking for people who not only have technical skills but who will fit in the existing group. Just keep trying eventually if you are capable, you will find the right place and they will hire you.

Any interviewer who dismissed a candidate simply because they didn't provide the expected answer is a poor interviewer. If a company encourages this and I get that feeling in an interview, that's a serious red flag about the team and company interviewing me.

If an interviewee provided me with an answer that I didn't think of, I'd expect him to be able to explain what the solution used is and the advantages/disadvantages of it. Like you said, there are often multiple solutions, ranging from choosing an algorithm to the syntactical structures used, and almost always there are tradeoffs involved. I'd even probe the interviewee for alternative solutions to see if they can come up with others, especially if it's an obvious solution, and ask for the advantages/disadvantages of each.

Regardless of how you run the interview, it's going to be subjective. Every interviewer, as a person, will have biases. As an interviewee, you can just do the best you can, be thorough (but not overly verbose) when answering questions, and explain your answers and how you got there. That'll take you a long way.

One that I found recently is when I said something about using an AVL tree algorithm to solve a specific problem that was asked. The interviewer asked me back: "What's an AVL tree?".

As an interviewer, I would ask that, too, even if I knew everything about AVL trees (I don't), to find out how much the candidate knows. Faking ignorance can be a trick to see if the candidate can explain well. But obviously, if you do come up with an algorithm/data structure that solves the problem, that I don't know, and that you can explain properly, I would hire you. Otherwise, shame on me. Not hiring people because they're smarter than yourself are is not a good hiring strategy.

But generally speaking: yes, technical interviews are always subjective. And they have to be. If you're going to spend 8 hours+ everyday with a person, it's wouldn't be reasonable to pick someone who manages to drive you crazy in a 60-minute interview.

Trivia Questions are anti-patterns to interviews. If you find yourself stuck in such an interview, try to direct them back to what you know. Concentrate on your resume. If this doesn't work...well consider looking elsewhere.

Interviewers should ask open-ended questions related to your Resume. While it's possible to get a feel for a person's communication skills, it's difficult to gauge a person's development abilities by simply asking questions. That's partly why so many people (including Joel on software) recommend, no require interviewees write code (and jump through several other hoops for that matter).

The fact remains that software development is still mostly about solving an unknown set of problems in an unknown amount of time. There's no set of tests that prove, ok this guy can build "a bridge". We are getting better at turning software creation into a more defined engineering process, but we aren't there yet.

The "real" technical interviews I had were all like: "Here is the problem, use these technologies, you have 3 hours". After that we did a code review and talked about why I did what I did. This way he saw what I already know and where I lack knowledgde.

Then we talked a bit about technologies and my goals in general and that was it. The interviews are, in my opinion, designed to get a feel for the candidate. You can not test everything. It takes a long time to get to know someone pretty well so that, again in my opinion, you should focus on the things that are important for you project and see how people handle this issues. The rest comes with experience over time

Im afraid that that the subjective part cannot be removed, only diminish. I frecuently have technical interviews, where the interviewer "pollutes" the interview with its own subjective ideas.

One simple example, as you mention, is that the interviewer wants an answer very close to its own answer. Another example is, when an interviewer its more interested to probe he/she knows more than the candidate. And another simple one, is when the interviewer, wants the candidate to know the specific menu location for an operation of a programming I.D.E., (Visual Studio, Eclipse, NetBeans).

I have been on several like that, and its very frustrating.

And, of course, there is also the hidden discrimination thing, where the interviewer doesn't want the candidate, from been poor, gender, political ideas, race, school, whatever you like. And its looking for any excuse to reject the candidate.

The weirdest part, is that, been an C.S. graduate, I know some psychology, (was going to study that profession), and sometimes, detect a lot of the subjective "interference". Or, when the interviewer goes to the office next door, and explicitly tells their coworkers, he / she doesn't wants to hire a candidate, for a subjective reason.

Something important, to consider, is that many Universities, or Companies, teach I.T. / Technical people how to do job interviews, and that teaching include both the technical & human factors, not just technical.

Here's how I do it:

• First I ask the candidate to solve a realistic problem. Usually this is a problem I can solve easily; usually in a lot less than the alloted time.

• Once the candidate is done; I become the student. I have the candidate talk and point through their solution and show me how they solved it. I ask questions about their ideas, and if they know of alternative solutions, and why they chose this solution over that.

Here's what I'm looking for.

• Just because I happen to know a good solution to the problem doesn't mean I'm looking for that solution. Any valid solution within the initial constraints is acceptable. I'm interested in how they planned their solution, how they used the provided tools. I'm interested in what shortcomings they are able to identify in their own solutions.

• I'm also interested in how well they listen and communicate. Were they able to understand and implement all of the initial requirements? How well did they explain the way their solution works?

At the end of all this, once I've got a good idea what the candidate is actually bringing to the opening, I might offer some of the points from my own solution, where I think my choices would be better.

If the candidate says something like "That's a good idea, I wish I thought of that," or "Oh, I didn't know about that technique," or even "I thought of that, but I used this instead" and supplies a sensible reason like "I understand this method better" or "I thought you were looking for this kind of solution", these all count strongly in favor of the candidate.

If it turns out the candidate chose differently from me, It might mean that I am wrong. Or if I am right, and the candidate is open enough to discuss the differences in solutions, it's a good sign that the candidate can be nudged quite easily to make better choices.

Here's How I know a candidate is a poor choice:

• the candidate tries to fish for an expected solution from the interviewer.
• the provided solution doesn't solve the stated problem, or somehow violates some of the stated constraints in a way the candidate cannot explain away.
• the candidate argues with the constraints to try to change the problem he's expected to solve (remember that this is a problem for which I have a solution that can be implemented in much less time than alloted).
• the candidate gets "stuck", and spends much of the allotted time doing nothing. Ideally a candidate would attack the problem from another angle or seek the interviewer to know what he should do when he cannot proceed.
• the candidate doesn't know "why" he used a technique, even if he doesn't know of alternatives. Answers like "I don't know any other tool that does this" or "I don't know how this tool works, but it does" are fine, but "because I did" are questionable.

Do you think that, as an interviewee, your acceptance of a job is not subjective, to a certain extent? Recruitment is a two way process.

As an interviewer, if I and my colleagues “click” with a candidate, they have a good chance of being in the running for the job, assuming that other factors such as a home-coding exercise and whiteboard problems go well. To “click” is to be on my wavelength, to have a fruitful conversation, to share common values about the development process. How objective can this be?

On the question of the AVL tree I would be interested in the candidate’s explaining how it works and providing insights into properties and use. To do better than the explanation on Wikipedia. Bear in mind your audience may be someone in a corporate enterprise environment where the last reference to O(log n) in a technical discussion was basically... never.

As an interviewer I want to give a candidate every opportunity to shine. I imagine this would apply to any organisation you would want to work for.

A good interviewer won't ask a question where they expect a specific answer, unless the question is something trivially simple where there's only one correct answer. A good interviewer will see how you approach a problem, how you think through it, and how you arrive at your answer - if your answer is valid they should not hold it against you because you didn't do things the way they would do it.

It sounds like you have just been subjected to lousy interviewers more concerned about showing their "superiority" to the candidate than actually gauging technical skill.

A very important skill when you work in a team is to be able to justify your own solution and fairly evaluate someone else's. You need to be able to both learn from your colleagues and teach them.

If you want to use an AVL tree to solve a problem, and the other members of your team remember them vaguely from college and haven't thought about it since, you had better be able to explain its advantages to them. If someone presents a solution you don't understand, you had better be willing to ask questions until you do. If someone presents a clearly inferior solution, you had better be able to articulate why. If someone presents a superior solution, you had better be able to recognize that and set your ego aside.

Those are the skills I look for when I ask a technical question at an interview. Whether they came up with the "correct" answer off the top of their head is largely irrelevant. That's only important in school.