Why is nobody addressing the elephant in the interview room?
Posted by ninetofivedev@reddit | ExperiencedDevs | View on Reddit | 10 comments
So interviews have never really aligned with what your typical software engineer does, so maybe this is just SSDD.
I haven’t had to think about writing code in 6 months. I read a lot of code and I can pick apart when code is not doing what it should be doing.
I’ve made this argument for years, that writing out a solution is harder than understanding what someone else has wrote and inferring the solution. It’s especially true with leetcode problems where understanding why something works is often clear once you see the solution.
Now my interview process has never required writing code. It’s honestly not something I’ve ever cared about when hiring senior engineers.
And that seems to be true now more than it ever has been. Tell me about something you built and the impact that it has. Explain to me how you use AI to help build a product. Explain how you define success criteria, how you ship to production, how you handle state and persistence and changing database.
Like if you can talk about concepts with me, I usually can sniff out the bullshit artists.
But anyway, I have an interview this week and it’s leetcode. I’ve historically been good at these, but I haven’t done one since switching to almost entirely agent based workflows.
BOT_Pain@reddit
Another post about AI but flavored as something else..
RunnyPlease@reddit
I’ve not only had to write code during the interview I’ve been given take home assignments where I had a set amount of hours to compete the coding tasks once I opened the page.
I also had one company give me a take home code review where it was my job to comment on the code review and make suggestions for improvement.
My guess is a few companies have been burned by slick talkers that couldn’t back it up with actual ability to write code. Or maybe they were very good coders just not in the specific tech stack the company used. I bet it’s a tough day in the office to find out the Sr Engineer you just hired with 6 years of experience has only worked in JavaScript and never coded in a compiled language before. I’m not saying I agree with it but getting burned once would be enough to cause a reaction. So I understand.
Yeah. I think that divide is going to get worse as time goes on.
Companies have already been using leet code style questions as a filter for too long. If you can google the answer in 10 seconds it’s not worth spending 10 minutes of an interview having the candidate reverse engineer the known solution. That has been true for at least a decade but some hiring managers still throw out the linked list problems as if that’s what an engineer does every day.
The problem with getting rid of them is those gotcha technical questions are a definitive and clean way of filtering though dozens of candidates that looks good on paper. At the end of a couple weeks the hiring manager can say “I asked 24 candidates the same question. 4 got the best answer. 2 candidates got it with minimal assistance. I suggest we pass both to the next round of interviews.” You can’t say that doesn’t sound good to a business type.
For some hiring managers it’s like a secret handshake for you to let them know you’re in on the scheme. You know how the game is played enough to keep on top of leet code questions. That’s all they need to know to confirm you get it. Some managers just want the secret handshake. They will probably never stop asking linked list questions.
caprisunkraftfoods@reddit
Gonna stop you there. It's been widely agreed for a very long time that exactly the opposite of this is true. If you feel otherwise then you've probably got a shallow understanding of the code you're reading, or your basic programming skills are atrophying a lot quicker than you realise.
t-tekin@reddit
Sorry what’s the question?
Yup reading code is more important than writing.
I wouldn’t say reading is easier. Really depends on the code base. Eg: 1M+ line code bases with different styles of 100+ developers, reading can be harder than writing.
But with AI all of this is changing yes.
ninetofivedev@reddit (OP)
A style guide really makes this a non-issue.
t-tekin@reddit
No I’m talking about humans not AI.
Basically I’m saying this statement was not 100% true:
“I’ve made this argument for years, that writing out a solution is harder than understanding what someone else has wrote and inferring the solution. It’s especially true with leetcode problems where understanding why something works is often clear once you see the solution.”
Regardless, what are you asking again with your post?
ninetofivedev@reddit (OP)
Most companies expect engineers to switch to agentic workflows.
At the same time, most companies still hire expecting engineers to write code out themselves.
mechkbfan@reddit
It's not an elephant in the room for me
I want people that think, not those that vibe coded their way to production.
ninetofivedev@reddit (OP)
Do you think that one is incapable of reviewing the code the agent generates?
You realize it takes thinking, like quite a bit of it, to ensure that your agents are building the right things.
You know what happens when someone pushes up AI slop to our code base? Their PR gets rejected and they have to try again.
You know what happens if it gets approved and breaks production. Well typically that never happens, but sometimes they break dev. And they get called out “yo. Anton. Your garbage ai slop broke dev.”
We know right away when someone pushed something without verifying it worked.
Which-World-6533@reddit
Yep. I do the exactly the same.
The real elephant in the room is that a lot of Devs that get to more senior positions and above aren't that good and are not able to do this.