What's the best way to show some of my code during an interview? [duplicate]

Question

This question already has answers here:

How to show code samples in an interview? [closed] (3 answers)

Closed 6 years ago.

I realize that there are already a couple of questions about this, but they mostly are about if you should bring code to the interview, which is not the case here.

I have a job interview (at a startup) coming up next week and they requested to bring some code to the interview. I have two smaller open-source projects and a closed-source Android app, which I mentioned (and linked) in my skill sheet I sent along, so I wanted to show them some code of those projects. It's my first job after graduating, so I don't have any sources from previous employments and there won't be any issues regarding "spying", licensing issues, confidential code etc. All the code is completely mine and written by me.

I guess I have pretty much three options: print some interesting parts of the code on paper or have everything on my tablet or laptop to show. The latter two have the advantage that I can bring all my projects and basically show them everything they want to see. However you can't directly make notes/underline stuff etc. as if I had printed it out and it's less convenient than just handing out paper.

What's the best way to handle this professionally and do this as hassle-free as possible? I currently tend to print out some of the parts that I think are both interesting and well written, but have everything on my tablet in case they want to see more.

Answer 1

Why don't you do both? Bring paper print-outs and bring an electronic device to showcase the rest?

If they have let you know how many people you are interviewing with, bring print-outs for each interviewer plus two or three spares. Extra interviewers get added on all the time and you want to be prepared for that.

If you can, bring a device with a screen that's easily seen from a distance. You don't necessarily want to huddle around the 4" screen of your phone in order to show your code.

I would consider cherry picking separate sections of code to show. For the print-out, a smaller, mostly self-contained routine would be ideal. For the device, I would try to identify some thorny problems that you had to solve and have those loaded up and ready for show.

---

It's worth noting that you do not need to bring copies of your closed source application unless you want to do so. Any potential employer should respect your copyright and understand that you may not be comfortable with handing out copies of that source.

Answer 2

There are several goals to that:

1. To see that the person can code.

   Don't be surprised: many programmers who come to an interview don't know how to write code. While it's indeed difficult to write code under pressure during an interview, some are also unable to write it outside an interview. If those copy-paste programmers are useless in a company, asking them to provide their own code is a good way to filter those candidates.

2. To see that the person has his own projects or participates to existent open source projects.

   Many programmers I was interviewing had only source code they've written at work. This is a good sign that for them, programming is just a way to gain money, not a passion.

3. To see high quality code (or what the person thinks to be high quality code).

   A non-negligible part of the candidates I interviewed was bringing code full of bugs, and by bugs, I mean clearly visible bugs such as infinite loops, dead code, etc. Nearly every candidate bringing C# code had his own style, or rather no style at all (remark: C# has well-established conventions created by Microsoft and enforced by StyleCop, a tool which integrates well within the IDE used to write C# on Windows).

   A glance on the source code can tell you much more about the candidate than fifteen minutes of interview.

4. To check that the person is not bringing proprietary code.

   I had done several interviews where the candidates were bringing proprietary code. They weren't even hiding the name of the company. One, to the question “Don't you think it's disturbing to show to a third party a piece of code for a project probably covered by NDA?”, answered: “I really don't bother, in all cases this company was lame!”.

5. To see that the person is able to handle or participate to a large-scale project.

Personally, I ask the interviewees to send me a piece of code before the interview. During the interview, I ask them questions, such as:

At line 27, you are using a stream without disposing it. Why? What are the two ways, in C#, to dispose it?

or:

You have code duplication between the line 14-18 and the line 55-59. Why? How can you easily avoid it?

or:

At line 62, you do a cast. Why?

Some of those questions are related to bugs: when I ask them, I want to know how the candidate would handle this situation (and if he would see the bug himself first). Some people are extremely bad at handling that. For example, answers such as: “It has bugs because this part wasn't written by me.” (well, I asked to bring your code, not your colleagues' one) are frequent.

Other questions are related to dark parts of the code. I was often surprised by candidates who were perfectly able to explain why they did it this way, and why a different approach would have been worse.

• If you think that you may be subject to such questions, be sure to bring a short piece of code you know perfectly well: answering questions about the parts you don't know well is not easy. Try to bring a piece of code which may not be particularly challenging, but which is flawlessly written, clean and easy to explain.

• If you don't think the interviewer will ask questions (but rather listen to you showing your code), bring larger pieces of code to be able to show architecture, as well as highlight technically challenging aspects.

Remember: if your projects are open source, putting the link to them in your CV can only be beneficial (unless there are reasons to be ashamed of your code).

Answer 3

• I believe Github is the best showcase for code these days, so be sure to create a repo for every interesting project. Bitbucket is an alternative if you want free private repos.
• A tablet is really handy in this case, you could create a slideshow with screenshots and a few lines of text to showcase some projects (like closed source ones).
• Show them the running applications and highlight the most interesting features. Nothing compares to experiencing a working product.