|
There have been questions similar to this, but my question is HOW exactly do you showcase your code when going to an interview? Do you show screenshots, or do you bring the actual code? Do you take the whole project with you, or just that bit of code? Thanks! |
|||||||||||||||
|
Questions on The Workplace Stack Exchange are expected to relate to the workplace within the scope defined in the FAQ. Consider editing the question or leaving comments for improvement if you believe the question can be reworded to fit within the scope. Read more about closed questions here.
|
In my whole life I've never brought code samples to an interview, and have never seen anyone do so either. And here is why: 1) Most of the code you write for work is not your property, and showing to other people is a stone's throw from industrial espionage :), that is unless you're working on an open-source product. 2) If what you're writing is open source, you will typically have github to your name where you can show everything you've participated in. So it's usually a github account or nothing. Bringing code to the interviews is not necessary because the employer can then take a look at your code on their own time. Alternatively, you can just tell them your ID at the interview, and browse through your projects together. *Keep in mind that a huge number of developers spend their entire lives having not written one line of open-source code. |
||||
|
Code samples at an interview are a dangerous prospect because, as suslik said, you probably don't own the code. If you wrote it for an employer, regardless of how general-purpose that code is, it's your employer's IP, which you were paid your salary to produce for them. It also doesn't have to be yours. Numerous blogs, QA sites (like the SE family) and other sources for "t3h fr33 c0dez" abound. Coding languages, in general, have fewer ways to say what you need to say, and combined with "best practices" and refactoring assistants, two knowledgeable coders' implementations of a QuickSort algorithm could differ only cosmetically (and cosmetic changes are the easiest to make to somehting you sneak off the interwebz). In addition, I dunno about the rest of the development world, but code I write "on my own time" is typically not code I'd like to show off. That code is stuff I create for my own enjoyment, usually without a huge amount of attention paid to architecture or documentation, because it's code that's only "right" (not only correct but well-organized and well-formatted) to the extent I need it to be so. Lastly, hiring managers don't tend to be coders. They may have worked their way up through the dev team hierarchy, but their job now, as a manager, is to tell you what they want coded, and send you off to go do it. They're not really interested in your exact solution; their concerns are related to the finished product. Does it work? Does it look good (for client-facing apps)? Does it perform well? Those are things that are difficult for you to demonstrate you can do with a code sample. They're much easier to demonstrate with a beefy resume of your past work, plus references from those past jobs that tell your prospective employer how impressed they were with your work. As a result, I say don't bring code, unless it's your solutions to interview prep problems they give you. Instead, bring knowledge of the company, the industry they're in, the language/framework they're looking for (and others that may get the job done better), object-oriented design patterns and principles, data modeling, etc. Show them you know your stuff, and that you know their stuff, and you'll make yourself a hot commodity. |
|||
|
|
