Something’s been bugging me about how new devs and I need to talk about it. We’re at this weird inflection point in software development. Every junior dev I talk to has Copilot or Claude or GPT running 24/7. They’re shipping code faster than ever. But when I dig deeper into their understanding of what they’re shipping? That’s where things get concerning. Sure, the code works, but ask why it works that way instead of another way? Crickets. Ask about edge cases? Blank stares. The foundational knowledge that used to come from struggling through problems is just… missing. We’re trading deep understanding for quick fixes, and while it feels great in the moment, we’re going to pay for this later.
Those are good approaches, I would note that the “90% is written” one is mostly about code comprehension, not writing (as in: Actually architect something), and the requirement thing is a thing that you should, IMO, learn as a junior, it’s not a prerequisite. It needs a lot of experience, and often domain knowledge new candidates have no chance of having. But, then, throwing such stuff at them and then judging them by their approach, not end result, should be fair.
The main question I ask myself, in general, is “can this person look at code from different angles”. Somewhat like rotating a cube in your mind’s eye if you get what I mean. And it might even be that they’re no good at it, but they demonstrate the ability when talking about coffee making. People who don’t get lost when you’re talking about cash registers having a common queue having better overall latency than cash registers with individual queues. Just as a carpenter would ask someone “do you like working with your hands”, the question is “do you like to rotate implication structures in your mind”.
judging them by their approach, not end result, should be fair.
Yup, that’s the approach. It’s okay if they don’t finish, I want to know how they approach the problem. We absolutely adjust our decision based on the role.
If they can extend existing code and design a new system (with minimal new code) and ask the right questions, we can work with them.
I’m just getting started on my third attempt at changing careers from sys-admining over to coding (starting with the Odin project this time). I’m not sure the questions you ask, while interesting, will be covered. Can you point to some resources or subject matter to research to get exposure to these questions? The non coding, coding questions are interesting to me and I’m curious if my experience will help or if it’s something I need to account for while learning.
We stay away from riddles, and instead focus on CS concepts. We’ll rephrase to avoid jargon if you don’t have a formal education, or it has been a while. Here are a few categories:
OOP concepts like SOLID
concurrency vs parallelism, approaches for each (generators, threads, async,’ etc), and tradeoffs
typing (e.g. is a Python strongly or weakly typed? Java? JavaScript?), and practical implications
functional programming concepts like closures, partial application, etc
SQL knowledge
types of tests, and approaches/goals for each
And some practical details like:
major implementation details of our stack (Python’s GIL, browser features like service workers, etc)
git and docker experience
build systems and other dev tools
That covers most of it. We don’t expect every candidate to know everything, we just want to get an idea of the breadth and depth of their knowledge.
Those are good approaches, I would note that the “90% is written” one is mostly about code comprehension, not writing (as in: Actually architect something), and the requirement thing is a thing that you should, IMO, learn as a junior, it’s not a prerequisite. It needs a lot of experience, and often domain knowledge new candidates have no chance of having. But, then, throwing such stuff at them and then judging them by their approach, not end result, should be fair.
The main question I ask myself, in general, is “can this person look at code from different angles”. Somewhat like rotating a cube in your mind’s eye if you get what I mean. And it might even be that they’re no good at it, but they demonstrate the ability when talking about coffee making. People who don’t get lost when you’re talking about cash registers having a common queue having better overall latency than cash registers with individual queues. Just as a carpenter would ask someone “do you like working with your hands”, the question is “do you like to rotate implication structures in your mind”.
Yup, that’s the approach. It’s okay if they don’t finish, I want to know how they approach the problem. We absolutely adjust our decision based on the role.
If they can extend existing code and design a new system (with minimal new code) and ask the right questions, we can work with them.
I’m just getting started on my third attempt at changing careers from sys-admining over to coding (starting with the Odin project this time). I’m not sure the questions you ask, while interesting, will be covered. Can you point to some resources or subject matter to research to get exposure to these questions? The non coding, coding questions are interesting to me and I’m curious if my experience will help or if it’s something I need to account for while learning.
We stay away from riddles, and instead focus on CS concepts. We’ll rephrase to avoid jargon if you don’t have a formal education, or it has been a while. Here are a few categories:
And some practical details like:
That covers most of it. We don’t expect every candidate to know everything, we just want to get an idea of the breadth and depth of their knowledge.
Love it. So much to look into. Appreciate your time.