Burn Rate

Developer Archetypes

While talking to a friend about interview prep, I had a realization about how I go through interviews. Specifically, I try to figure out the archetype of my interviewer and tailor my interview to that archetype.

What do I mean by archetype? I’ll illustrate by way of a character named Morgan. Morgan doesn’t do side projects. They go to work, where they are a senior developer. They keep up to date on technology, but they don’t actively seek out the cutting edge. They care about best practices, however they recognize that shipping is the ultimate goal. They emphasize work-life balance and don’t work outside of normal hours barring extreme cases.

I’d categorize Morgan as a pragmatist archetype. They clearly care about programming, but they’re not hyper passionate. They’re likely a little older, possibly with children. They likely espouse concepts like “the right tool for the right job” or “code is meant to be read, not written”.

Keep in mind I’m not making any value judgements about this archetype. It may sound like I’m being derogatory, but unfortunately that’s a side effect of creating these archetypical or rather stereotypical portraits. I’d love to work with any of these people.

If I’m talking to someone like Morgan in an interview, I’m not going to wax lyrical about my love of Rust. Likely if I were to do so, they’d see me as a naive, overly language obsessed novice1. Instead I’d probably talk to Morgan about the importance of writing good code and how tooling can facilitate stable, scalable services.

However, let’s take another archetype, Jaime. Jaime loves to spend their time reading tech blogs and following the latest news. They started out writing Ruby, then got really into Go, then Rust and have written some significant libraries for all of them.

Jaime loves to write code, sometimes to their detriment. They’re not as involved in the business, corporate end, but really have a deep knowledge of the tech. They care about stuff like performance, and idiomatic code and can tell you when you’re doing something potentially hazardous.

As an archetype, Jaime is an adventurer. They love being the early adopters of new technology and are willing to delve into unknown territory to get there. They likely are younger, as they have the time to teach themselves. If I were talking to Jaime, I’d go out on my Rust knowledge and the cool stuff in the ecosystem. I’d talk about stuff like WebAssembly or dependent types or Haskell. It doesn’t matter if any of this is related to the job. It’s more about communicating that we’re on the same wavelength.

Within these archetypes is really several qualities that go on a spectrum. Stuff like “valuation of work life balance”, “interest in new technology”, their age, etc. In my experience, they’re correlated enough that you can use these archetypes.

There’s also several qualities that are not correlated with these archetypes such as competence, social skills, intelligence, etc. There are profoundly smart programmers who are pragmatists and there are extremely not-smart programmers who are adventurers.

I realize this may seem cynical. I’m showing selective sides of myself to get hired. I’d counter that we do that every day. Geez, read some Goffman. Also, it’s not as disingenuous as it may seem. I’m a firm believer that programmers have a responsibility to read the room and tailor their programming styles to their company/team. If you work with a bunch of pragmatists, maybe don’t try to get them to use Rust all the time. If you work with some adventurers, you’ll probably have to learn some new tech. Of course you can have influence over your coworkers as well. People learn from each other and having both a pragmatist and an adventurer on a team can lead to even better results.

The pragmatist and the adventurer are the main archetypes that come to mind. I’m curious if there are others. Of course there are nuances to these archetypes like ability, experience and degree. But are there other archetypes that you’ve encountered? If so, feel free to reach out and let me know.

  1. Which, yeah, probably guilty 

This project is maintained by torchNYU