Remarkable software engineers write remarkable code

When hiring for my software company Lokad, my goal is to identify remarkable software engineers: those who will deliver outsized positive outcomes. The latest addition to my process is asking candidates to exhibit a personal and remarkable piece of software of their own choosing.

Anything goes. I don’t mind if it’s COBOL or Rust, or even if it does not compile because it’s just a fragment of a personal project that you’re not willing to disclose1 in full. The goal is to assess your skills and create an opportunity to have a meaningful discussion about software engineering.

Indeed, the “usual” approach which consists in challenging people on trivia - i.e. write a bubble sort on the whiteboard - is just inviting candidates to reverse engineer the hiring process. This isn’t the 90s anymore, there are now websites where applicants publish their interview questions and challenges. Furthermore, I fail to see the point of testing applicants on what they can look up in 2min through a search engine anyway. By letting the applicants pick a piece of code of their own choosing, I let them choose their weapons and battlefield.

My goal is to see candidates at their best, not at their worst.

To say that most applicants choose badly their piece of code would be an understatement. Let’s provide some guidelines for this exercise.

The first mistake is to send source code as file attachments via email. Do you usually send code via email for review in your company? If you do, your tolerance to bad processes is impressive but I am not too sure that you have the right mindset for us. I prefer people who improvise suitable processes when facing unusual circumstances. The courtesy of putting the code somewhere online is highly appreciated, especially if code coloring is involved.

As you are sending a piece of work to a prospective employer, it has to be something that illustrates your skills or your mindset in a positive way. Yet, there are many things that do the exact opposite:

Conversely, let’s refine a bit what a remarkable piece of code could be.

The use of rare and cryptic programming language is positively looked upon (don’t expect to use that at Lokad though). A vivid interest for some downright obscure implementation details goes a long way to demonstrate that you are paying attention.

Again, anything goes. There is no right or wrong, merely remarkable and unremarkable. Low quality code is unremarkable as there is so much of it floating around. If you can tell the difference, then, you’ve already gone a long way to become a remarkable software engineer.

  1. I refuse to sign NDAs as part of a hiring process, it’s just too much hassle. We don’t ask for NDAs from our applicants either. ↩︎

  2. A variant on the university assignment is a work assignment that you produced as part of the hiring process for another company. Most companies are fairly unimaginative as far as their work assignments are concerned, thus, from my perspective, it feels and tastes the same as an university assignment. ↩︎