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:

• A random university assignment2. If the most remarkable piece of code that you can conjure is a standardized answer to a standardized test that you were required to produce as part of your curriculum, it demonstrates that you never cared much about your trade. You did what you were told, and that’s it. It’s fine though, but don’t expect me to think that you are remarkable because you have a degree.

• A script, typically Python, that merely consumes some kind of (supposedly) interesting third-party piece of tech that you didn’t write and most likely wouldn’t be able to engineer on your own. For every such piece of tech, there are a bazillion tutorials out there, and a linear piece of code that imperatively invokes the right sequence of methods to achieve “magic” is unimpressive - unless you were involved with the “magical” parts.

• A dumb piece of CRUD app (create, read, update, delete) based on some MVC framework. Indeed, I can hardly think of anything less challenging as far as software engineering is concerned. Being able to mimic a programming pattern to produce ad nauseam code variants following a template hardly qualifies as inspiring. If you think that software isn’t more than filling in the blanks in a template, then, let’s agree to disagree.

• A messy code piece. If you can’t get the presentation of your code right, why would I trust you to get anything right as far as engineering is concerned? Without carefully crafted variable names, a codebase rapidly devolves into a non-euclidian horror that takes a toll on your sanity. The mental health of my team is important. I am not hiring someone who would jeopardize this by driving my colleagues nuts.

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

• Parody is fine. It does not have to be serious business. Being creative and having a sense of humor aren’t defects. If you have enough mastery to make fun of your trade, that’s a telltale sign of competence.
• A tiny piece of code is fine. It does not have to be long. Here, I am omitting - on purpose - the short inline comment that I would actually expect from a candidate to explain why this code is remarkable. Be prepared to be challenged though.
• Old fashioned tech dealing with an ancient problem is fine. It does not have to leverage the latest cool tech of the corner.
• Pseudocode in a public answer is fine. Combining tech mastery with high quality communication certainly ranks highly among the qualities that I see as desirable.
• A semi-ugly piece of code that happens to be an enabler to produce less ugly code is fine. The value delivered by certain abstractions precisely lies in their horrid internals that get abstracted away.

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. ↩︎