I've been coding for 11 years now, and went from shitty CTO, to junior dev, to junior dev, to glorified junior dev, to senior dev, to lead dev, and then finally, to dev.

As I learned more and more, I took a step back to ask myself if I'd hire the dev I was 5 years ago. And truth be told, I would not. Because as I gained some experience through the year I also changed my standards when it comes to code quality, and to what I consider to be a senior dev. So, without further adieu, here are the 4 things I consider when hiring a new dev.

Product

This is, by far, the most important thing I look for when hiring a new developer. I'd rather have a dev that is a bit less experienced, but ask questions about the product, then a killer dev that has no interest whatsoever in what he's building. It's not about the idea of discovering the product, it's about your ability to question why the product was built this way.

Patterns

A junior dev will struggle, because he's still learning. A senior dev will also struggle, but he knows some patterns that will save him some time. With the rise of AI coding assistant, we also noticed an increase in "lazy" devs.

Don't get me wrong, if your AI assistant saves you 30 seconds by completing some basic stuff, that's great. But if you rely on your assistant to deliver a piece of code you don't understand, it's a lose-lose situation.

When I'm facing a new feature, or a new pattern, or any problem that requires learning something now, I know I'm going to struggle for a bit, and that's the beauty of our job: we fight, fall, but overcome. Now, your responsibility, once you find a solution and the solution has been validated by your team through a thoughtful review, is to write down your piece of code. I'm using obsidian as my note taking app, and it saved my a HUGE amount of time. From well-documented pieces of code to custom CSS styling, I got it all.

And the best way to discover said patterns is to work on side projects. If we're considering web development, I expect you to be able to handle a few basic patterns: authentication (and maybe authorisations), web sockets, database operations, routing...

Communication

I'm not talking about your ability to talk on a daily basis with every single member of the team, I'm talking about your ability to raise your hand when you're facing an issue. I have never ever blamed a dev that came up to me and said he was stuck. Any complication you face is an opportunity for the team to discuss, bring up new perspectives, and improve. But communication goes beyond this: when coding, your ability to communicate is defined by how clear your code is. In my current company, our only meeting is a 5 minute daily meetup that goes like this:

• Yesterday I worked on X, it went well, I'll keep on working on it today


• Ok, yesterday I worked on Y, I'm a bit stuck on [some topic], I'd appreciate it if someone could take a look.


• Sure, let's talk about it.

This is how you build trust, reliable code, and meaningful interactions.

Now, the rules of written communication.

I've worked in companies that required a lot of comments, and I've worked in companies that said that comments are only necessary when explaining a complex piece of code: in the end, if it's not a written rule, the decision is yours to make; but remember: this code is your responsibility, and if a new dev discover your code, 6 months from now, and starts crying in despair because you named your most important variable "foo", you lack the communication skill I'm talking about.

Team player

I took English classes at school. Yet, 99% of my vocabulary comes from music (all hail Aesop Rock), video games and movies.

Same thing goes for coding: I learned a LOT of stuff from coding school and from my previous jobs, but most of my coding experience comes from side projects. Which is a bit of a bummer: sure, you move faster when working alone, but you go FURTHER when working as a team.

Which means, you have to learn how to be a team player. And for this, I have only one rule: be good. Ask yourself when you hate the most when working as a developer. Here are a few of the things I despise, even though I love my job:

• 54 files, 3k lines of code changes in a single merge request. Just like Andy's old toys in Toy Story 2, this will either end up collecting dust in our list of MRs, or go straight to the trash.


• Squinting my eyes when reading a piece of code. Good code is like a good book: it tells a story. I don't. Want. To re. ad. a piece of co. de that looks
  As if you were
  having a stroke
  while writing it. See, that's hard to read, huh ?


• Linter and CI are your friends. Which means, if you write a critical piece of code, please test it. And if for some reasons your company does not include automated CI/lint check in your git flow, please make sure that your code does not break anything before asking for a review.


• When asked for a review, do not wait. In a perfect world, a MR should not live for more than 4 hours.

Now, obviously, on my end, I'll make sure to provide the best developer experience during our interviews. Which means, I will never ask you to send me a technical test that took you half a day to complete. I don't believe in 7-steps process, nor in online coding tests. Show me a project you're proud of, let's discuss it for a few hours, and I'll probably be able to assess your expertise.

This is the level of skill that I expect from a senior engineer. And this is the level of respect that any interviewer should give to someone applying to that position. Because in the end, a good senior engineer is a cornerstone.