Senior Dev Interviews

Posted by ThickySprinkles@reddit | ExperiencedDevs | View on Reddit | 63 comments

I’m the lead on a small team and am filling an open senior full stack role. The amount of applicants who aren’t able to hand code anymore is alarming. I am doing an entry level question over zoom as a first pass before we bring someone in to do a full in person round and do more difficult problems and technical deep dives.

Are other people who are running interviews seeing this? I get that it’s 2026 and we have codex, claude code, etc. But how can I sign off and bring someone in and potentially waste peoples time if they cant even run through or explain code for a simple problem. The problems are along the lines of simply counting distinct numbers in a list or distinct characters in a string.

To be clear I’m not looking for applicants here I’m more just curious if other people are seeing this and if people are changing their interview processes. I haven’t really interviewed since this LLM craze hit and am wondering if I should change my approach.

[-]

nasanu@reddit

You count distinct numbers in lists for your usual job? Weird.

[-]

Shifftz@reddit

Sorry, are you talking about actually hand coding something on the spot (not pseudo code, not code review, actually writing the working code)? Because people being rusty at that wouldn't surprise me. Every dev should easily be able to talk through problems like you mentioned. Ive been interviewing a lot of people recently and have not seen anything like you're describing.

[-]

RandomPantsAppear@reddit

I don’t think this is the best test now. It was always rough, but AI has made even good engineers rusty, and killed the take home test.

I would

1) Lean hard into systems design, but also looking for depth of experience - try to spot the passion that only comes from knowing the tech stack inside and out.

2) Do a take home, but expect AI to be used. See what their standards are, and the kind of work they will do.

——-

I actually sort-of failed an interesting take home (that expected AI) you might find of interest: Scraping an API endpoint, where there were ways to manipulate it to return data faster than it would normally. It was rate limited, but it also started a timer the second you queried the API.

If you were too slow in figuring out the tricks to make the API go faster, you wouldn’t have enough time to finish.

It tested how you think under pressure, not fizzbuzz.

[-]

gjionergqwebrlkbjg@reddit

The problems are along the lines of simply counting distinct numbers in a list or distinct characters in a string.

That's the problem they were asking. It makes no sense to waste your time on people who can't do that.

[-]

RandomPantsAppear@reddit

Fair. I missed that line.

[-]

My100thBurnerAccount@reddit

You'd be surprised at how seniors can't even do a basic todo app with react/vue/angular

[-]

kittysempai-meowmeow@reddit

Not all seniors do UI development

[-]

idontevenknowwhats@reddit

Ah yes, because react Todo apps are the best metric. This screams bootcamp lmao

[-]

My100thBurnerAccount@reddit

If seniors can't even reason through how to map, filter, find then 🤷‍♂️

[-]

idontevenknowwhats@reddit

Digging yourself a hole bro

[-]

mehtheswede@reddit

I haven’t written react

[-]

kittysempai-meowmeow@reddit

I think there are still plenty of senior devs who have no interest in AI and are likely to be pushed out at places that value AI so maybe in your ads you need to specify you are looking for people who can demonstrate their skills and knowledge without relying on AI.

[-]

kickerofelves_@reddit

Honestly this. I'm pretty turned off by job descriptions saying you need to show you've 100xed your productivity with AI. Saying you're looking for someone who can actually code would be refreshing.

[-]

GlobalCurry@reddit

This was a thing before AI, many seniors get pushed into more leadership/management adjacent roles. Also, If you're using leet code style questions it's likely they haven't had to do that style of programming since college.

[-]

Anttu@reddit

That would be me. I've been staff level for 5 years and the past 2 years I mainly mentor, attend a lot of meetings, drive projects and discussions and act as a knowledge repository when investigating incidents. Ask me to answer a leetcode question and I'll know what to do in theory but I'm not going to be able to solve it in under whatever time they expect. And if I had to actually program something like that at work I'd prompt LLM to use x data structure and do y, review it, and move on. Before AI, I'd google it. There's a difference between knowing what is the right solution and being able to implement it with no aid in an interview setting. I remember when the interview process involved watching someone solve a problem and being happy they looked at the docs, used Google and generally knew how to unblock themselves.

[-]

biosc1@reddit

As my boss says: I pay you to solve problems. I don't care how it's done.

[-]

HarmlessSponge@reddit

This is me. I'm more cloud eng and have been approached about a principal role ( I wasn't looking), and found out they use hackerrank for evaluation.

I think it's a perfectly reasonable expectation for a principal role, and also that I'm about to heavily bomb depending on what gets asked.

My programming ability is "good enough", but I literally haven't seen fizzbuzz or similar since college and the work scenarios so far haven't required anything in the space, as it's very infrastructure/config heavy in general.

Which hey it's fine and expected but jesus I'm going to have to study hard for a few months and I'm expecting to embarrass myself some first.

[-]

sfscsdsf@reddit

I’ve been using AI the last year, only doing minor edits by hand, also pretty rusty with hand coding. But I just had an leetcode interview and I knew that’s probably what I’d get, so I practiced some basic leetcode problems to get that manual coding feeling back. I realize i’ve lost some reflex level understanding and typing of coding syntax. So I’d say leetcode style problems should be treated as basic weed-out problem, you just have to dig into the problem’s tiny gritty details to get a sense of the candidate’s acuity on coding, which shows understanding of coding and how fast and well they can think logically, which is also needed whiling working with AI and reviewing AI generated code.

[-]

WolvesCallum@reddit

Nerves, the best software engineer l have met, could do things i wish i could. But cant do the interview process.

[-]

Kriemhilt@reddit

Solution: do more interviews, including ones you don't care about, and get over the nerves.

[-]

WolvesCallum@reddit

I bet you are a pleasure to be around, what a weirdo thing to say, just wanted to add to the conversation 🤣🤣

[-]

Kriemhilt@reddit

I'm an absolute delight in person, but text is fairly low-bandwidth and tone gets lost.

Is it so unreasonable to suggest that if you know something is required to land a job, it might be more constructive to practice that thing?

[-]

gjionergqwebrlkbjg@reddit

Don't even bother in this subreddit, it should be called ProfessionalVictims or something. It's always someone else's fault.

[-]

Dymatizeee@reddit

What did you ask ?

[-]

FlattestGuitar@reddit

Are you looking for people who code with AI or not? I haven't written significant code by hand in almost a year now, I'm going to be extremely rusty. I don't think it's a good way to gauge someone's abilities today.

Idk how I'd approach interviewing today but I'd probably spend a month or two on brushing up on my best languages just in case someone does want me to code by hand again in the interview room.

[-]

apartment-seeker@reddit

Look at what OP says he is asking:

The problems are along the lines of simply counting distinct numbers in a list or distinct characters in a string.

Someone should be able to do that without AI assistance lol

[-]

zonerator@reddit

The problem with saying "even a junior" is that this kind of thing is often easier for juniors because they have recently been studying pure code and syntax. Then they get a job and their brain is filled with system specifics and company specific logic flows and soon enough they are worse at "basic" coding than the typical hobbyists

[-]

apartment-seeker@reddit

Again, look at the actual question(s) OP has outlined.

Even assuming there is validity to "juniors have more recently been studying pure code and syntax", the problem in question is so damn ez it just doesn't matter.

[-]

zonerator@reddit

Thats fair. I am biased because I do pretty poorly in time sensitive code puzzles but the specifics they outline should be fine.

[-]

Naive_Freedom_9808@reddit

If you don't understand how to implement something basic using your own brain, them how can you be trusted to verify the output from AI?

[-]

FlattestGuitar@reddit

I understand just fine, I spent over a decade doing this in various stacks and languages. I just don't practice writing it manually much anymore. An unused skill atrophies.

[-]

rilened@reddit

Can't speak for OP, but in the interviews I'm a part of I wouldn't even expect you to know the minutia of syntax and, e.g. array methods by heart, but if you apply for a senior typescript position and you can't filter an array of objects by their name property (things I've seen people flounder at), then what are we even doing.

Kerninghan's law states that it's twice as easy to write code than to debug it, I would argue that extends to reviewing as well.

[-]

Riseing@reddit

Personally, I would never hire a dev that could not use punch cards. Once you prove you can use those we allow you to write in assembly for the rest of the interview process.

[-]

Idea-Aggressive@reddit

I’ve done a few live interviews, was able to provide solutions, code on the spot, etc, believe not exactly perfect. Did not get the offer. So, I don’t know how others who don’t even code are able to get opportunities and to offers.

Can you share the job description? I’m sure many people here who are glad to code live would be interested in finding work. I am definitely

[-]

lphomiej@reddit

Every time people post this, I just assume they're full of hubris, the interview process is broken, or you must be asking weird questions. If someone has been programming for several years, they are absolutely capable of answering "basic questions" about programming. Full stop. I've personally only been completely astonished by the talent pool available right now and the breadth of experiences and interesting, deep problems people talk about in interviews.

[-]

Vivid_Pond_7262@reddit

Is this a live coding scenario?

I’m 10+ YOE and even pre-agentic coding, I at struggled with these because of a) nerves b) contrived scenarios/problems c) unnatural environment to how I would experience day to day.

How to gauge ability? Ask open ended questions that allow them to reveal how they think, how they approach problems, etc.

[-]

Kriemhilt@reddit

Why are open-ended questions less susceptible to nerves though?

At some point you have to convince someone you know or can do something, and interviews are an unnatural environment for every type of question (unless you're interviewing interviewers).

If you can do open-ended questions under pressure but not coding, is that really because the type of question is essentially more suitable?

[-]

dj_estrela@reddit

Because open ended questions do occur in real work

Live coding pair programming style = never seen it anywhere

[-]

Mael5trom@reddit

There are still companies that do full on live pair programming as their default. Look up Menlo for example. Their interview is a full day of pair programming, I believe.

And any time you screen share with someone to debug an issue it's basically live coding pair programming.

That said, I agree that it's much less valuable in interview settings, because there is a level of nerves you wouldn't have in day to day pairing or for most companies, regular non-paired work. At the very least, it behooves a company that does this to do everything they can to reduce nerves, but sadly the companies that insist on this probably also haven't given much thought to how to put the interviewee as ease either.

[-]

Kriemhilt@reddit

You completely ignored the question about why they're more suitable under interview conditions.

So is your answer is that you never code where someone might see you? It's fine that everyone makes more typing mistakes when people are watching, but you can just fix it and move on with your day.

And yes, I've done live pair programming in the past. I don't necessarily recommend it, but surely hopping over to someone's desk for a quick code review isn't unusual, unless you're fully remote?

[-]

GlobalCurry@reddit

I personally hate pair programming and one of the benefits of remote work is being able to deep focus on problems in private.

[-]

kifbkrdb@reddit

It's because people think they can bullshit open ended questions.

[-]

GlobalCurry@reddit

I had an interview a few months ago where they kept correcting me for syntax errors on a white board (actual in person white board). In hindsight that was a great filter because I don't think I'd want to work with them based on that.

[-]

Friendly_Confines@reddit

I’m not a good interviewee. I take solace in knowing that if/when I do get the job that I will likely outperform expectations

[-]

McN697@reddit

I used to practice Leetcode and do the grind. I completely regret this. I feel awful when I think about the amount of things I could have built in that time.

I’m making that time back in spades with Claude. I’m far enough into my career to swear off Leetcode. Companies that over optimize on that skill are going to be left in the dust. There’s so much more to development than being able to hand edit code.

[-]

NotNormo@reddit

I remember having the same difficulty when I was hiring years ago, way before AI coding was a thing. I can imagine it's gotten even worse lately.

[-]

DCON-creates@reddit

I think if you're asking any level of dev to write anything other than pseudocode in an interview, you're going to miss out on a staggering amount of talent.

[-]

ThickySprinkles@reddit (OP)

I am fine with pseudo code. I get it, interviews are stressful and it’s not a great indicator of skills but at some level I need to filter out candidates to a degree. Otherwise we bring everyone in and waste so much time for everyone on the team who are already extremely busy.

[-]

NotNormo@reddit

Maybe that's a good middle ground. Try telling candidates to pseudo code a solution and the ones with problem solving and logic skills will still be able to stand out even if they've forgotten programming languages.

[-]

bombaytrader@reddit

I am rejecting to interview at small to medium size if I have to hand code. That time has gone dude.

[-]

ThickySprinkles@reddit (OP)

Yeah my take on it is if I can’t verify you can walk through a simple task/problem and understand the code you are writing or looking at how can I trust you have the ability to verify the LLM output. At that point you are just blindly trusting the tool and are adding no value to the engineering process. Thats my take at least and I’m trying to see if it’s outdated or what other people are doing.

[-]

DeterminedQuokka@reddit

I mean I’m seeing it. But also 8 years ago we used to ask people fizz buzz and they used to fail it. So it’s not that new.

[-]

luna_code_vibes@reddit

seniors used to forget syntax now they forget how to think without claude

[-]

EyesOfAzula@reddit

I would understand the writing code part given the age of AI, but at a minimum I would need them to be able to explain the code.

Otherwise, how would you debug and how would you be able to tell when the AI is wrong?

[-]

freefallingmonkey@reddit

Honestly, when I started passively interviewing again and prepping interviews again, it probably took me a week to get comfortable coding live manually again (either scaffolding from scratch or basic algo test) and like two weeks of interviewing to relearn maintaining composure and mental clarity during interviewing rounds.

Perhaps, those people just started applying to jobs , so they aren’t as battle ready for interviews?

For me, interviewing is just a separate skill, so maybe for them, the interviews they had with you where their “oh s**t I need to lock in”

[-]

nyckulak@reddit

I think engineers are being asked to know so many things now that sometimes some of us can have blind spots and not know something that might seem “basic” to someone else.

Not saying this is what’s happening in your case, but just something I’ve noticed

[-]

phantomplan@reddit

They should absolutely be able to reason through an approach and build (in their preferred language) a simple algorithm to count distinct characters or unique numbers in a list. If they can't do that without leaning on AI, then they're lacking some critical thinking skills, and at that point they're just a middleman to chatgpt that does the work. We already have job titles for middlemen, that's a management thing

[-]

NoobChumpsky@reddit

We've been mostly relying on code review and system design type exercises. It lets you understand if they can walk through a non-trivial app, read code, and handle architecture.

I think that's more relevant than hand writing code for a toy problem.

[-]

ThickySprinkles@reddit (OP)

Yeah this is the plan for the more in depth technical round when they come in person and meet the team. I agree this is more valuable in understanding a skill set. But doing that in a 20-30 minute quick interview just to get a gauge whether to bring them in or not I’m not sure is enough time to work through all of that. Maybe I’ll pivot a bit and come up with something along those lines for the initial pass.

[-]