According to news (eg https://www.theregister.com/ai-and-ml/2026/10/28/anthropic-engineer-declares-the-coding-interview-dead/5306115) - coding challenge interviews are dead.
Good, they sucked. For almost all things I've ever done, interviewed for as an interview or interviewed as a candidate? The answer to "build me a linked list" should be "it's 2026, we should be using a library."
What about the other end of it? Is it just all AI agents and people skills? Well, it depends on what you want.
Anyone building a linked list from scratch is almost always doing the wrong thing in 2026. (Well, unless you need to build a toolchain, OS and library from scratch and at THAT point? Sure.) Knowing how they behave, when to use them and when not to use them is much more important. I'd like you to know that a double linked list is O(1) on all operations except insert and lookup, and for low level software / firmware folks I'd like you to know why you'd want to use a single versus double linked list.
This was something I clashed at during my time at Facebook/Meta. Other interviewers would over index on data structure and language knowledge. This is stuff you can acquire (even before the current LLM driven craziness, humans are indeed capable of learning stuff on the job!) I didn't mind if you didn't know the deep details of C, C++ or Python. What mattered is how you solved basic problems, how you communicated that stuff, and what your domain knowledge is. If you knew the language backwards but you couldn't describe what you were solving, or you'd keep using arrays where you needed to use hash tables then I'd start asking questions like "why X instead of Y?".
And honestly? I think that stuff isn't going anywhere. You still need to know how the pieces work. You still need to know how data flows through things. You still need to know how computers talk to one another. You need to have learned how to organise your thoughts, how to learn new things, how to adapt to incomplete information, how to communicate it all and collaborate with others. Some of these are people skills, some of these are learning skills and some of these are engineering skills.
The big push with AI driven development and agentic workflows is showing a old-is-new-thing again, but in a much more immediately accessible way. Test driven development isn't new - but it keeps AI agents on the rails. Specification driven development is also not new - but it .. well, it also keeps AI agents on the rails. You can't do either unless you have domain specific knowledge, you've learned how to solve problems, organise your thoughts and adapt to incomplete information. We used to acquire these things by grinding through linked lists and figuring out how to debug programs.
Also - let's be honest with ourselves. Even before AI/LLM workflows became a thing, we still had a huge problem of badly written software and designed infrastructure by people who either didn't know or didn't want to know how to make things efficient. They had different outcomes in mind - prioritizing efficiency, correctness and well engineered solutions were already difficult in a world where outcomes were measured in lines of code, time to market and keeping executives happy with flashy demos. All that test driven and specification driven development? Have you seen how much CI gets grinded through daily at a large company, and things STILL are terrible? Are those specifications that people are writing actually useful, or someone's academic wish list with no real grounding in how they're going to behave in the real world?
People were already writing absolutely crappy performing web frontends and data backends that scaled purely because people knew solved the distributed work / sharding data problem because hardware was cheap and plentiful. App developers didn't necessarily care about how their app performed after being used for six months - who cared if an sqlite database tracking every piece of telemetry about app use it could grew to be gigabytes in size? Or how things behaved when the network was spotty? People were already spitting out CI tests that took too long to run, claimed code coverage metrics were met, but didn't actually fix fundamental issues with the codebase.
We can't blame LLMs for that. Humans were already designing, implementing and managing absolutely crap software to begin with, and .. some of those humans passed the coding interviews in the first place.
So if anything, now we're faced with a new dilemma - the cost of humans generating even more utterly crap code is much, much lower than it was five years ago, and that technical debt is going to bite you. Did your coding interviews where you asked people to implement maze traversal or a binary tree really help you with your engineering excellence? What's going to change if you just change to ask people how they code with AI agents?
Ie - what makes a good software engineer / developer in the first place?
I guarantee it has nothing to do with implementing a binary tree in a 30 minute coding question interview. It never did.
No comments:
Post a Comment