Never, ever ask questions about esoteric knowledge of a particular technology. In my experience, this has almost null relevance as to how a person will perform on your team.
The source of this post in my brain started when I stumbled upon an article tonight entitled “Front-end Job Interview Questions“. The absurdly long list of questions in the article is exactly the kind of questions that you should NOT ask. Ever.
All these questions do is scream, “I’m an egomaniac who has spent vast amounts of time Googling this nearly useless knowledge, but will ask you to regurgitate it to me without the aid of a search engine, and then judge you on how much it makes you sweat.”
Look, I get it. We’re geeks, and without some basic training and/or experience, we think that everyone should have an encyclopedic knowledge of our most treasured technologies and tools. However, even if a candidate does somehow have this knowledge miraculously stored in their memory, it doesn’t mean squat.
Think about the best group of people you’ve ever worked with. Then think about the biggest jerks, assholes, social misfits, and douchebags that you’ve had to endure over the years. Did their level of technical knowledge ever matter when you determined their value as a team member? Of course not.
Some of the most technically talented people I’ve ever worked with just so happened to be colossal jackasses that I could have invited over for dinner, fed them their own brains, and then gone to sleep with a smile on my face. Conversely, I’ve worked with people who were adequate with technology, but also managed to be great, passionate people and invaluable teammates that I would work with again in a heartbeat.
I was fortunate enough to work with a fantastic group of people when I was at DaVita. As it is with most IT shops, there were many layers of innate technical talent on the team. Some people had to put in that extra couple of hours to achieve the same results as someone else who had it come naturally.
We had a contractor once whose brain thought in Oracle. He could tweak performance and results out of queries and other aspects of the database that I couldn’t achieve in a lifetime of study. He also had an incredibly helpful and passionate way of dealing with others, and when he left the company we all felt that we had lost not only a great asset, but a friend.
When I joined the company, and then we started hiring other front-end developers to join me, I had a two pronged approach to interviewing. First, a five question technical quiz that filtered out the inexperienced. It doesn’t take 50 questions to determine if someone has the chops or not.
If they performed adequately at that, there was a face-to-face interview at which I had three additional scripted questions. They are meant to start a conversation, not test a candidate on how much they’ve crammed into their short-term memory from Google in the past week preparing for your onslaught.
If someone proves that they have the bare minimum of technical prowess, then all that’s left is determining if the candidate is (a) a smart and critical thinker, (b) passionate about anything, and (c) bringing anything of value to the team.
The dirty little secret that I don’t mind saying is that software development isn’t hard. There’s lots of handbooks, manuals, blog entries and Stack Overflow Q&A pages out there that very clearly describe how to work with any development language or tool. Follow it step by step and you are a software developer. However, keep in mind that it is also very easy to hold a paintbrush in your hand, and swirl oil based paint on a canvas. Unfortunately, Rembrandts and Degas only come around every once in a while. The mechanics of software development are easy to learn, but incredibly difficult to master.
The real issue is that hardly anyone has the disposition to be a software developer. The mind numbing attention to detail. The absurd amount of time it takes to debug the simplest of issues. The complete and utter need for total concentration for hours upon end in order to complete the basic tasks of the trade. In short, the passion for developing software.
Not many people are wired this way. The ones that aren’t, but are in the field anyway, are very easy to pick out. All it takes is a 20 minute conversation about anything but technical minutiae.
Update – This silly article I wrote at 1 a.m. last night before I fell asleep has certainly touched a nerve (either positive or negative) with a lot of people. Let me clarify one thing that many readers seem to have misinterpreted. The point of my three seemingly non-technical questions asked in a face-to-face are meant to lead to a discussion about technical issues. Yes, some people will throw bullshit at you, and if you can’t detect the bullshitters, then you shouldn’t be interviewing people.
18 Responses for "What not to ask technical people in interviews"
You’re exactly right. I’ve been through job interviews where they’ve asked me something super specific about some feature of the language and I’m left digging through my memory banks for an answer. If I can’t recall anything useful, I usually just say that I’m familiar with the topic or concept, but I’d have to look up the specifics. Some people will ask those types of questions just to gauge your familiarity with the topic and they’re not expecting you to regurgitate all the specifics. Those are the types of people you want to work with, not the egomaniacs.
Like you said, it’s more important to ask questions that help you determine if the person is passionate about development and a desire to continue learning new concepts and technologies.
Some of those questions really are stupid, but others are good. Similar to what Josh mentioned, when I ask questions I am looking to gauge their familiarity with the topic, rather than see if they know specific answers.
Would you hire a web developer that has never heard of minification? I think this is a great question. If you are any kind of decent developer you should know what this is.
And if they have at least heard of git or github, I know they are not a 9-5 corporate developer that only codes while at work – they have at least a little clue into whats hot in the software development world right now.
I always ask a question about favorite blogs, too. If they don’t follow any sites or blogs, there is a larger chance they just there to get a paycheck and aren’t really curious or passionate about development.
If you want to test for intelligence, ask for a writing sample. While it’s sometimes the case that a smart person is not a good writer, it is never the case that a stupid person is a good writer.
If you have a good writer in front of you, then you also are in the presence of a smart person.
>Would you hire a web developer that has never heard of minification? I think this is a great question. If you are any kind of decent developer you should know what this is.
Unless, of course, the minification tool they use is Google’s Closure Compiler. In which case, they probably think of it at a “Javascript Compiler” rather than a “minification tool”. I had no idea what you meant by “minification tool”, despite having gone to a talk on the architecture of CC by the Google Engineers who created it (I’m not a web developer, but rather a former compiler developer).
Which, I think, demonstrates the problem with this line of questioning. Take a web developer who started at Google right out of school. It doesn’t matter how good they are, or how much they understand and appreciate Javascript minimization: they’re almost certainly going to stumble on “What does ‘minification’ do?”. Because that question doesn’t really ask if someone understands Javascript minimization. Rather, it asks “does this candidate use all the same terminology I do?” Which isn’t really that important.
Do you have any examples that you think are good answers and bad answers for this:
Why do you want to work for us?
Ryan asked, “Would you hire a web developer that has never heard of minification? … If you are any kind of decent developer you should know what this is.”
I’ve designed hundreds of sites and never heard of it.
Let’s see, googling.
Ah, you mean stripping white space and obfuscating the code before going live. Yeah, I do that sometimes. I find it funny though when guys will pull in 5MB of javascript and 20MB of graphics and flash ads and their site takes 3 minutes to load, but by god they’ve gotten it minified.
I also think asking those questions is a bit much. And, as you said, what does it really tell you about a candidate?
To me, the 2 most important aspects of hiring someone are (1) their ability to get along with the team and (2) their ability to communicate. Neither of those abilities can be judged by technical questions. You need to determine their personality, and try to figure out if it will work with the rest of the personalities on your team. After that, since very few people develop alone, you need to see how that person communicates issues of a technical nature, especially to non-technical people like project managers or clients.
I like the approach suggested in PeopleWare (I think it was PeopleWare, anyways), that said you should avoid the interview almost altogether. Instead, have them do a presentation on a project they’ve worked on or something else of a technical nature that they’re passionate about. That way, you could judge what they like, what they know, what type of things they focus on, and how well they communicate.
@Ryan
Yes, I would hire a developer who hadn’t heard of minification. Do you know why? Because it takes 2 minutes to teach someone what minification is and how to do it. How long does it take to teach someone to change their personality to fit into the team? How long does it take to teach someone how to communicate better?
My point: most technical aspects of web development can be taught quickly, and thus, are far less important than the non-technical aspects of a person that would take much longer and a lot more effort to change.
@Jan, well considering images load AFTER DOMContentLoaded and JavaScript runs BEFORE. There is a huge difference in the time that someone waits for scripts vs images to load. Check out http://backbonejs.org/ for instance. Hugely fast to load and interact, but all the sample images take a while to download. These images don’t affect any of the functionality in the site.
This is why you quiz candidates with technical questions. Had you said that, I’d be very concerned with your technical understanding of why minification exists and the problem it solves in a remote resources environment. (Especially with regards to mobile connections).
Some of us are being paid to solve problems that haven’t been solved before, thus the idea that “coding is easy” and the ability to “Google for the answer” aren’t viable. A candidate’s experience, knowledge and intellectual prowess are of prime importance, asshole or not.
Agreed, Joah, but you miss my point, I believe. It is a subtle difference. Software development is easy, much the same as holding a paintbrush in your hand and swirling color on a canvas is easy. That’s my point. Also, “Google for the answer” is viable for learning the “how” of development. Not always the “what”, and never the “why”.
I definitely have to agree.
We’ve been interviewing people recently for asp.net development and QA positions. I’m not officially a developer (application engineer/product manager) but I learned how to do development from scratch after joining the company (I studied electrical engineering in school) so I know it’s not hard to learn if you are “wired for it” as Steve mentioned.
Therefore, I was less concerned about their intimate knowledge of advanced web services or whatever and was more concerned with the things Steve mentioned in this article. We had one candidate that was very good from a technical perspective but he just didn’t feel like that good of a fit to me. Good or bad, he was hired by another company and instead we hired someone with less technical knowledge but who was very excited to learn. She has already started contributing to the team to help improve our web-based application in her first week.
This just reaffirmed to me that how they fit in the team and how enthusiastic they are to learn is just as important (if not more so) than what they already know.
Then I have to ask, do you list a 4 year computer science (or similar) degree as the one of the requirements for the position? I have read of other firms that “claim” to have a similar mind set as yourself, yet will disregard 5 years programming experience because the applicant either doesn’t have a degree or it isn’t in a programming related field. So where do you stand?
> If they don’t follow any sites or blogs, there is a larger chance they
> just there to get a paycheck and aren’t really curious or passionate about development.
Do you have anything other than personal belief to back up that assertion?
I can tell you I was a much more passionate and productive programmer when I wasn’t following blogs, social bookmarking sites, or other sources of hot trends.
As a front-end developer who interviews a lot, I agree that basing a hiring decision on a series of esoteric front-end quirks and technologies (which is always-changing, poorly documented, and highly experimental on the fringes) is a terrible idea. The ideal scenario would be having the candidate work on a real system and show off his programming abilities, with all the resources he would have on the job.
The questions serve as a shorthand to filter through candidates who look great on paper but haven’t done enough on their own to get into any of the nuance. It’s no big deal if they miss one or two, but a pattern of not knowing the technologies of their expertise is a red flag.
We’re in the middle of doing interviews, and I do like to ask technical questions about specific parts of the language(s) that the person says that they’re competent in.
I’ll find some particular technology that they’ve used within the language(s) and go into some detail on how it works, what it does, why it’s used, etc. In order to get this information, we may delve into the minutia of the technology… but this is something that the interviewee has picked.
Being cognizant of language / terminology issues, one can find out rather quickly if they’ve actually used this technology at the level that they’re advertising, or if they just did a quick “brush up” the day of the interview.
Above all, I try to make sure that the interviewee understands that this isn’t a “gotcha” situation, and that I don’t actually care about the information he’s giving me. I care about how he thinks and how comfortable they are in a technical discussion.
Avoiding technical details is just as bad as hammering the candidate on some ridiculous language corner-case.
Lots of good discussion here.
@Jeff – I don’t see how a developer could be considered “passionate” if they don’t search for anything beyond themselves. How can you be passionate in a bubble? Passionate, to me, means be interested in your field and bettering yourself. You can’t do that without books, user groups, and websites.
@StephenC – my thoughts on your degree question – I’ve interviewed a lot of developers lately, and the ones with comp sci degrees almost always “get” programming better than those without comp sci degrees. I am unsure if its the actual degree that makes the difference, it could be that people who “get” programming tend to get comp sci degrees.
@RussellUresti – I think you are missing my point. And I’m not concerned if they know the term “minification”, but that they are aware this concept exists. And its not even that its important to know minification for the job. Its that a smart, passionate developer who isn’t working in a bubble will be aware of the current tools of the trade.
In the end, intelligent people prove themselves so by asking questions, not just solving problems. To solve a problem you need only a set of skills and a bit of understanding. To ask an intelligent question you need the skills and knowing their limits.
Try posing an incomplete problem and seeing what questions they come up with.
Leave a reply