You showcase your code by:

• Having a high quality code which is well-written and commented, with no or few bugs,

• which is your own, from a personal project, not a source code of your coworkers, nor the code you’ve taken from the internet,

• which is not too small, but still not to large, in order to be challenging enough and to avoid too much boilerplate code,

• that you published in a public version control or on a public website,

• and that you mention in your CV and give it before the interview, so that the interviewer has enough time to explore it.

Here are some hints in detail.

Give your code before the interview

You shouldn’t wait until the interview to give your code. Ideally, you should have an already available open source projects that anyone interested in your skills can download from a public version control. If you don’t have a public version control, then you should at least have some source code ready to be published on your website.

Have a link to this code in your CV. Don’t wait until people ask you (but note that most people don’t have time reading your CV¹, so they still would ask for it).

If you’re a developer, your coding and your communication skills should be the most required skills to look for, so a CV which mentions that you’re playing violin and enjoy golfing but forget to mention any source code or any article you wrote has no value.

Giving your code before the interview allows the interviewer to explore it, and prepare the questions. If the interviewer discovers your code only during the interview, there is no enough time to read it in details, and you’ll only receive some superficial remarks and questions.

Give your code which is long enough, but not too long

A long-enough code is a must. Giving a method with only 10 LOC doesn’t allow the interviewer to have a clear view of your coding skills (well, sometimes, even 10 lines is enough to understand that the programmer sucks).

But the code shouldn’t be too long neither, for two reasons:

1. An interviewer doesn’t have time browsing boilerplate code, and it’s difficult to find challenging code in a large codebase when you’re not accustomed to it.

2. During the interview, you’ll have to answer questions about your code. If it’s a small piece, you will more hardly be lost. More code = more chances to have a bug in it.

Give your code

Cheating is very harmful. Every candidate is able to find a piece of code on the internet, but when the interviewer will start to post questions about this code during the interview, the candidate will have a hard time answering those questions.

Once, I had a rather strange interview. It was similar to this:

Me: do you have anything to tell about the line 1402 to 1406?

Candidate: no.

Me: well, first, you create the variable ac, but never use it later. Secondly, there is a bug: you actually expect to add every element from the collection to the list, but you’re looping backwards, so the list will always be empty. Any remark?

Candidate: ah, I haven’t noticed it. But you know, this part of the code was not written by me, but by my colleague.

I don’t care. If you’re posting this piece of code during the interview, I assume you wrote it, and you’re accountable for every character in it.

^{¹ In general, do never assume that the interviewer had opened your CV. When I was interviewed myself, it was really surprising to receive questions which made no sense from somebody expected to make an effort to open my CV at least once before the interview.}

However you do it, just remember confidentiality… you may have written the code (all of it, or some of it) but unless it is entirely a hobby project, it may contain commercially sensitive material.

This is of course especially true if the interview is with a competitor.

Personally, if I was interviewing a candidate, and they started waving their existing work at me, I’d be cautious, because the work I do (and they would be doing with me) is VERY commercially sensitive, and I’d be worried that they’d do the same thing with our code!!!

Strange as it may seem most interviewers are not interested in seeing your code! The guy interviewing you is probably a project leader or from a similar career stream and may not even understand any code you show him.

Even if the interviewer is a techie and understands the code, he/she does not know how long you took to write it, does not know if you really covered the spec/use case, does not know how you tested and debugged the code, in reality the interviewer cannot even be sure its “your” code.

If the interviewer is really interested in how you code then he/she will set you a coding, code comprehension or debugging task and see how you cope. Otherwise you can safely assume they do not want to know.