The Technical Interview Rift
You are a manager and it’s time to hire a new developer to join your impressive team of A+ players. Do you give them a technical interview?
You are a developer and it’s time to be interviewed by a new company. Do the upcoming technical interviews excite you?
Technical interviews are a contentious topic. During our weekly discussion, we set out to ask the #TechMasters community how they felt about technical interviews. There was a pronounced discord between opinions which made for a lively discussion. Why are technical interviews such a polarizing topic?
Two Sides to the Argument
Whether you are looking to hire or you are the one being hired, one cannot hide from technical interviews. They have penetrated the recruiting process of many companies in North America, Europe and Asia. A survey of the #TechMasters community shows there is a clear rift between the two sides. One side uses technical interviews whereas the other side does not.
There is a slight proclivity to conduct technical interviews within the companies that comprise the community. We set out to come up with a hypothesis to explain this and found an interesting parallel. From a survey of Myers-Briggs personality types, 67% of people are protector, visionary and intellectual types whereas 33% are creator types. How strongly correlated these datasets are is still in question, but we speculate that the company culture and consequently the hiring process closely follows the founder’s and/or executive team’s personality types.
During the discussion, there was a nuanced reasoning behind supporting or rejecting technical interviews. There was, however, a coalescing around two central ideas: (A) technical interviews are terrible at assessing fit, and (B) technical interviews are the only way to judge if a candidate has the required technical skills.
Why you should do technical interviews
The main argument to support conducting technical interviews was to ensure that the new hire doesn’t backfire if it turns out that they don’t have the skills. For example:
In a different time and place, I interviewed someone for a WordPress theming position, and although they had a vast portfolio of themed sites, they later admitted to not knowing any PHP or CSS — they just grabbed themeforest stuff and applied them. In a case like this, maybe a basic technical test is necessary. — Enrico
The discussion continued, and it moved into why doing whiteboard or pen/paper tests are useful. If the sole purpose is to assess the candidates learning/problem-solving ability, then it is generally supported. However, technical interviews are a tool that can be misused as eluded in the following:
I’ve never given a crap about asking someone how good they are at a programming language, let’s be real, in the real world we will always reference the man pages or docs to get the necessary details. I generally ask them questions to understand how they solve the problem. I tend to ask them to pretend I wasn’t there and have them go through solving the problem whether on whiteboard or paper. What I like to look for is how quickly they give up vs. how dedicated they are to coming up with a solution (workable or not). — Puleen
Technical interviews and the tests within them are used as a leading metric to indicate the discipline and dedication of the candidate. Being able to solve problems, communicate your thinking and learn quickly was repeatedly mentioned as the main traits you should be looking for in the interview. If the technical interviews are being used as a means to eliminate candidates due to the ‘wrong’ answer, then you aren’t doing it right. For example, there was a recent story about a candidate being interviewed for a Director of Engineering role at Google where a non-technical HR person following a script eliminated him. This is an example of when technical interviews fail, and it is our duty as part of the industry to work towards ensuring this doesn’t happen. After all, the primary purpose of doing technical interviews is to ensure A+ players are identified and are persuaded to join your team. If your process is preventing this, then you are doing it wrong.
Why you should avoid technical interviews
Interestingly, the main argument for doing technical interviews can be reversed and used as a means to dissuade from doing technical interviews. The main reason being that technical interviews can cloud ones judgment insofar as you miss the intangibles that the candidate has to offer. Assessing fit has more to do with the intangibles of the candidate, i.e. soft skills, learning ability, then it has to do with their hard skills. Eloquently stated:
Regardless of role and position in a company, what possible insight does questions like “solve a Fibonacci sequence” + whiteboard + no internet give you to know about a person fit for a development role?
Ability and willingness to learn is my number one criteria for hiring developers. Besides, nowadays, you rarely rely on writing algorithms when developing SOFTWARE. — Ahmad Nassri
The other problem is that the interviewing process at most companies does not evolve at the same pace as the industry. Candidates enter the recruiting process expecting the latest and greatest technology and are thrown into a time machine needing to work on technologies that are sometimes decades old. Due to this the interview questions are almost irrelevant devolving the interviewing process to one of hubris:
Working with leaders who haven’t evolved their interview questions or shape them for the candidate/role. It is just ego strokes. — Adrian Mauer
Having a new-hire backfire is not an enviable position to be in as a front-line manager trying to climb the corporate ranks. Therefore, an objective tool meant to assess one’s skills can become biased and intuition-driven. In mature companies, extra diligence is needed to ensure technical interviews are not only used as a means to cover your ass (CYA).
Lastly, whiteboard or pen/paper tests are not the strong suit of certain cultures, demographics and/or personality types. Putting a candidate through these tests is akin to throwing a fish into a shark tank:
I have failed the Amazon interview twice and the Google interview once but I always seem to get a job with SOMEBODY slinging code or fixing sick servers. For some reason I don’t do well with coming up with working algorithms on the first try. I submit that I am totally making excuses for myself at this point but I learn and re-learn through play and experimentation and I don’t think there’s really time for that in short white-boarding sessions. — Anonymous
If the candidate is required to do whiteboard thinking in their day-to-day job and can’t do it during an interview, will they be able to do it afterward?
The Technical Interview Spectrum
Black and white thinking is dangerous and after further discussion we began to remove the binary lens and uncover a spectrum of approaches. We found that the definition of a technical interview differed between individuals. Some folks considered algorithmic tests as the technical interview whereas others consider taking practical tests the technical interview. Our survey results clearly show that there is not a single approach and in fact, most companies deploy multiple technical interview techniques (with none using algorithmic pen/paper tests):
To illustrate this, one individual described his experience with an engaging, evolved and integrative process. One that not only assessed the candidates hard and soft skills but used the spectrum of technical interviewing tools to accurately assess fit:
An interview I did at Venmo/Braintree/Paypal 3 years ago was very well set up. After all the usual phone screens (tech and generic personality “fit” screens) I did a take-home test in a language of my choice, it was a generic CRUD thing with a single “algorithmic” function, so the test was mostly about code organization and structuring, I thought that was great (took me ~3 hours from start to sending it in).
Then they flew me over to SF, put me in a very nice hotel and the day of interviews went like this: — Walk around the office, meet the team — Interview 1: talk with someone senior about what you like, what kind of programming you specialise in — Interview 2: similar chat, honestly I don’t remember all the details — Lunch with the team at a nearby restaurant, they paid — Pair programming! On my own gear, in my comfortable setup.
They asked me to extend the little app I wrote for the take-home test. — Data modelling time on a whiteboard. That was another great test. They give me a real life scenario and asked me to define the data model both on the application and on the relational DB side. All in all, would do again, except not more than 1 a month because flying across a continent and back for 1.5 days is gruelling.
— Simon
Lastly, James Wilkinson described a process which may be representative of the trend many companies are following in North America:
If you are going to do a technical test it belongs at the very beginning of the interview process after HR has said ok you meet the requirements. Because doing a test after you’ve spent time with the company getting to know them is a slap in the face. No one ever uses the technical test as a gauge of how you solve problems despite them saying that. Having done so many I know that you don’t pass you don’t move forward no matter how much you can talk through it. So IF you have one, have it first
They have a place for people who are fresh out of school and have 1–3 years or 1–3 employee experience. You need to check on these people to make sure they can code they’re very young and probably been using a single pattern.
What is more effective is a conversation about technical subjects, where the interviewer ask questions like explain inheritance in JS, what is a prototype, what is a closure. These are ways to gauge if they know the langue without making them write code. You should never ask a developer to write anything from scratch, or write anything.
Some of the best tech test are solving bugs, make a fake bug and ask them to solve it, the code is already there, it more like how you would expect to work in that environment. This code is suppose to post but it not working, in the code it set to GET change to POST and done, Small simple tasks.
You must trust in experience. If someone has code online, a portfolio and company names you’ve heard of on their resume, don’t waste their time or insult them saying we want to do a technical interview.
Ask the developer, or as the developer, ask to come into the office for an hour and have them shadow a developer, see the real code and the real problems. I do this after an offer is extended before I sign. — James Wilkinson
Go Beyond Fibonacci Pen/Paper Tests to Assess Candidates
If you are a manager interviewing candidates, you should take a long look at a process that employs multiple technical skill assessments. Combined with pair programming and lunch with the team will certainly give a holistic overview of the candidate’s fit. For those being interviewed, a good indicator of the culture is the process you go through. A pejorative and humorous term emerged towards the end of the discussion, namely being Fibonacci’ed:
For someone with 1–3 years of experience without an extensive Github, it’s useful [to do technical interviews]. I would definitely not Fibonacci anyone… but for intermediate to senior level candidates, asking them to spend time answering textbook problems isn’t the best use of time for anyone.. — June Coffey
If you get Fibonacci’ed in your next job interview, perhaps you should look elsewhere? If you are the one doing the Fibonacci’ing, you are doing it wrong.
The Weekly Picks
The following articles posted during the discussion are enlightening:
- Interviewing Programmers (Eli White)
- The Terrible Technical Interview (TechCrunch)
- You Suck at Technical Interviews (Laurie@Seldo)
- Technical Interviews are bullshit (Anonymous Author)
Future Articles in the Series
Two interesting questions were raised, to paraphrase:
Do companies that have a religious TDD culture ask more hardcore algorithmic technical interview questions? — Jason Chen
Are technical interviews predominantly a North American trend? — Ahmad Nassri
These will be the topics of future blog articles.
How do you feel about technical interviews?
Do you have a technical interview story to share? Tell us on TechMasters.chat. We discuss something new every week with hundreds of perspectives and backgrounds to learn from.
If you would like to help us with the technical interview series, our 7 question survey is available here: Technical Interview Survey.
Your story may be featured in an upcoming article!
Special Thanks to Andrew Moore and Ahmad Nassri.
