They Don't Even Know the Fundamentals
We enjoyed the dialogue around this article on the frustratingly vague nature of programming fundamentals from HackerNews and asked our Engineers in Residence their thoughts.
Ben Juarez said that when he worked at a Fortune 100 company, he attended Community of Practice (COP) meetings every other week, where an engineer would present on a topic and the group would discuss. Ben says, “This article does a good job discussing the grey (Gray? See what I did there? That’s also a CSS reference!) we see everyday as devs. Some things do matter more to one dev than to another when it comes to their bread and butter skills.”
Angus Kinsey echoes those sentiments: “When I started at Centare, I was immediately quizzed on SOLID programming. Thank God it was during a learning moment and not an interview, because I'd never heard of it. That said, the underlying concepts were logical and mostly fit into my existing practice, I just didn't have a cool mnemonic.” Meaning that just because you don’t know a definition, doesn’t mean you don’t understand the context.
Building off of this example of different interpretations of REST, varied meaning does not necessarily imply varied levels of correctness. Context is important! As Ben explains, “...Not all devs are the same, even if we know the same stack. Priorities as to what’s important to one dev are different for another.” Angus agrees with the idea of prioritizing the “what” over the “how” — “It's less important to know a specific tool than be able to research and vet a tool or concept for application to the current problem in a rapid manner. Adaptability, and not knowledge itself, is the best advantage of a modern dev.”
The article also points out that, “If the terms are so vague and so many interpretations are possible...I don’t think we can really treat them as fundamentals, as fundamentals are not supposed to be open for interpretation.”
So how does this translate to hiring FOR fundamentals?
Ben says, “That’s what makes it hard to gauge a candidate and how they’ll fit into a team with different opinions. This is why culture is super important, because it helps set up boundaries for opinions to be expressed without affecting the day to day work.”
Angus adds that, “A better way to interview is to be ready to add enough context that the person on the other end can draw connections to the work they've done in the past, or prove they can have an intelligent conversation about [it].”
He continues, “It doesn’t feel quite appropriate to dismiss the concept of ‘fundamental knowledge’ outright. That said, I enjoy the framing of ‘foundational knowledge’ much better. ‘Foundational knowledge’ is the knowledge that you will need as a foundation in order to be successful in your role. Building from there, it’s important to be very intentional in considering and defining what a candidate truly needs as a foundation in order to be successful in their role.”
There will ALWAYS be context to learn on a new team. You will ALWAYS be working with new people, and using technology in a unique way. If that wasn’t true, there would be no point in building anything new; you could just buy everything off the shelf.
Let’s get real. Are you hiring a dictionary, or a creative, abstract problem-solver? If you’re interviewing around the formal definitions of ACID, you probably haven’t spent enough time thinking about what kind of team member you want to hire.
To end with something practical—consider a case where your team is working in a highly regulated industry and has identified TDD as the ideal way to maintain quality and security. You’re likely going to turn away some bright minds if your first screening question is, “Tell me when and how and why you used TDD in the past.” What would be more effective is gauging foundational experience working in quality-first environments, writing things like unit and integration tests every sprint.
Hiring is always going to be nuanced. Let’s put in the work and set up our people for success.