Your Junior Code Submission Checklist

Before I move onto telling you what the checklist is, I'd like to start off with an anectode. If you're not interested in it just scroll until you see "STORYTIME OVER" but I hope that you won't do that. There is value in learning the thought processes of people that carry out your interviews.

STORYTIME:
Not too long ago we were hiring a developer. His resume wasn't filled with programming experience or an amazing university, hell he didn't even finish a computer science course. He had minimal amount of personal projects to prove his worth and with that as a start I went ahead and started looking at his code submission. (I have a soft spot for self taught programmers so I really hoped it would be good)

I ran the code and it worked. The code met the specification that we asked the candidate to fulfill and he even covered his submission with a fair amount of tests. It wasn't 100% coverege but the tests were there and these tests were meaningful enough.

I went ahead and tried to break the code here and there. I used invalid inputs, I used inputs that were out of range, I poked at the code for a while before realising that the candidate has actually covered up the holes pretty well as well. In the past I wasn't as diligent when writing my first interview code submissions so was really proud of the candidate to see him do it.

I then looked at the code and checked whether it checked off the programming principles and this is where I encountered the first real issues. Because of the lack of formal education the candidate missed out on a number of programming fundamentals. Some code wasn't fully SOLID, there were some "clever" workarounds employed that made the candidates code work but werent very clean codey BUT this was a code submission for a junior role. What was I expecting?

At that point I was lost. I didn't know whether we should hire the candidate because his fundamentals were off so I went to my supervisor and said that this guy shows great promise but he is missing the fundamentals. This is the summary of the conversation:

"What should we do about him?"
"Does his code run? Are the tests fine?"
"Yeaah..."
"Invite him for a chat"

After a few days we spoke to that candidate and realised that his job experience despite not being programming would help him on the managerial and relations level and his learning drive was actually something that we liked about him and he was hired. His fundamentals were off, his tests had some holes but he had character and dilligence and that was enough to land him that job. I'm sure that in the future he will make us all really happy with his work.

STORYTIME OVER

From the story above we can see that juniors are not expected to write perfect code. In fact, with that story we can extrapolate what your interviewer will do to check if your solution worked fine:
1. They will start by running your code. If your code doesn't run after you submitted it you will lose a lot of points
2. They will try to break your code. Code that's easy to break shows that you will need to be taught to write error resistant code.
3. They will run and read your tests (If you have them and you should). Meaningful tests that pass will reflect greatly on your submission and will give you those delicious browny points
4. Finally they will look at how you solved your issue, your coding style and what could have been made better. If they were easy wins, it will reflect on you negatively. If it's something harder this can be a good avenue to pursue in the later interview meeting.

Did you notice how reading the code and judging its quality is one of the last things checked by the recruiter? For me this only became obvious after I started recruiting myself. I would rather teach someone attention to detail in code than to teach them attention to detail when solving a problem. The second quality is much more difficult to etch into a person. I also think that if we flipped this list we would see a development process of a regular program. Writing code, writing tests, protecting the program from faults, deploying it to be used.

Having that understanding I think that if you follow these principles you will be far more likely to land that job you want:

1. Ensure your program works and is hard to break
2. Make sure you have unit tests for it
3. Make sure your code is easy to follow
4. Attach a readme to your submission to get extra points :)

I know, I know. I didn't speak about READMEs before but honestly for a junior I'm not really fussed if I don't see one if the program is easy to enable. The rest of the list is far FAR more important. Please please PLEASE make sure your code is running before submitting. Make sure it is tested because if you have tests then you can refactor your code to make it clean without worrying that you will break anything.

Anyway, I think I conveyed my message so all I'd like to do is to leave you to your interviews and I really hope that you will land that dream job and that this post has helped you do it. Nothing will make me happier.

Best luck to you all,
Maciek