Technical interviews are already highly imperfect measures of ability. And they drive engineers crazy.

But on top of that, certain interview practices themselves can seriously challenge an engineer’s sense of legitimacy – even when they perform well enough to land the role.

Here are six technical interview practices that I’ve seen lead engineers to needlessly question their value, and how I think candidates can anticipate and steer around them.

Job requirements > the job

You might be genuinely great at what you do, yet companies not-infrequently set unrealistic expectations for the roles they are hiring for.

For example, I once had a company reach out to me about candidates for an iOS role. They were an IoT startup and many of their engineers had substantial low-level knowledge and a wide breadth of generalist software engineering knowledge.

They of course valued this knowledge, and they wanted the same from their iOS hire. In particular, they wanted a strong native iOS engineer to architect and build their native app from scratch, with the following interview and experience requirements:

1. The interview must be done in a language other than Swift or Objective-C
2. Interview content will be less-focused on iOS and more on generalist concepts, including academic CS
3. Candidate must have several years experience, that equivalent to mid-level or higher

The problem is that these expectations are wildly unrealistic for most iOS developers, let alone at the junior-level salary they were offering.

That is, iOS engineers tend to be a different breed. Having interviewed hundreds myself, they tend to be weaker in topics like algorithms, and have less interest in technologies outside the Apple ecosystem. This doesn’t make them bad engineers, it just indicates a slightly different set of values they tend to hold compared to other classes of engineer. I myself got into engineering, not because I was inherently interested in code (that came later), but because I wanted to build products. And backgrounds like this are not uncommon in this community.

As such, most iOS candidates who took this interview would fail — including those who are masters of their platform and would do a phenomenal job architecting and building the app from start to finish. I can count on one hand the number of iOS engineers I’ve interviewed who would pass, and they would command salaries wayyy beyond the junior-level amount this firm was offering.

And unfortunately, those who do fail an interview like this end up feeling like their expertise in their platform is somehow generally undermined by not being a generalist. Except what they don't realize is that the background and characteristics that lead someone to be able to build great user experiences on an end-user-focused platform like iOS tend not to be the same characteristics as those that lead to other kinds of engineering interests.

The key take-away: Don't let niche values of specific companies dictate your sense of value in your particular area of expertise. The fact that they are in a position to hire you does not imply they themselves have the expertise to properly evaluate your particular background.

However, if you do find yourself facing an interview like this, and would like to rise to the challenge, that just might be possible. I probably sound like a broken record by now, but a growth mindset is the secret sauce to getting proficient at any content. If you can do iOS, you can do low-level. It’s just a matter of weighing how much time it’s worth spending preparing for an interview like this when other companies are more realistic about their expectations. If you’ve got time, why not give it a shot? You could fail an interview like this miserably and leave knowing your iOS chops are fully in tact!

How I’d like to see companies change

Those responsible for hiring at companies need to take a step outside of themselves and align with the realities of the hiring market. The company I mentioned had already been looking for years prior to reaching out. It would have served them better to find someone with solid expertise in iOS (which is full of nuance as it is), and coach them into the rest with a team that seemed more than qualified to do so. Not every hire needs to be your technical golden ticket.

Arbitrary job requirements

Along similar lines, there are companies that administer what I like to call "franken-interviews" as a result of a really bizarre set of requirements that are driven by factors like budget and miscellaneous organization-level needs.

Let's say you've applied for a front-end position at a healthcare company. But your future boss is actually experiencing a bunch of pressure from higher-ups to solve a very specific set of problems for which there is limited budget. Ideally, she'd hire more than one engineer to solve the problem but can only afford one. So, she tries to fit a square peg into a round hole in the hopes that someone comes across her desk with the requisite core skills along with the otherwise unrelated set of skills.

So you get to the interview, you nail the front-end stuff, but are taken off guard by being drilled on other topics which you didn't even think to prepare for. That's because your prospective boss didn't even add this to the official job description, and is testing you on it off the cuff. Some of it is sort of related to your typical front-end work (e.g. SQL), but some of it feels really out of left field. You don't get the job, and you don't know why, and you wonder if front-end engineers are actually supposed to know all of these other things these days.

This scenario takes a few different forms, but the general model is the same: scraping together miscellaneous requirements for very specific, often temporary needs, frequently in large organizations.‍

As an engineer, you need to be the defender or your honor. Just because a company has arbitrary requirements for a role doesn’t imply you’re a bad engineer in your role if you don’t meet them. You need to make this connection internally so you don’t make the mistake of internalizing what is really a failure of the company’s hiring process as a general failure of your own.

But if you’re not sure if you’re in this situation, take not of the questions that side-lined you. Then do some research. Ask mentors, do a little Googling, and ask peers if this is the kind of stuff someone in your role should really be expected to know these days. If so, no biggie, just familiarize yourself the best you can. If not, move onward and upward and let it go.

How I'd like to see companies change

It’s fine for companies to look for people who meet exactly their set of needs. But it’s important, when doing so, to be very clear about the distinct sets of requirements being used to make the hiring decision. If some typically unrelated skill is a requirement and not just a plus, it’s valuable to be explicit about it lest they confuse the people they do hire and garner a reputation of unpleasant interview surprises among those they don’t.

Toxic interviewers

You’re not guaranteed to get an interviewer who is capable of creating an environment that is susceptible to gathering accurate data about your strengths.

That is, some interviewers have a style that causes candidates to be uneasy. Perhaps their overly severe in their tone. Perhaps they are eerily silent or even sound aggressive. Subtleties like these can throw candidates completely off their game and leave them feeling like this was somehow an accurate measure of their engineering chops.

I’ve even been in interviews where the interviewer was very clearly on an ego-driven power trip. He actually took pleasure in asking sneaky gotcha questions, and seemed to feel validated in his own knowledge at the possibility that I might make a mistake.

You need to take situations like this for what they are: profoundly suboptimal and frankly inconclusive. Perhaps you had technical weaknesses you need to work on, but an unhealthy emotional environment makes it challenging in the moment to know up from down. After enough interviews, you eventually get used to it.

How I'd like to see companies change

Companies should augment the interviewing team with high-warmth, high-emotional-intelligence individuals. Ideally the interviewer falls into this category, but even having a non-technical but incredibly warm person present can radically alter the dynamic in the room. They can supplement the technical interviewer’s energy in real time, and offer feedback to help interviewers grow in their soft skills.

When adaptive interviews go wrong

Some interviewers use an adaptive technique. That is, the more a candidate knows, the harder the questions they ask, but the less a candidate knows, the more they gloss over.

Interviews like these are designed to test candidates with a range of experience. There are various sections that weigh different skillsets and combinations thereof, before making an overall determination.

I’ve administered interviews like these, and I can't tell you the number of times I interviewed candidates who struggled on one or two sections, thought they failed for sure, but then proceeded to pass the interview. The irony is that some of them disproportionally considered the really tough questions they got wrong without realizing they got further than most other engineers.

This is a situation where you are being asked really advanced questions because the interviewer may be boundary testing just how awesome you are. The thing is, they don’t clarify that you aren’t expected to know that knowledge on day 1, if at all, so feeling like an impostor for not knowing it is not appropriate.

The moral of the story: don’t assume you know how you are being evaluated. It’s entirely possible to get questions wrong and still do well on an interview.

How I'd like to see companies change

Interviews like these can be really great. They give candidates the opportunity to impress with range in addition to baseline requirements. The solution is as basic as setting expectations. A simple “you may encounter really tough, experimental questions in addition to standard content” is enough to seriously put someone at ease when they run into a question that’s beyond their wheelhouse.

Interview content != actual responsibilities

The impostor vibes can carry beyond the interview even if you pass and get the gig. That’s because, unfortunately, interview content doesn't always match what you'll be doing on the job. That means you can be tested on one set of material and be expected to do something seemingly unrelated if you are ultimately offered the role.

This ‘bait and switch’ can lead to at least two scenarios for impostor-hood: the rude awakening and the existential crisis.

Existential crisis

Imagine you're actually a pretty successful back-end developer. You've worked at several smaller startups and have worn a variety of hats that gives you a strong sense of system design, not to mention that you have familiarity with the latest and greatest technologies to solve real problems at scale.

But then you get one of these CS fundamentals interviews. You haven't touched this stuff in 10 years. Maybe you don't even have a CS degree. To this point, you thought you were a solid engineer, but then you bomb the interview miserably.

Suddenly you find yourself questioning how good you actually are. Have you just been skating by from one small startup to another with unrigorous hiring standards? Is all the stuff you've learned to date just child's play when it comes to the kinds of mammoth problems seen by the likes of Google and Facebook and who knows what else?

Horror sets in, and you're not sure you deserve even the jobs you've had.

The thing to realize here is that technical interviews are profoundly limited in terms of what they are successfully able to measure. Different companies have different values in terms of what they expect from their employees, and that doesn't mean your flavor of value is undermined because one company's interview process was unable to discover your strengths. The good news is if you really want that job, the academic stuff is well within your reach. But you can always seek roles that value the areas you specialize in already.

The rude-awakening

Now, imagine you're a fresh college grad. You've been studying your CS fundamentals inside and out, and you've jumped through every academic CS hoop your FAANG interviewer has thrown at you. Now you've got the offer, and you've been assigned to a real-world, back-end web problem.

Suddenly you realize your CS degree hasn't prepared you very well in terms of how the web actually works. The kinds of problems you're encountering are less abstract and more specific to technologies like HTTP and caching, not to mention myriad security considerations you've never even dreamed of. You're experiencing a rude awakening of epic proportions, in the sense that you're going to have to pick up a boatload of domain knowledge on the job before you can even hope to be effective at solving substantial problems. You don't even have a strong grasp on git!

Again, horror sets in and you think maybe you never deserved the offer in the first place.

In situations like this, it’s not helpful to think in terms of whether you do or don't deserve the job. Your company hired you. Given all the available data, they accepted the tradeoffs and risks you posed specifically. If you're more junior, there is usually an expectation that you will spend a significant amount of time learning on the job. Seek out advice on how to learn most effectively through doing, and embrace the situation you're in with a belief that you can pick up all the skills you need. You're not faking it with anyone. The company knows you're junior. Now is the time to take the baton and run with it.

How I’d like to see companies change

The solution to this problem is a small dose of transparency. By explaining their interview philosophy (what their interview claims to be measuring and why), companies give candidates an opportunity to make sense of their experiences whether or not they pass. If they do, they’ll have a clearer sense of what they signed up for. And if they don’t, they aren’t totally left in the dark as to why, especially if the content is foreign to them.