My Favorite Way to Evaluate Software Engineers

When I mention a kata, I’m talking about take-home code testing, so I’ll use the two interchangeably.

I’ve interviewed for a lot of companies so far in my career and have always, personally, hated on-the-spot code evaluation. Interviewing for a new job is stressful enough, let alone deciding in real time who your partner will be.

Not everyone tests well, so putting those candidates in this position isn’t entirely fair to those people. I also find it annoying that creating candidates code inside a code answer where they have no access to the tools they use, such as autocomplete, IntelliSense, and so on.

For these reasons, I enjoy giving candidates chopped up what they can do on their own time with the tools they know and love. When someone is comfortable, I believe you get their best, and that’s what I like to rate someone on.

My ideal interview pipeline goes something like this: initial phone screen, candidate cuts the code at home and returns it, we evaluate it internally, and if the internal evaluation is good, the candidate will come up with their solution. comes to talk about.

During this in-person or remote interview, it’s a discussion about the solution and why they approached it the way they did. What did they think of the sign, and how long did it take? (It’s not used against them, but it’s good to know because you might have thought it should only take three hours, and it takes an average of six hours).

If you’re on the fence about the candidate’s coding ability, I’d suggest a simple feature change within the Kata solution that wasn’t originally listed in the hint. This can also turn into a pair programming refactoring session to see how the candidate works with others. It’s really up to you to decide!

The kata you write should ideally request the tech stack in which you want to do it. The sign you write should apply to your company and the work you would expect them to do when hired. The difficulty of the kata should be based on the role you want to be hired for. If you’re looking for a junior, your signal shouldn’t be asking the candidate world, because once again, you’re looking for a junior.

Finally, respect your candidate’s time. Remember they are not being paid to do this. If they are interviewing at multiple companies this could be just one of the many cuts on their plate.

One of the other things I found that some companies do is ask for a readme explaining the candidate’s thought process as they were solving the KATA. I think the readme is a nice touch because you can get a feel for what they did and why. Maybe a candidate has a great job that you look at and go, “oh my, why did they do that”? A readme at least gives the candidate a fighting chance to say why they have done so. You might even be surprised by his reasoning that you might not have even thought of.

It’s a good idea to have multiple skewers to turn, especially if you’re hiring a lot. This shouldn’t come as a shock, but it doesn’t have to be hard for your private kata to be publicly available. Only one candidate is required to create a public repo.

It’s not usually the end of the world, but you want people to come up with their own solution instead of seeing how others solved it. If your company hires backend and frontend engineers instead of full-stack engineers, it probably makes sense that you have two kattas: one that is more applicable to frontend work and one that is more applicable to backend work. it happens.

You can also make kata submissions anonymous if you want to take it a level up and remove the possibility of bias altogether. I’ll tell you how one of the companies I worked for did it. A new resume was submitted, and the candidate’s first and last name were removed. When the kata was submitted, a pull request was created with a random UUID as the title. You were then free to evaluate it however you see fit best. I don’t think it’s a right way, but it was one of the interesting ways I’ve seen so far in my career. It seemed to work great and was easy and straightforward to implement.

To be completely transparent, I could care less if you knew every algorithm under the sun. I’m looking to see if your code is solid, if you’re a good fit for a good culture at the company, if I enjoy working with you, and if I think the team will enjoy working with you as well. .

So, if you haven’t done so yet, I highly recommend giving Code Cuts a go for evaluation and recruitment of future software engineering candidates at your company! Thank you for taking a part of your day to read my article.

Want to Connect?Follow me on Twitter.