Eight Reasons Why Most Technical Interviews Suck

At some point, if you’ve been in the technical industry (software engineering, architect, DBA, Flash, Web Dev, etc.) long enough, you’re bound to realize (if you already haven’t) that all too often what happens in an interview is in no way indicative of what real life was or is. That’s because most interviews suck. They fail miserably at their intended purpose. And there are a few key reasons why that is, and they can be fixed.

Whether it was hiring a crazy Java engineer, who seemed great during the interview process, that once hired would randomly touch people and tell them how spicy he likes his food while refusing to write any code unless it was in iambic pentameter, or it was a company/manager who told you one story of a utopian workplace where you accepted the offer, and that place ended up being the basement of the 7th ring of Hell, you’ve probably noticed some problems. Interviews suck. And they do it for a few reasons.

My own management and interview style is, so I’ve been told (and so all my comparisons and fact-finding tells me), drastically different, and I have been able to avoid the suckfest of these interviews for a while now, having staffed amazingly talented teams while avoiding problems, by seeing all the problems related to this issue, and actively trying new ways to address them, so why not share some of the things I realized about those problems? And those problems are not just about the interview process, or the questions asked therein, itself.

Hiring Managers Don’t Know What They Want

Lots of hiring managers are just trying to fill empty seats. And for some teams that works, like an Agency world–they just need doers, its not always about team fit or culture. For most teams it does not work, and it doesn’t work because one has to know what one needs before one can find it. For example, what level of SWE is needed? Are Leads needed more than “doers”? What about Architects or DBAs? Or, worse, people try and find everything in one person. They want an engineer who can write Java, C#, C++, ActionScript 3, PERL, PHP, CGI, FORTRAN (just in case), COBOL (it just sounds cool!), and they better know how to use punchcards. Why? Because they need to cover a lot of bases and they don’t see the focus they need in priority (or they are trying to make one position do far too much work). Knowing that one needs to hire a Senior level before anything else, or knowing one needs a guy who is solid at customer-interaction or troubleshooting or live-site support, etc. is extremely helpful to the Hiring Manager. If each position of the team is planned out and prioritized in that fashion, it aligns priorities and needs. Conversely, if each person on the team is meant to be a cookie-cutter carbon copy of everyone else on the team…well, two things: a) Managers – this means you’re probably doing it wrong, I’m pretty sure you will be causing yourself massive headaches doing this (with exceptions, of course), and b) interviewees: Warning – if the place you are interviewing at wants you to be like everyone else, is that really a place you want to be? There’s more to a paycheck than just a paycheck. You can only advance in your career so far by looking into a mirror, and that’s what cookie cutter tech shops are.

Hiring Managers Don’t Have a Vision for their Team

Continuing from the point above, establishing a vision of what the team is supposed to be doing and how it does that helps clearly identify and define the needs of that team. And, much more specifically, the type of people needed on that team. When I built my last (current) team (which is a team filled with great people who are all 10x engineers) I knew that I was building a team to be very high-powered, highly-functioning, capable, adaptable, and fast. That meant I needed people who would push the limits, who could think abstractly, who were strong proponents of standards, code review, SDLC processes, etc. That, in turn, meant I needed to tailor the specific requests and Job Descriptions of the people I was looking for, but it also meant I needed to figure out what roles I needed to staff earlier than others. I knew I needed a certain type of work done early before other projects hit, so I could prioritize those roles. I also knew I needed architecture skills early on, and that if I delayed that it would hurt the future health (and reputation) of the team, so I staffed that early too. The point is: I thought about it and planned it out, I didn’t just think “I need n guys to do some type of work.” The Hiring Manager needs to truly understand what they and their team are tasked with, so they can properly staff, motivate, train, and lead that team, and thus staff that team in a prioritized order.

Job Descriptions are Boilerplate, Recycled, and Misleading

Most Job Descriptions used, especially with larger shops and corporations, are all the same Job Descriptions used over and over again, even for different positions (at most a few key words or phrases are changed). Some I have seen were literally years old. For you people looking for jobs, this is also another warning sign for you: see if there are other job postings from the same company, and if they all look the same then make sure to ask a lot of questions in your interview, because the JD isn’t going to answer nearly as much as it should.

Writing a solid JD is not a difficult process, but its one that so many Hiring Managers overlook. Many of the Hiring Managers I have known completely ignore this step and just ended up using what was there before, or grabbed a copy from one of their peers, and the fatal flaw in this is that the Job Description is their chance to truly pitch, sell, and entice the types of candidates they are looking for, while also weeding out the types of candidates they are not looking for. This directly impacts the entire interview process as most candidates come in having been lied to by a false Job Description that doesn’t accurately describe the work, position, or team other than at the most vague, homogeneous levels. So now you have a hiring manager who doesn’t know what they need, doesn’t know what their team needs, and now a candidate who has been told a completely different story. Things add up fast.

Most People have no Success or Fail Criteria Defined

This is something I picked up from Johanna Rothman way back, either from her book or her Hiring Technical People blog, I can’t remember which, but it has been very helpful. This applies to both interviewer and interviewee, and is often just not thought of. The basic premise is that there are certain key things, both positive and negative, that are indicators that need attention. Specific things that if a candidate doesn’t have would result in an instant pass, or that if an employer didn’t offer would mean moving on. Similarly there are key things one specifically wants from a job or from an employer. These things should be identified. For example, if you are hiring a Flash Engineer and they have no idea how the Flash event model or bubbling/capture phases work, you probably want to pass on them. Similarly if you were to interview at a company who ensured working 80-hour weeks, that might be a pass too. On the flip side you need to also balance that against your Success criteria, since thinking of the negative is always easier to most of us in a technical world: PM experience, worked with geographical distant teams, workplace offers flexible work schedules, etc. Of all these points this one may not directly relate to the interview process itself, but it is worth noting as these things should be defined before a candidate ever gets in a room with an interviewer. Realistically they should be defined along with the Job Description, to my mind.

In short, take the time to figure out 3 or so key points that are both “Fail Criteria” and “Success Criteria.” This also helps one judge a candidate (or employer) more objectively, and can often end up making interview feedback such as “Meh, I don’t know, seemed ok at this, but not so good at that” into “The candidate couldn’t do x or y, those are both critical problems, I say pass.”

Most People are Just not Good at Interviewing

And this applies to both sides, interviewer and interviewee. For those conducting the interview, grilling other people is not natural for many people. And, more specifically, asking the types of questions that are consistently revealing and good indicators of success criteria, while being efficient with the amount of time available in an interview, is just not a natural thing. Individuals will naturally ask questions that are related to their world view, experiences, and day to day job responsibilities. These are typically not the same as the position being interviewed for, and may not be applicable to the candidate at all. Additionally, many people asked to interview are not properly informed of what they are interviewing for (the duties and responsibilities of the position) and this is crucial information for them to know in order to ask good questions and provide good and relevant feedback.

Again, a lot of this comes down to the Hiring Manager not knowing what they want and not knowing the best ways to go about that. If you are a Hiring Manager and the individuals on your team are involved in the interview process (and they better be, if not, stop reading this and go quit your job until you figure out how to do it better), and yet you haven’t told them the details of what they are interviewing for, then you are doing nothing more than ensuring a bad interview and that any feedback you get back from the interview panels will be so much errata. The more information and context you can give those people on your interview panel(s), the more your job as a Hiring Manager becomes simpler, and the more direct feedback that is relevant and insightful you can receive.

There is nothing wrong with setting up mock interviews with your team to practice. We practice at everything else, why not interviews? Change the paradigm, pick one person to be the candidate and have them intentionally lie or misdirect and see if your team picks up on it. Coach them through improvement after reviewing how the practice session went, ways to craft questions to answer multiple things, ways to work an interview into a more conversational tone (getting the candidate out of actor/interview mode and into just being a real person), etc. In other words, you’re a Hiring Manager, spend some time mentoring people to advance in their careers, and give them the tools to be successful at what you are asking them to do (in this case, interviewing). Presumably you mentor in other areas…why not interviewing?

However, on the side of the interviewee, many people don’t realize that the interview isn’t just about them, its just as much about the people who are interviewing you: work practices, focus, management style, culture, team fit, processes and methodologies used, etc. You need to know what you are getting into, and I (as a Hiring Manager) never see it as a good sign if there aren’t any questions to me from the person I am interviewing. It’s not necessarily a fatal flaw if a candidate doesn’t ask questions, but more directly its unremarkable, or only remarkable in a negative way. As a candidate trying to get a job, you don’t want to leave that impression. But, from my own personal perspective, don’t ask those oft-recited filler questions so prevalent in recruiter handbooks and job advice sites. Tailor the questions to what you have been getting exposed to in the interview process, research the company, research the people on your interview panel (if you know their names, that is), show that you are taking an active interest in wanting this job. And if you can’t do that, if you don’t feel motivated to do that…then really think about why you are even interviewing for that position.

The Wrong Questions Are Asked

Most technical interviews will, obviously, relate to very technical topics. However, this is a painfully deceptive trap. For me it is relatively easy to tell, and very quickly, if a candidate has the technical chops. That is because I come from a heavy engineering background and know the skill-set (many hiring managers do not have that background or have forgotten it all if they do, which is unfortunate just for the sake of career advancement), and I have grown and adapted my questions over time (in fact, I have one question I always ask that answers me dozens of things simultaneously as I lead the candidate down the path of the question, I’m notorious for this question), but also because I realized long ago that there are so many other key areas that affect and influence the validity of a candidate: team fit, culture, work ethic, approach, collaboration, stress indicators, and the most important one (for me): thought process. Knowing someone can write code a certain way, that adheres to standards and works, is fairly objective. That’s simpler to quantify in comparison. What is more subjective is how a person approaches a problem, how they think around a problem, their views on quality and standards/best practices, if they get stuck on linear paths or analysis paralysis, if they can’t even debug or troubleshoot (and if they can’t do that, they shouldn’t be in tech, its fundamental), if they don’t deal well with stress or live-site issues at 4AM, etc.

Now I’m not saying to create psychological interviews and brain teasers, as is so popular today (they suck even more at giving real-world insight into capabilities of a candidate, but do really good at letting you know they can do crosswords or move a mountain), those types of interviews are all glam and no substance, they are buzzword ideas. Fake. What I am saying is the questions need to be tailored to the position, and to the expectations of that position, and taking into account the people this position has to work with. If the same exact questions are asked of all SWEs, whether they are senior, junior, or senior staff, is a clear sign something is wrong. There are differences between positions, realize them and recognize them, then adapt interviews so that the interview itself can address and focus on those specific needs that are specific to the position. Otherwise you may as well just print out all the résumés you get and post them on a board and start throwing darts to pick your next hire.

Interviews are not about Ego and Showing Off

I’ve seen this so many times. Especially on the interviewer side, as the interviewee needs to show off during an interview, that’s the whole point. But as an interviewer no one should be in there trying to sound smarter, better, or faster than anyone else. That is completely unrelated to the point of an interview. This also taints, massively, any feedback to the interview process. There can be a bit of nuance to this, such as if you are hiring for a Sr. Web Dev, other Sr. Web Devs conducting the interview have likely more directly applicable and comparable mindsets, and that can be used advantageously. However, if a Sr. Web Dev is conducting an interview for a junior position and their questions are related to just finding out what they don’t know, and then their feedback is mostly about how much the candidate doesn’t know, something is wrong. But, again, there is a nuance there in that this is also valid feedback so long as it is balanced with (in this example) what the candidate does know…which is why ego and showing off need to be avoided. Balance must be maintained, objectivity is preferred over subjectivity, but still recognizing that subjectivity has its place.

This also goes to team management, an issue the Hiring Manager needs to address. For an extreme example, but one that is easy to visualize, your employees on the interview panel should never feel as if they are defending their own jobs when they are interviewing others, you’re just guaranteeing team morale and cohesion issues, as well as ensuring completely tainted feedback. In my experience the best mindset your interview panel can be in is one of ownership: each of them are helping shape and craft the future of the team they are part of. They are each helping ensure successful candidates are brought in, who will help them in their own tasks, be able to take extra burden off their shoulders, and someone they can either learn from or mentor, or (in the best situations) both. Ownership and that kind of accountability will help any interview so much in that each person interviewing is invested in a good outcomes and avoiding bad hires. But what’s even better about this is that this attitude and mentality can be extended across almost everything else the team does, and it works magic at team cohesion, accountability, investment, and passion. Use it to your advantage.

Most Interviews Ensure Invalid Feedback and Responses

Whether the interview style is grilling attacks, or problem solving, or diagraming or the like, interviews tend to keep a candidate in “interview” mode. Meaning prepared answers, prepared concepts, practiced points and responses. In other words, fake. This is not the information a hiring manager or team needs to make a good and well-informed decision. This is the information that makes people say Yes to a candidate and then 6 months after hiring them there are all kinds of problems because none of that was true in any real way.

The entire interview process needs to be about open conversation and dialog, getting people (on both sides) out of that prepared “acting” mode. Do that by asking questions that are not scripted, that are unique to the needs of the position and company, and questions that aren’t in every single interview book/blog out there (the only valid response to “Where do you see yourself in 5 years?” is “Celebrating the 5th anniversary of you asking me this question.”) The questioning that allows this mood to fill an interview is the questioning that is standard, common, and completely useless. People ask these questions because that’s the way they have seen it done, because those are the questions they were asked.

Instead, think about the questions you ask, or have been asked, in an interview. Are any of them real? What’s your favorite language? Useless (Make the question about the language you need the candidate to know, and ask them what they think about that langauge). What IDE do you use? Useless (try “When working with X langauge, describe your optimal work setup for me”). How do you prevent SQL Injection attacks? Useless (try a question that is less leading and allows for more insightful responses that answer multiple things: “How do you ensure entered data is valid and safe in a system?” This question allows the candidate to show thought process, design, planning, troubleshooting. The original question only would answer 1 thing, make them answer 20 things with 1 answer). Instead ask questions that don’t lead the answer, that allow the room to answer multiple things without the candidate even realizing it, and that allow that open communication and actual conversation. That’s when you see the real candidate, and see the real information.

If you think about it, it wouldn’t surprise me if most of the questions asked in your interviews are either directly leading, only answer one specific thing at a time, or both. Craft questions to be more open while still specific enough as to get the point across (while keeping in mind some candidates will not understand such questions even with specificity, and that can be a valuable insight as well…assuming you aren’t making the questions so open as to be completely non-specific and utterly confusing). Use questions that answer multiple things (“How would you design a reservation system for a restaurant?” Everyone knows restaurants, and this answers DB, architecture, UI, requirements gathering, thought process, etc.), or questions that can lead down a path of multiple insights or topics (walking a candidate through a project process: requirements/spec gathering, estimation & design, unexpected shortened timelines, development, scope creep, slipping the date and figuring out how to get back on track, documentation, etc.).

Summation

Interviewing well is a vital requirement for successfully building a team, as a bad hire will hurt your team/company much more than a good hire will help it. And interviewing well is something that requires an investment to do well, and it is a wise investment. Many issues I see in jobs, especially larger corporations, are all related to bad leadership or bad hiring. And much of the time the bad leadership is due to bad hiring in the first place. Interviews are a basic fundamental thing that has impacts that will eventually ripple into nearly every facet of the company, especially if done poorly. Respect that notion, and work to always improve it. It doesn’t take too much effort, and it will pay off in both sanity, improved teams, and a fundamentally improved staff in your workplace.

What I lay out above is certainly not the full breadth and width of the ways interviews can be improved, and there are definitely more nuanced things to list if I wanted to list every single detail about why tech interviews suck. But hopefully what I’ve pointed out above will, at the very least, spark a different point of view or a rethinking of an approach, even if it isn’t directly what works for me or what I proposed an alternative to, the biggest outcome if you’ve taken the time to read this is simply to actively re-think your interviewing process and identify areas to improve it (as well as areas that already work and capitalizing on them). Always keep moving ahead, and sometimes its hard to tell if you are stuck unless someone points it out to you.