Did you fail that interview or did your interviewer fail you? Did you ever get rejected from a job interview and feel terrible about it? I mean, like really beat yourself up about it. I know I have. Well, sometimes there’s more to the picture than you passing or failing. Sometimes the interviewers don’t know what they’re doing.

When that’s the case, getting rejected or for that matter, getting an offer. Well, it’s more like random chance. It’s certainly not something you should feel bad about. You wouldn’t beat yourself up if you lost a game of heads versus tails, right? Like, we’re not psychic. So let’s talk about how to know if your interviewers know what they are.

Start. Start by imagining the most experienced and talented person you can think of, hardworking, nice to work with. Imagine that person is interviewing at a bunch of companies. You might think that someone like that would be able to get an offer every single time they go out for interviews, right? But would they sadly.

Even when that person is really good at interviews, they won’t always get an offer. That’s because they are only one half of the picture. The other half is out of their hands and in the hands of the interviewers, they are being interviewed by now. Let’s just be very, very clear about this. Not every talented person is a fit for every company, team or role.

So one totally legitimate interview outcome is that a good person is just wrong for the company or for the type of work that’s totally fine and normal, and that’s not what we are talking about here. For the purposes of this video, we are talking about when a great candidate for the job and company doesn’t get an offer.

And uh, interestingly, we’re also talking about when someone who is wrong for the job and wrong for the company, when that person does get an offer. You see, when interviewers don’t do a good job, it can fail both ways. The company can lose out on a great person, and they might also accidentally hire someone who is destined to fail or be terrible to.

Hey, look, no one ever said being an interviewer was an easy job, right? So why though? Why don’t interviewers just get it right? Well, it, it’s complicated. And to be honest, there are hundreds of ways an interviewer can come up short. For this video though, we’re going to focus on the most common ways interviews go wrong.

So start the counter. Let’s begin. Number one!

Interviewers who ask too many questions

Now, that might sound counterintuitive, but it, it’s actually quite a common problem. It goes like this. An interviewer shows up to the interview. They’ve got their notebook, they’ve got their huge list of questions, their pen, they’re ready to.

They ask you question after question and they write down what you say. Then they thank you for your time and they leave. It looks like an interview has happened, but did an interview actually happen? Well, sadly no. No, it didn’t.

So let’s be clear. This is different from a recruiter screen. If a recruiter calls you and asks very, very specific questions of you, that’s totally normal.

In that scenario, they’re trying to understand very, very basic, straightforward stuff. Like, do you speak the language that you need to speak to work at this company, or can you communicate verbally with any coherence at all? Uh, do you know very, very basic stuff relevant to the job. It’s a different sort of question they’re asking because the recruiter isn’t trying to hire you in that interview. They are trying to prevent the wrong candidates from using up the time of the team on interviews that are destined to be all “no hire” outcomes.

So that’s not the sort of interview that I’m talking about here. I’m talking about when you are on the call or in the room with the subject matter expert– the actual interviewer for the role that you are interviewing for –when that person hits you with loads of questions.

The problem is that they’re not actually getting any signal from all those questions they’re asking. It’s usually a junior interviewer, someone who wants to do a good job, but they’re mistaking asking questions for getting meaningful signal. It’s subtle, but, uh, here’s an example.

The interviewer asks you, “have you used a TypeScript before?” And you say, “yes, I have.” Or you say, “no, I haven’t.” And they dutifully write down your answer and then they move on to their next question. When that happens, um, my question to you is, do they have a useful piece of information about you or do they not? Sadly, they don’t.

If you know TypeScript and they need you to know TypeScript, then it might sound like they have done a useful thing in this interview. But do they know if you know TypeScript? No, they don’t actually. They don’t know anything about what you actually know. Did you do a TypeScript tutorial once? Or did you maintain a 10,000 line of code TypeScript code base for multiple years? They have no idea when they’ve asked a superficial question like that.

And it’s even worse if you haven’t used a TypeScript. If you say “no” and they move on, maybe you just failed the interview. How do you know? And if you say “no,” does that mean anything? Like really? Well, it depends. Maybe you haven’t used TypeScript, but you have used JavaScript extensively. Did they get that signal? Well, no, they didn’t.

Maybe you’ve used loads of JavaScript and you have previously written Java or C++. So you’re familiar with typed languages. Even better, right? Do they know that? No. No, they don’t. They didn’t do any follow up questions to get that signal. That’s a big “Womp womp.”

What you want instead is for the interviewer to be asking questions that are rich in detail, open-ended. Not have you worked in TypeScript, but tell me about the last project you worked on. What was challenging?

In that question, the interviewer will find out far more about you than just what programming language you know. I mean, they will find out if you can code in TypeScript probably, but they’ll also learn what sorts of problems you can solve.

They’ll also find out a bit about what you’re like to work with. They might also find out a lot about how you communicate technical content. That’s all more important than if you know one particular language. It’s just a much richer question.

Hey, by the way, I didn’t really introduce myself. I’m Jack. I’m the CTO and co-founder of a company called Cord. That’s cord.com. Cord gives you an SDK for turning any existing web application into a rich real-time, multi-player app like Figma or Notion. Cord exists to make it absurdly easy to add social features to your app, like real-time chat. Or real-time presence. Typing indicators. Read receipts. Uh, slack integration. File attachments. We offer in-page annotations so that you can see what specific work your teammates are asking about. There’s a lot. It’s a really fully featured collaborative experience.

So part of the reason that I’m making videos again is because I’ve got something I feel proud of in. We let you jump from nothing multiplayer about your app to best-in-the-industry multiplayer features really, really, really fast. I mean like probably a hundredth of the time it would take you to build those same features for yourself. Our customers right now include several billion dollar companies. Uh, names like monday.com. You may have heard of them. Uh, Stoplight. Uh, there’s a company called Walnut it’s one of our customers. Uh, Finmark, which was just recently acquired by bill.com. These are folks who already trust Cord to take their applications up to the next level of multi-player, real-time goodness. Look, I don’t really feel super comfortable self-promoting, but I’m able to offer you this video today because I have something to promote. So if you are a fan of this channel, please check us out.

It’s cord.com, C O R D dot com.

Okay, enough of the self-promotion. Let’s get back to the list.

Number two.

My number two item on this list is:

Interviewers that don’t know their content

You might encounter this where the interviewer walks in and says something like, “oh, so I’m not supposed to be doing this interview. Uh, but the interviewer you were supposed to meet with, they couldn’t make it today, so you got me.”

Uh-oh. Immediately, you have to wonder, does this interviewer know what this interview is all about? Do they know what they’re supposed to be assessing? In all honesty, they probably don’t. Even worse, do they care about the same things the primary interviewer would have cared about? Are they even on the same team at this company?

This other person might actually be more lenient than the intended interviewer, which probably sounds like a good thing, but actually it means that you’re basically getting noise back out of this interview process. Positive or negative, the person might be setting you up to fail even worse later if they pass you through to the next round.

Another way you might encounter this type of interviewer is where they walk in and say, “ah, this is only the second time I’ve done this.” When I hear that, my brain instantly re-translates this as, “this is only my second time doing this interview, and so this is probably just like practice while I get calibrated. I don’t know what good looks like.”

I do have some empathy for the interviewer on this one. You have to start somewhere and until you have interviewed people, you don’t have any context. Good interviewers test their interviews on themselves first. And then they do mock interviews with good people that they know, people on their team. They do all of that before they talk to you.

At my company Cord (cord.com), no one gets to do an interview until they have attempted their own interview questions first. Then they will shadow someone else doing that interview. Then they will be reverse-shadowed by someone who watches them do the interview. And only then, only after all of that are they flying solo interviewing you. We do this so that when they walk in the room, they’re calibrated. They know what good looks like. We’re not expecting you to be our Guinea pig. Many interview teams don’t apply this kind of rigor, and so you get… what you get.

Another form of this that you might not know you’re getting is… get ready for it…

The person who just read the description of the interview on an internal doc 10 minutes ago…

…and now they’re trying to interview you.

I’ve seen this like a hundred times in my career, even at Facebook, at different companies. So what happens is the interviewer is rushing. They go to the document, the internal wiki, docker, whatever, where the description of the interview is. They read it. They’ve never done the interview before. They’ve never even asked the questions of anyone else before. They walk in and they start interviewing you. And this usually goes about as well as you might imagine.

They just often botch the questions. Their phrasing is awkward. They stumble over it. They don’t really deliver to you an interview question that you can handle. And what this means is that it’s really hard for you to know what they’re asking. And because of that, it’s hard for you to know how to answer it. Real talk. The interviewer will rarely attribute your poor performance to their poor delivery, even when that’s what actually happened. And so often, they will just reject good people completely, completely wrongly.

Uh, I’ve personally been subjected to this years ago. Uh, it’s about 10 minutes into an interview I was answering some systems architecture question. I wish I could remember exactly what it was. Um, the interviewer just seemed to be making like random questions, kind of meandering around the content without any detectable outcome in mind.

By that point, I knew enough about interviewing to know that we should be headed somewhere with this. There’s sort of a, a design that we should be arriving at. Yet this interviewer seemed to be gradually guiding me to solve a completely different problem than what he had initially prompted me to do. And I realized… this interviewer doesn’t know what he’s supposed to get from me here.

Hmm. He’s just asking me like, whatever next question came into his mind in the moment. So being a bit cheeky, I literally just asked him like, “Hey man, where are we going with this? Like, what, what are you seeking from me?” I will say to his credit, uh, he actually acknowledged, ‘yeah man, I don’t really have a plan here.’

And then we just kind of sat there a little bit awkwardly. Um, Look, I absolutely would not have taken a job if they’d offered it. Uh, but also they didn’t offer me a job . Um, you know, I reckon that actually makes sense cuz you don’t necessarily want to hire the person who called you out in the interview, right? Like, that’s not exactly the person you feel comfortable coming into work every day and facing whoopsie.

Number three

Interviewers that don’t make sense for the role

It takes loads of context and clarity. To be a good interviewer, you have to really know what you’re looking for. The person doing the assessing needs to be an expert in that domain. You wouldn’t have a database administration interview run by a senior product developer, for example.

And yet… way too often… a team will put someone on an interview that has no business doing that interview at all.

Sometimes this is like a leadership team member and they just wanna be a part of the interview process. You know what I mean? Like the, the sort of exec who just believes that they’re automatically qualified for whatever they want to do. They can put themselves into the interview process. I was actually once interviewed by an exec team member who thought his role in the process was to sell the candidate on the company’s vision.

The wrinkle was, I was already a big fan of the company’s vision. That’s why I was there. So that part of the conversation took a whopping, I don’t know, two minutes. I remember the look on that exec’s face when he realized he didn’t have anything to ask me now. He actually said out loud in the interview, “you know, usually I have to do more work selling the candidate, but, uh, you seem to really get it.”

Let’s just think about that for a second. Unpack it.

The candidates who aren’t as bought in, he’s good at selling them. And the candidates who already believe in the company and who know what’s going on, he doesn’t really have anything to do with them. Pretty sure that’s the wrong way. Even more, he was definitely the wrong person for this interview because he wasn’t trying to get any meaningful signal from me at all. I don’t think he even knew he wasn’t doing an interview.

So I got an offer from that company. I rejected it. But even more importantly, they had no idea if I was good for them.

Another way you might see this interview is when a short-staffed team is using anyone they can to cover interviews. That doesn’t have to be a tragedy, but it too often is. If the interviewers are short-staffed, they may have to include people who aren’t the perfect fit.

This happens on small teams. This happens at startups especially. You just don’t have the people. What good teams do is ramp those people up as much as they can. Have them shadow someone who has the context to run the interview competently.

At Cord (cord.com), when we are hiring for the first person in a particular role, say for instance, our first salesperson or our first developer relations person, we don’t already know how to hire those people. We always seek the guidance from industry leaders in our network first. We literally run our interview scripts by them and ask for specific help in designing good interviews. Often they laugh at us and say, you’re so far off. This is not how you assess people for these kinds of roles. And we eat crow and we fix our interview process.

Now, that might sound like bad for us. That might sound like we should be embarrassed for not knowing, but consider this. Most teams don’t put in that work. They don’t start by admitting what they don’t know. They just go for it and see what happens. And so they get extremely low value out of their interviews because they don’t know what they’re assessing for. They don’t know whether you are good or bad, and whether you get an offer or you don’t, it’s not really possible to know if that was the reasonable outcome.

Okay. The last and most dangerous type of interviewer you might encounter of this sort… is the interviewer who seems to be the right person… who even believes that they are the right person…

but they aren’t.

This person isn’t competent to do the interview but doesn’t know it. It’s hard to spot these people in many cases because they don’t exactly advertise that they don’t know what they’re doing or that they’re approaching the interview the wrong way. And it can be really nasty to be on the other side of the interview table with a person like this.

Say for example that you’ve got a person like that and you’re doing a behavioral interview. They might reject your values or discount your experience. Uh, and they might be just literally wrong.

One example of this that I’ve encountered directly was an interviewer who was convinced that all of the developers at big tech companies are idiots. This is like in 2017. Uh, I had only just recently left Facebook. Instead of interviewing me to see my knowledge. He was interviewing me to prove his knowledge to me. And he was doing it in ways that were completely unrelated to the interview that we were doing. He spent more time with him taking pot shots at high scale teams than he spent getting interview content from me to understand if I was a good fit for the job he was interviewing me for.

Ironically, I’m pretty sure he walked away from that experience thinking that like he’d shown me what was, what. He was, he was, uh, taking me down a peg, as they say. My experience was that I would absolutely never, ever work at that company specifically because they’d put a person like that on an interview loop.

Number four.

Interview teams that blindly copy the process from big tech companies

This is another anti-pattern that I’ve seen dozens of times in a massive variety of companies, from healthcare companies, to fintechs to biotechs, even at an advertising company. And it goes like this.

A company needs to start hiring people. So they look at how a well-established company does similar sorts of hiring and then they set up their process to match what that well-established company does– verbatim. They copy exactly the process.

So like a concrete example of this would be a small company that decides to copy Google’s interview process for hiring engineers.

They do a technical screen, couple of coding interviews, a systems design interview. Then like a behavioral interview. Easy, right? Like Google already did the work. They can just copy those notes. Straightforward.

Wrong! This is a classic example of the swimmer’s body paradox. Now, if you don’t love cognitive biases as much as I do, let me explain to you.

The swimmer’s body paradox goes like:

A person decides they want to have the lean, long, lithe figure of an Olympic swimmer. So, they start training like a swimmer. They start eating the diet of the Olympic swimmer. They buy the bathing cap. They buy the tiny super, super tight black Speedos. They literally clone exactly what an Olympic swimmer does.

My question is, will they get the outcome they want? Will they get the swimmer’s body?

No. No, they won’t. They’ve accidentally done things the wrong way around. Swimmers become amazing athletes because of their physique. They eat the way they eat to maximize what nature has given. They train the way they train to get the most out of their genetic gifts. They were born looking amazing in Speedos. Wait, sorry. Where am I going with this?

Uh, I mean to say if I start training today to be an Olympic swimmer, I stand about as much chance of becoming one as if I had bought a Beyonce’s fragrance thinking that will make, uh, me as electrifying as the Queen B herself.

Uh, that’s not how causality works, sadly.

Sorry. Uh, so back to this company. They will copy the form of Google’s interviews to a T, but they won’t be able to copy the talent that Google has. The experience that those interviewers are bringing to those interviews. They won’t have the resources of Google’s interview teams, right?

They don’t have any of that stuff. They won’t have the onboarding sessions. They won’t have the interview panels that that do the decision making behind the scenes. They won’t have all of the cross-functional training that Google puts all of its interviewers through. All of this stuff is what makes Google’s interviewers very, very good.

So this company, they probably also won’t have Google-strength engineers on their team already. So that means that even if they do the interviews exactly the way Google does theirs, they will not build a “Google-strength” team.

And even more than that, they probably don’t want “Google-strength” engineers anyway.

What a small team needs is entirely different from what a large organization like Google needs in their employees. So copying and pasting their interview process, even if that company somehow clones it to a T — perfectly identical to Google’s process — they’re not gonna get the result that they want. They will not put the right people on their team to help them succeed.

A much better way to approach the same problem is to start from the results you need your employees to achieve and to design interviews that test to see if a candidate can help you achieve those results. But not many teams go about it this way, they often start with something much more ambitious and amorphous, hoping that it will just sort of magically work out. They, they eat the swimmer’s food thinking they’ll get the swimmer’s body.

Uh, and if you are interviewing at one of these companies, you might find the interview process looks quite robust, right? It’s probably got a schedule and lots of interviews and a structure. But then when you go into these interviews, it might feel a bit procedural and hollow. The people doing the interviews might not really seem like they know what they’re doing Exactly.

And if you get an offer, you don’t know if you are the right fit. You don’t know if you are able to do what this company needs you to do to succeed there because they haven’t tested you for that.

Okay. Last up.

And speaking of testing people for things…

This is number five

Asking for A, but testing for B

and of all the items in this list, this is the one that really gets my goat. So what does it mean? What does it mean to ask for A, but test for B? It goes a little something like this:

A company decides to hire a person for role A. They make a job specification for that. They post it online. They start accepting applications. They line up interviews. Then in those interviews, either on purpose or by accident, they don’t actually test to see if the person can do the advertised job A. But instead they test the person for some completely other quality B. And in the worst case, they test the person on completely irrelevant stuff that has nothing to do if they are good stuff. That actually obscures any measure of whether or not they’re the right person for this particular job.

So one way this happens is when the interviewer is waiting for the candidate to say the magic words.

And I have an admission. I’m not proud of it. I’m ashamed to say it, but I have run interviews like this myself.

Okay, look, in my case, I was hiring for frontend engineers. But I was testing for something other than that. Specifically I was testing to see if they could solve a very, very tricky, nuanced, deep and gnarly frontend problem. The problem had several different alternative solutions that all had different trade-offs. But there was one solution, one blessed solution that was flawless.

It was also something that no reasonable human, even if they were super talented, would ever arrive at by reasoning. And yet there I was a budding junior interviewer holding out for that rare candidate who could just say the incantation flawlessly. And literally, I wouldn’t advance them even if they gave me every one of the alternative solutions to this problem.

I was forcing them to give me the non-obvious solution or they failed. So while I thought I was hiring for frontend engineers, what I was actually testing for was has this person read the source code of the types of libraries that have needed to solve this problem and have done the copious amount of research required to find the one solution that actually works.

Those are not the same thing.

It makes me frustrated, honestly, to think back at how many people I rejected who were probably great, but they just didn’t know the magic words. And just the same, how many people did I pass through to the next stage of the interview process who just happened to have read those particular lines of source code previously?

It’s honestly embarrassing. Uh, but, uh, you know, no one’s perfect. We live and learn.

Another form of Asking for A, but Testing for B is something I encountered, uh, in New York at one point. Uh, I had been flown from London to New York by a company for interviews, and they were asking me, you know, some bread and butter reasonable coding interview questions.

Uh, I was solving them. It was going pretty well. But on the second coding interview… If I remember correctly, I was being interviewed by their CTO and he challenged me about the way I had structured my code. If I remember correctly, his exact words were, “isn’t your code insufficiently polymorphic?”

Now… honestly…, um, if someone brings up fairly high and mighty ideas, such as the, the correct amount of polymorphism, uh, of your code in a coding interview scenario, that’s already a bit of a smell, just feels like the wrong place to launch into a debate like that. These are the sorts of things that engineers sink loads and loads of time into. Becomes religious wars. Feels weird.

But even more than that, I actually didn’t agree with him in this case. In, in my opinion, the code would’ve been actually less coherent if I had intentionally made it polymorphic in this context, and it was, it had to do with the way the two pieces fit together anyway, it was all on the whiteboard together. There wasn’t any other scenario that was obvious.

So I just challenged him back and said, ‘I don’t know, man. Like here’s why I think it’s probably fine to be as not polymorphic as it currently.’ He gave me kudos. In fact, he used the sentence “that was well defended,” and it was at that moment I realized I will never join this team.

The thing is he was interviewing me for a tech lead manager sort of role. Uh, someone with , uh, product UI experience. I was gonna help build their core product. But what he was testing me for was whether or not I had enough backbone to stand up to him in like this weirdly academic, largely irrelevant debate about like code structure for whiteboard code we’re gonna throw away anyway. It just felt weird.

Like, you know, who fails interviews like that? Uh, anyone who isn’t as disagreeable as me or as self-confident as I was that day. Uh, so like just knowing interviewing, that means you’re gonna filter out like the women that you interview, uh, the people of color. That means you’re very likely to filter out all of the people from underrepresented backgrounds who don’t know that style of debate.

It means you massively bias your hiring towards people who debate this way. Uh, people who happen to have a form factor similar to mine. Um, people who like rhetorical jousting.

I personally hate working with people like this. Uh, I want people who can like, make pragmatic choices and get a lot of work done. This CTO wasn’t hiring for that, even though that’s what they claimed they were hiring for on the job spec. It’s a bummer.

Another form of asking for A, but testing for B that I’ve seen just recently is when an interviewer accidentally demands that the interviewee have cultural background that they might not have.

So the story goes like this.

I know a really thorough, detail oriented, design savvy frontend developer. She’s been looking for a job recently. Uh, decided to leave her previous role and is on to the next thing. She was telling me about some of the interviewing that she’d done, and one of her experiences really stuck out.

She was talking with a tiny startup that was hiring their first full-time frontend developer. The person doing the interviews was a backend developer who had sort of learned enough frontend stuff to get by and realized that they needed to hire someone for the job. They had no designer and they had never hired a frontend person.

If you were paying attention before, this is, this is risky territory already. So what do they do? They ask this frontend developer to design the data model for the game Mastermind. Does that sound fine?

Well, the average backend engineer might be surprised to learn that the majority of frontend developers never actually learn like the concept of data modeling in any detail. Like, sure backend developers have to do this because you have to turn stuff into database columns and rows, but most frontend developers don’t. And inversely, how many backend developers know about UI contrast or accessibility? How much do they know about, uh, tab index management or optimizing for TTI on the client?

The backend developers don’t know that stuff. So here we have an interviewer who is hiring for a frontend skillful person, but testing them on backend skills. Yeah, guess how well that went? Right?

And this interview has the bonus problem that the interviewer believed it was completely reasonable to base the interview on the classic board game Mastermind.

You might have already guessed it, but uh, this particular frontend developer didn’t grow up playing Mastermind.

Uh-oh, right?

Like now you’re spending the first 10 minutes of the interview trying to explain how a game works that the person has never seen. And instead of testing the candidate for the skills she actually needs, , the interviewer has instead…

Let’s see, tested, um, how much his or and her backgrounds are the same.

That’s not the right thing.

Uh, and they also tested how much of his job this frontend developer could do, which is not what they want her to do as her job.

So that’s like basically a total fail.

And you know, the, the, the part that really gets me is this frontend developer was actually really excited about the role and the company.

Her background would have been a great match for what they needed. If I remember correctly, it was a FinTech company building data tools, and her background was in finance and data analysis, and she had transitioned into tech a few years back to become a frontend developer. So that’s a super uncommon candidate with a surprisingly complimentary background, and they completely dropped the ball interviewing her.

So that’s the list.

There are, of course, way more ways a company can fail you as an interviewee. But this is, uh, let’s call it the, uh, the greatest hits of interview failures. I hope if you’ve made it this far in this video that you found it useful. Failing an interview, it takes a big toll on all of us. I hope this video gives you some pause.

A chance to consider whether or not you need to beat yourself up. I mean, obviously we can all grow and learn and do better, and sometimes we, we earnestly fail interviews. But sometimes the fault is not in ourselves, but in our stars. And by stars I mean interviewers who don’t have their shit together.

So if you’ve had an experience where your interviewers dropped the ball, I’d love to hear about it. Tell me about it in a comment. Let’s, let’s, uh, start the discussion about that.

If you’re a longtime subscriber to this channel, you might know this is the first video I’ve uploaded in a while. The thing is, I am hoping to revive this channel in the coming months. I’ve got a number of ideas that I’m working up.

Uh, one of them is to have live interviews and then do like a commentary on them, sort of like a reaction style video. But for that I need some brave souls who are willing to jump in there and be interviewed on camera. So if that’s you, if you are excited by the idea of that, hit me up on Twitter. My, my Twitter handle is @jgbbrd. I probably just did that backwards. Um, I’m looking forward to hearing from you.

Uh, and again, I can’t make this video without plugging my company. That’s the reason I’m on screen right now. My company is cord.com. We make the sickest collaboration SDK you’re gonna find out there. You gotta check us out. It’s the real deal.

Thank you for watching.