What matters in a senior engineer job interview

Degree matters if you have nothing better to show, consulting and BigTech backgrounds are negative, too many seniors can't code.

Part of working with a growing company has been interviewing. A lot. 17 interviews for senior engineers in 18 weeks, I counted. Felt like more 😅

Everyone I interview considers themselves a senior engineer, talked to our recruiter, and got a first thumbs up from the hiring manager.

My interview is a React pair programming challenge. Sometimes I'm the pre-onsite tech screen. The one folks cry about as The Leetcode.

It's not about leetcode, it's about showing you can code your way out of a wet paper bag 😉

Too many seniors can't code

2 types of candidates can't code – the very junior and the very senior.

Juniors struggle because they're fresh. Know a lot of concepts and ideas academically, but the visceral experience and battle scars ain't there yet.

Seniors struggle because they spend less and less time coding. More and more meetings, design docs, tribal knowledge, code archaeology, and mentoring. Suddenly you can't code.

Our "leetcode" is a question you can solve with a loop and a dictionary. Takes people 2 minutes to think of a solution, 10 to 15 minutes to code it up. Sometimes they choose Java and it takes 20 minutes.

Then we chat about curveballs and dig into "Anything you could improve?". The fun part.

Many engineers get stuck because their first stab is theoretically optimal. But algorithm complexity ain't everything my friend.

You can improve how it works in practice.

One day I'll find an engineer who says "Hey bozo there's a limited number of English words, get outta here with your memory performance question"

That's the corner cutting mentality you want in a startup engineer. Real world constraints that make the code easier to build. 😉

Read the instructions!

The React pair programming challenge tells you a lot about a candidate. Many promising senior engineers turn out to be mid-level instead.

You get a working toy project, a user story, and up to an hour to solve the problem. Pretend it's a work day except you can't use npm install solve-my-problem.

Almost everyone solves the problem. But it's tricky.

If you read the requirements and ask questions, you build it in 30min. Plenty of time to discuss optimizations, better solutions, debate about component design, and interview the interviewer.

If you don't, you'll take a wrong turn, make a bad decision, and it's gonna take 50min to build.

Candidates run out of time when building step-by-step with no plan for the end goal. You gotta have a plan.

Skip the fiddly details

Engineers have a hard time letting small fires burn.

Yeah sure the code is ugly and you have no idea how it works. But it works, has a name, and is self-contained.

Leave. It. Alone.

You do not have time to refactor everything in an interview. You won't have time to refactor our 600,000+ line codebase in your job either. Trust me, I wish I could.

Lots of dragons lurking around. Kill your dragon my friend.

That's my favorite signal to look for in a senior engineer. Will you look at a working non-leaky abstraction and lean into it, or waste time?

Kudos to you, if you can slay dragons and finish the user story.

Maybe focus on the user story first? 😉

Many engineers lose time on fiddly details, little design tweaks, tiny refactorings, then realize "Oh shit, I didn't read the whole story! There's more work than I thought!!"

Too late.

Too many engineers can't build

My biggest surprise was seeing how many engineers can't build.

Yeah sure they'll write fine code, design a reusable component, quickly grok existing code, understand React, and even ask good questions ...

... then they're like "Wait that's weird, why does the page reload when you submit a form?"

Because that's how HTML forms work, damn it! 😣

They're so used to working with an established framework they forget the basics. How to make a link, how to add a button, the behavior of forms, event bubbling, ...

Someone somewhere solved it all. Now they're reusing patterns, copying code around, and patching little details.

The system design interview highlights this the most. Many fail or get a flabby "yeah maybe".

Senior fullstack engineers who can't write a SQL statement, design a caching structure, think about scalability, or deconstruct a fuzzy ask into a clear model schema ...

Why consulting and BigTech backgrounds are bad

And that brings us to the most surprising revelation of all 👉 BigTech engineers are bad.

Great at what they do for their companies. Likely flop in a startup.

Consultants and consultant-like folk are great at talking a lot, generating reports, giving advice, and taking up space. Where they falter is getting shit done.

It's like the lesson from Moneyball, doesn't matter who's on your team – do they get on base and score points? You need points.

Same problem with BigTech folk.

Lots of meetings, lots of process, lots of free time, lots of deep thought about a specific problem and all its implications for a bazillion users.

We don't need that. We need you to get on base.

Then build the tools to get everyone else on base. 😉

The best question to weed out senior vs. mid engineer

Why'd you do that?

I ask this a lot. While you're coding. 😍

Seniors explain every decision. Tradeoffs, implications, ergonomics, abstractions – there's a reason. Even if you disagree.

Mid-levels falter. It's how they've always done it. Or a tutorial said so.

Cheers,
~Swizec

PS: here's a bonus about job hopping that didn't fit the article

PPS: don't worry we do hire folks from BigTech and Enterprise when they show the right mindset. Unfortunately those places are designed to hammer it out of you by force. They need interchangeable robots.