I spent a year conducting technical interviews. Seventy of them. Frontend developers, tech leads, architects, career switchers. People from Romania, Moldova, the US, Greece. Self-taught developers who learned from freeCodeCamp, computer science graduates from top universities, a former Amazon manager who missed writing code, a guy who worked as a bouncer in Crete before becoming an Angular developer.

I asked about closures, prototypes, the event loop, CSS specificity. I asked about TypeScript, testing, deployment pipelines. Standard stuff.

None of that was the interesting part.

Every career follows the same arc

After about twenty interviews, the pattern became impossible to ignore. Every developer’s story follows the same shape: chaos, discovery, a ceiling, then a leap.

One candidate started in accounting, discovered programming through curiosity, and within two years was the sole frontend developer on a hospital management system. Another spent eight years on the same desktop application before realizing he might be missing something. A third taught herself through freeCodeCamp, formed a meetup to teach others what she’d just learned, and within three years was building procurement software for Coca-Cola and Metro.

The specific technologies didn’t matter. jQuery, AngularJS, React, Vue, Knockout. The arc was always the same. Find the thing. Hit the wall. Jump.

The developers who impressed me most weren’t the ones with the longest resumes. They were the ones who could articulate why they jumped.

The question that reveals everything

I had a list of technical questions. Closures, hoisting, falsy values, the difference between == and ===. Some candidates nailed every one. Some stumbled. The technical score rarely predicted who I’d actually want on a team.

The question that told me the most was this: “Who would you avoid at all costs in a team?”

Every single candidate had an immediate answer. No hesitation.

“Arrogant people.” “Whiners.” “The person who loses their temper.” “Someone who says ‘don’t bother me.’” “Verbally violent people.” “Closed personalities.” “People who don’t take code reviews well.”

One candidate, a tech lead, gave the answer that stuck with me longest: “If I’m the lead, I am responsible for my team anyway. Their mistakes become my mistakes.”

You can teach someone closures in an afternoon. You can’t teach that kind of ownership in a lifetime.

What people actually want from their managers

I asked every candidate what they expected from leadership. The answers converged so tightly it was almost eerie.

Trust and autonomy. Not micromanagement. Not someone breathing down your neck.

Transparency. Tell me what’s happening. Give me the real picture.

Being seen. One candidate said it exactly like that: “I’d like to not be ignored. Seen.” He wasn’t asking for praise. He was asking to be acknowledged as a person doing meaningful work.

Filtered pressure. A candidate described his ideal lead as someone who “owns the team’s issues” and “doesn’t let pressure slip through unfiltered.” Another said a manager fails when “they tell you there isn’t a problem when there actually is.”

Honest feedback. “Positives are ok, but I want to know where I can improve.”

Nobody asked for free snacks or ping pong tables. Everyone asked to be treated like a professional.

Self-taught developers have a superpower (and a gap)

A surprising number of the candidates I interviewed were self-taught. freeCodeCamp, Pluralsight, Stack Overflow, Telegram groups. One candidate said she’d answer questions on Stack Overflow that she “almost” knew the answer to, as a way of learning.

The gap was vocabulary. A self-taught developer might use destructuring every day but not know the word “destructuring.” They’d implement closures correctly but stumble when asked to define one. The knowledge was there. The labels weren’t.

The superpower was resourcefulness. These people figured things out without a curriculum telling them what to learn next. They built WordPress themes in a day to get hired. They formed meetups to teach what they’d just learned. They joined Telegram groups and asked strangers for help.

One candidate, when asked what roles she’d need on a project, said: “I need a senior for knowledge sharing. I miss having a senior because I had great reviews and learned a lot through PRs.” She wasn’t asking for someone to do her work. She was asking for someone to help her grow.

That’s the signal. Not “I know React.” But “I know how to learn.”

The 10pm client message test

I started asking situational questions because the technical ones felt incomplete. One of my favorites: “Your client messages you at 10pm about an urgent problem. What do you do?”

The best answer I got: “I’d let them know I’ll answer in the morning. I’d let them know it shouldn’t be a problem. I’d diminish the panic as much as I can.”

Three things in that answer. Boundaries. Reassurance. Emotional regulation. That’s not a JavaScript skill. That’s a professional skill. And it’s worth more than knowing the difference between microtasks and macrotasks.

Another situational question: “How would you tell a client about a very big problem?” The answer: “I’d be super fair. Explain that I made a mistake. Pressed by time. I’d maximize the effort of data recovery through involving the team. I’d take responsibility.”

No deflection. No blame. Just ownership. In 70 interviews, maybe five people answered like that.

The real interview is the conversation

Here’s what 70 interviews taught me: the best developers aren’t the ones who can recite the event loop from memory. They’re the ones who can describe a problem they solved, explain why it was hard, admit what they got wrong, and articulate what they’d do differently.

One candidate talked about optimizing 300 parallel tests that were timing out. He didn’t have a textbook answer. He tried things. Failed. Tried more things. Eventually solved it by running the suite on his gaming PC at home. That’s not elegant. But it’s real. And the thinking behind it, the willingness to keep pushing, was worth more than a clean whiteboard solution.

Another candidate, a former Amazon manager with 20 years of C++ experience, said something I think about often: “I want to become an expert in as many things as possible. I won’t miss C++. And people management. I’m a bit saturated.”

Twenty years of experience, and he was still hungry. Still willing to start over as a beginner in a new stack. That’s the person you hire.

What I’d change

If I could redo those 70 interviews, I’d cut the trivia in half. I’d keep closures and async because they reveal how someone thinks about code. I’d drop hoisting, falsy values, and most of the “gotcha” questions. Nobody writes production code that depends on knowing that typeof null === 'object'.

I’d spend more time on stories. “Tell me about code you’re proud of.” “Tell me about a time your team broke something in production.” “What did you learn from the worst project you’ve ever been on?”

And I’d always, always ask: “Who would you avoid in your team?” Because the answer tells you who they are. Not who they pretend to be in an interview. Who they actually are when the work gets hard and the people get difficult.

Seventy interviews. Seventy careers. Seventy different paths through the same tangled web of JavaScript, career ambition, difficult clients, and the universal human need to be seen and trusted.

The technical questions were never the point.