Ten years of experience, still failing phone screens

and a better algorithm can often be over-engineering, so it needs context in the question-giving

I preface my interviews saying that I'm we're going to have a conversation rather than a list of trivia questions. The goal is find out what the candidate knows, rather than if they know an answer to any specific question, or specific version of a technology. If I ask a question that is too easy, it's not a trick, it's a segue to more conversation. If I ask a question that's incomprehensible, it's because I don't have a prepped list in front of me and I'm making some questions up on the fly, and the candidate should just ask for clarification. Also, that a lot of my questions are open ended, or have multiple right answers and any of them are acceptable.

It's not really a pattern of interview I expect most people can implement immediately, but it really gives a good idea of fluency. I just have to home in on what they do know. The easy questions get some momentum going and provide context for the follow ups. When they don't know an answer I'll tell them the answer. Sometimes this leads to them adding some depth beyond that answer as they know what's going on but haven't worked with it formally, or have worked with it in passing, or maybe know it by a different name.

> Today's interview process seems eminently gameable by grinding LeetCode and watching YouTube videos on system design.

That is a feature. You look at what they worked on before to see if they are senior material. Then you do leetcode and system design to see if they are smart. A smart person would most likely learn whatever tech and problems they worked on, so if they do well on leetcode you just assume they did well in their past jobs. If they can't learn leetcode then you assume they did poorly in their past jobs. If they didn't practice leetcode then you got no signal on their smartness, so no-hire due to unpredictability.

So we get these possible results and what you do with it:

- Good leetcode, great and relevant experience: Hire at high level, this guy is smart so he likely learned a lot of things during his past experiences.

- Bad leetcode, great and relevant experience: no-hire, he might be smart but we don't know so we don't know if he actually performed in his past jobs.

- Good leetcode, no/minor expereince: hire at junior level, this guy will likely learn fast

- bad leetocde, no experience: don't hire, there are no positive signals.

This works really well actually. The only bad part is that some experts needs to brush up on this when they want to find a new job, but for a well paying company that isn't a problem as millions of candidates gladly brushes up for the pay bump.

If you are smart and a hard worker then learning it properly is easier, yeah.

But if you are lazy and prefers talking to people and watching videos, so you spend your day talking about these conferences with your colleagues rather than doing work then you have the scenario I'm talking about. It doesn't require some genius conman, basically any guy who prefers to talk about things instead of doing things will more or less fit this description. The degree they lack real skills depend on the degree they prefer talking over doing, but such people will always over perform at such interviews.

Lastly since the talkers get rejected by all the leetcoding firms, you will have an abundance of talkers that can't perform in the hiring pool. So the problem with talkers is way worse today than 20 years ago.

It's important to remember that it's also YOU interviewing THEM.

The coding interview is an opportunity to get to know the company culture in a very feet-on-the-ground fashion. How the interviewer behaves and how they expect you to do things reflects upon them as managers, mentors, and in general people you'll be working with for potentially a long time.

- If they're forcing you to go against your natural flow, that's a red flag.

- If they're preventing you from building or explaining things as you'd normally do on the job, that's a red flag.

- If they don't allow you to consult the resources you'd normally do, that's a red flag.

- If they prevent you from testing your work and assumptions as you'd normally do, that's a red flag.

- If they're only looking for work and no conversation (all questions to you and none to them), that's a red flag.

I've had times during an interview where I've had to pause everything and explain that this is how I work, and how I would work if I were hired. Usually the interviewer will stop, reassess, apologize and we move on no harm no foul. I've also had occasion to stop the interview and say that we're not going to be a good fit, sorry and goodbye.

It's on YOU, the interviewee, to make sure that you're not getting bullied or coerced (either accidentally or deliberately). This is not a one-way street. If you don't push back, at best you get hired into an abusive or incompetent environment, and at worst they reject you after toying with you, wasting even more of your time and sapping your morale. Yeah, it's a bad time when one hires a bad employee, but it's MUCH MUCH worse to get hired into a bad company! You're taking a bigger risk than they are, so make sure you interview them well!

Breaking off an interview is not a bad thing; you're assessing THEM as much as they are assessing you, and eliminating the deadwood early is in your best interests, because YOUR time and resources are precious too.

Remember: THEY can fail phone screens, too.