TL;DR
Everyone claims to be an "expert" in their thing. The reality is they rarely are. They either honestly think they are, or they know they are not but adhere to the George Costanza philosophy to lies, "It is not a lie, if you believe it". Which is the honest version of the toxic "Fake it until you make it!" advice.
Took me to long to figure this out
After almost two decades of doing technical interviews I have been able to distill a technical interview down to just two questions.
And my "technical" interviews, I mean, does someone really know the subject they claim to know and how well they actually know the subject.
I can end an interview with someone that claims to be an "expert" quicker than someone that claims "intermediate/competent" or "beginner".
This is the hardest question you can ask someone.
- "What do you like best about <insert technical skill here> ?"
The only wrong answer to this question are non-answers.
Answers that do not directly specifically answer the question with an opinion are non-answers. These are answers that do not offer an opinion because they apply to anything.
Here are some examples of non-answers:
- "I like everything about ..."
- "I like it because it is popular/easy to find work in/etc"
- "I like it because it is easy to use"
These types of answers are immediately disqualifying. But just to to make sure they are not just being shy or evasive because they do not want to come across argumentative or insult something that I might not agree with I prompt them for something specific.
Like "Why do you think it is easy to use", "Why do you think it is popular", at least those answers give you something to follow up on and see if they are just bad at giving opinions and expressing themselves and actually have a opinion in there somewhere.
Granted, you can have too much of a "weak personality", just as you can have too much of a "strong personality". That is not about technical interview stuff, that is more about, person than what the person knows or does not know about something.
If I still get a non-answer, after some leading follow up chances I move on to the next question, which should be guaranteed to draw out an answer for everyone.
And like they Daily Double on Jeopardy gives them a chance to dig themselves out of the hole they have dug.
This is the most softball question you can ask someone.
- "What do you like least about <insert technical skill here> ?"
A strong answer here can rescue the interviewee from a non-answer from the first question. And give them another chance to revisit the first question in the context of this answer.
Now everyone has something they hate about everything, especially things they are extremely knowledgeable about, even beginners have stuff they hate.
Every Java programmer hates the original Date class, regardless of their experience level. Same with the boilerplate verbosity.
Every new Go programmer starts off hating error handling in Go. Even most intermediate and a few experts hate on it, even though they understand it and realize it is a reaction to try/catch and is a better solution.
Ask a couple about what they like/love about their partner and you will get some generic stuff or one or two specific things. Ask them what drives them bonkers and they hate about their partner and you will get an "ok you can stop at any time list". And the longer the relationship the love/like list does not change in length, but the hate list will have grown.
A non-answer here is pretty much "That's it man, Game over man, game over."
I am going to wrap up the interview as quickly and politely as possible.
What the answers mean.
Here is how to score the answers.
You are looking for opinions, the more experienced they are the stronger their opinion needs to be, and the better they should be able to articulate why your opinion is what it is. Whether you are agree or disagree and to what extent is irrelevant at this point.
On a scale of 1 to 10, with a non-answer being a 0 and a really passionate opinion with a well thought out and reasoned argument supporting that opinion, even if you think they are absolutely wrong, should score a 10.
I weight the "like/love" question higher than the "dislike/hate" question. Simply because negative feedback is always easier to solicit than positive feedback.
The reason this is such a powerful and effective approach to technical interviews is it gets you to the "I know enough that I do not need to know anymore" point very quickly. And it gives you a platform to get some back and forth engagement with the other person and see how they think and why they think what they think.
It is easier to dig into someone that you disagree with their opinion than when you agree, so even if you agree with their opinion on what they like/dislike and why, you should still take the contrary side and play the part of someone that disagrees with them.
This gives you detailed insight to their thought processes, but it also gives you some insight into their personality; how someone argues tells you a lot about how they will fit into the team.
You want experts that can argue persuasively and effectively, you need them to help drive growth in the less experienced members of the team as well as use them to convince peers and higher ups why what they want you to do is not the way something needs to be done.
Even if someone is not a very senior expert personal technically, if they have opinions that means they are learning and if they can argue effectively and persuasively they are way more valuable than someone who is an expert level but is ineffective a arguing their position, or worse someone who can win an argument but lose the respect of everyone in the discussion in doing so.
If you do not believe me
The brilliant thing about this approach is, it does not matter if you are an expert in the technical subject, you can find out if the other person is just by their answers.
Call up a friend, tell them you want to practice some new interviewing approach, but do NOT tell them what it is.
Ask, them to self assess if they are an "expert", "intermediate" or "beginner" in the subject. This is like question zero, usually resumes will tell you what the person thinks their skill level is, or it is implied by "years of experience", which is a false measure, but that is an entirely another article.
Then ask them these two questions I detailed above in order.
The order is important, just like I presented them. The "Like" question and then the "Dislike" question.
If they give you non-answers, that is ok, it gives you a chance to practice the follow up, redirect approach questions I mention.
It is amazing how quickly you can get into what someone actually knows or does not know with this approach.
Top comments (16)
This makes sense. Thanks for writing this.
Although I believe folks who are not able to answer these, may still be good.
As in most folks aren't much interested in their tech, only parts that get's the job done.
These questions however do help in indentifying wether if someone is passionate with their job or not.
that is why I said, almost answers get follow up questions to drag something out of them. honestly, I do not want someone that does not have an opinion on my team. fry cooks have their opinions about what they like and dislike about the equipment they use to do their jobs, someone that uses technology specifically should as well.
This is actually a good litmus test tell if someone is really interested and invested in what they are doing, which is something I would expect from any dev I hire. Because if they're not that interested in development, they should probably be looking for a career that does interest them, and I've had that conversation with a few people over the years.
someone with 8 years experience and has no opinions about what they like and dislike about what they claim to have dedicated 8 years of their lives too iss a valid disqualifier. I mean after 8 mins of just reading about Ruby I knew enough to know I did not need to know anymore and had a pretty well formed opinion about why that even my biggest Rubist friends could not argue with.
Interesting, can you conduct a quick interview for me?
sure, hit me up over my email
Brilliant!
Love this. I'm long beyond having to do coding interviews (self-employed contractor) but I kinda wish someone would ask me these questions about my main language... I could opine all day. 😁
I'm a Junior but I would ask: "Do you like this language/framework?
Interesting perspective, good read! Thanks for writing this :)
yeah that is all nothing more than ego stroking and/or gatekeeping unless the job they are applying for is to invent and implement programming languages.
your approach is just looking for people like YOU, my approach is identifying people that are good at what I need them to be good at, and that is usually not ME. I need people that compliment me and the team, not a team of me. That would be a disaster!
just like asking interviewees to whiteboard code to reverse a linked list without using intermediate variables when the language they will be using every day is Java, Python, C#, etc. and anything but C. Languages that basically have a generic reverse list function built into their standard library.
I just excused myself from interviews that demanded stupid gatekeeping stuff like that. I learned after the first contract i took a place that asked me that as the qualifying question was a toxic environment of has been C programmers that just wanted to talk down to anyone that was not some kind of C guru and bitter about being forced to write Java code themselves all day. This was early 2000s. Life was too short to deal with people like that 23 years ago, definitely would be today.
unless you are hiring someone to design and implement languages, this is a exercise in showing them how much you know about designing and implementing languages and validating that you are the expert over them.
nothing more.
you would not have a limo driver design and implement an engine, transmission and all the other parts of a car if all you were hiring them to do was to DRIVE a car. That is an interview for a mechanical engineer not a driver.
Same with your interview, you are not interviewing for what they are going to be doing, you are interviewing on what YOU value, you are looking for YOU in them, not who they are.
It is your personal lack of experience interviewing if you can not determine if someone is knowledgeable without demanding for them do free work ...
Lots of places like to interview people and have them design systems just so they can get free consulting on something they are working on. Had it done to me, many times over the last 3 decades.
If I was given this exercise during an interview, I'd honestly walk out the door. What you describe is a major red flag of management style. Others already pointed out that this is basically an ego trip, and I honestly read it exactly the same way before I even saw their comments.
And as a note: I say this as someone who did invent a scripting language from scratch about 20 years ago when developing home automation software, and then later using Lua in several projects.
Much like OP, I can get the same level of information out of a candidate in a 10th of the time just by having a basic discussion vs having them write a single line of code.