A Senior Dev Perspective

I just got off a call with someone who made a throwaway comment about the future technical interview and how they’d intervewed a number of Senior Developers who’d “forgotten everything they knew”.

This struck me as interesting, because I can relate to it. There have been a number of interviews where I’ve forgotten the name for X or not been able to pull out the specific detail they were hoping for.

The thing is, I’m not bullshitting my capabilites, but I’ve found that how I code, and how I approach coding has changed significantly over the past two decades with piles of languages and frameworks. That change in perspective is not something I find that most companies are well equipped to interview for.

The longer I code, the less I care about the specific details of any given language or framework. The longer I code, the more I care about quality and maintainability.

I’ve stopped chasing flashy feature rabbits. In 14 years of using Ruby on Rails I’ve literally never been hired to use the most recent version. I don’t care what features it has, because I’m not going to get to use them, and wishing for them will just make me frustrated with the feature set I do have to work with. Whatever language I’m hired for has a reasonable chance of changing over my time at a company. Two companies ago I was hired for Java and ended up writing Perl. At the last company I was hired for Ruby and Rails, but we ended up also using Elm, and Ember.

Focusing on the specific details of any framework or language just screws you when you move to the next one. Learning how to solve programming problems at the fundamental level, where the chosen language is essentially meaningless is what’s important. It’s what truly makes someone a senior engineer.

But… how do you interview someone, who may be a master in their field, but doesn’t care about details that really don’t matter? “What is [insert name of framework feature here]?” they ask. I may know. I may not. But, critically, not knowing is not indicative of “having forgotten everything [I] know” so much as it’s indicitive of having moved beyond the point where it’s important.

You could argue that without knowing about a new feature or technique, you can’t leverage it, and that’s true. There is value to staying abreast of the features of the framework or language you work in. Unfortunately the reality is that, excluding some rare and severly autistic people, essentially no-one knows all the details of any programming language, nevermind that and the frameworks, and libraries they use on top of it.

You can chase the rabbits of features and details with an essential guarantee of never reaching the goal of knowing it all, or you can become a generalist and learn how to program regardless of language and framework.

The more I code, the less I care about “all the features and quirks” of anything. I care about the shapes and patterns of software, and knowing how to match solution to shape. I care about having a codebase that a Junior can step into next week and understand what they’re looking at. I care about a codebase that I can come back to 2 years later and be productive in despite having forgotten all the details. I care about code that doesn’t break and waste my time.

But how do you interview for that?

Watch them think through a code problem. Don’t ask them about specific features. Then, if they satisfy you with how they went about solving the problem, not the solution itself, talk to them about coding. Talk to them about problem solving. Talk to them about common problem scenarios and how they’d work through them without worrying about if they mention a specific feature or function.

Honestly, it’s the how, not the what, that’s important. It’s the thinking and approach that make a talented programmer, not their knowledge of any specific thing.