Tech Stacks Are Overrated

In the process of interviewing dozens of junior and intermediate engineers, the questions candidates ask implicitly say as much about them as the rest of the interview. One question that comes up occasionally is some variation of “what tech stack are you using”? List some of the myriad Javascript libraries-du-jour and I get a murmur of approval; mention something mature and be met with silence or a disappointed “oh”. In fact, many outright say that they want to be working with the latest or “bleeding edge” technologies.

I get it, the “right” technologies are cool and shiny and have undeniable appeal. You feel invigorated when using them. For me, I’m excited about Elm, Crystal, and GraphQL.

But focusing on tech stacks and looking for the coolest technology during job interviews isn’t very valuable, and distracts from more valuable questions. Companies build software to reduce costs or capture value. Customers don’t care what tech stack companies are using, as long as they can get things done. A company using Node and bleeding-edge ES2018 doesn’t get to charge a coolness premium over a competitor using Rails; the shinier tech, by itself, doesn’t automatically create more value.

It can, however, increase costs. Mature technologies have a well-worn path to success: there are documentation or blog posts for everything you’d want to do, Stack Overflow questions for any issue you might run into, and a patch for every bug that might’ve existed in a v1. None of that might be true with the new and shiny, where any one of a dozen configuration options or plugins could break everything if you breathe the wrong way. There’s no clear path to a maintainable codebase and your ability to consistently create value in the long term.

Rather than ask “what’s your tech stack”, a more interesting question is why that tech stack makes sense for what’s being built. As a interview candidate, listen for a clear reasoning that makes sense — that’s a stronger signal of a company that’s more likely to be successful (and one where you can learn) than one that picked its technology based on what was cool at the time they started. To a good interviewer, that’s also a more impressive question.

It’s even more valuable to go beyond the technology and focus on the product and problem. What problem is the company trying to solve? How are they thinking about the problem, and what is their proposed solution? What kinds of problems do you want to solve? What kind of products do you want to build? As an interviewer, I’m looking for alignment between what we’re building and the problems and products you’re passionate about. As an interviewee, determine alignment around these questions first — and then you can ask about the technology, and whether that’s a reasonable choice for the problem. It’ll make for a much more interesting conversation for everyone.