Production-quality Code Tests

This post is all about the code test and development interviews. For software development jobs, our craft is programming and to be a great developer you have to be a great programmer. Is it that straightforward? It really is.

The Code test is your first impression

Don't count on previous experience being known to your potential new teammate. We all have histories, and when you have put down lots of good work it may seem obvious that you know what you are doing. That may be obvious to you, but your assumptions about how good you actually are just that; an assumption. Put yourself out there and get real feedback. This is how you know how obvious this reality is to others.

My big mistake in my last code test was approaching it in the manner I send code tests to new employees. These have been new grads and co-ops, so the audience (me) is looking for how someone approaches and solves a problem; and all the gory details along the way.
For a company that is established, and growing fast, the priority isn't in new products or prototypes. They have a product and need people to grow it with quality code that doesn't need to be re-visited and re-factored. Reflect this reality in your deliverable.

Show an understanding of Done

What I needed to do was find out from my audience what they were looking for in the result; and produce the result to that end. This was for a senior position, so the need is to have someone starting that can add value to the team immediately. This would mean the code would have to be production quality, and why not? If you are hiring someone, you don't want to have to figure out if they can deliver quality; you are aiming to hire people that know how to do just that.

Create trust with a solid deliverable

Be thorough and produce a production ready commit. Assume the highest standard. While it is important to show how you arrived at the solution; for the interviewer it's easier to work back from a finished product rather than stepping through the commits to get there.
Sloppy work will show that you may not take this seriously, so how is that going to work in the day-to-day when your teammates depend on your work to be Done?

What is Done?

Done means different things to different groups. In some environments it may seem ok to have a lower bar of quality when done. Academic environments can be very proof-of-concept work, so it can become normal to deal with code from many different authors and styles. Some groups are in a rush to get to a prototype. Be diligent and don't  let that become your normal in your day-to-day work. Done is when you don't have to go back and fix it; its Done. That is the nature of professional work.

Find the time to do it

You probably have a full-time intense job, and maybe a side gig, and a life with responsibilities. How do you make the time to carve out a new path? Interviewing for a developer role isn't the traditional meeting with people and doing some company research in-between. The company research must be done along with: Domain research to understand the industry the company is in, and a code test. The code test (if it's good) will take some time. Make sure you have time before you interview and take on a code test. Go above and beyond to create the trust in the new relationship.

Changing environments can be challenging

When switching to an entirely new language and platform; it can be challenging to catch up. In catching up and figuring out your new reality, there is a big different to being fairly proficient in the new platform, and being production-quality ready. Once you get some momentum in the new environment, find some code tests to try out and see how production ready you are.

Find the fit

Work is a relationship, and sometimes what seems to be a 'good fit' on paper may not reflect the reality. What stage is the company in? is it searching, scaling or mature? There are different personalities needed at the various stages. In the early days there is a need for visionaries, but in the mature company that person may become a disruption. A drone worker in a startup still searching for market-product fit will slow the group down. Decide what you want to do, and understand who you are, before approaching the company.

Goals for the code test

The main goal for the code test is to establish one very important relationship trait: Trust.
The candidate needs to trust the group they are applying to join, but only when the candidate gives a reason for them to be trusted will this happen.
Show quality in your deliverable and show your craft in the highest possible light to put both of you on the best path for a long professional relationship.