I have recently applied for programming jobs, and created a small portfolio with specific examples that display my programming knowledge, and show how my work experience has helped my development.

These are questions I've received during question-and-answer sessions with potential employers:

"Can you program?"
"How well can you program?"
"Are you familiar with?"

I respond to the question and follow up with something similar to:

In addition I have also prepared a portfolio with clear examples, some live tests as well as code samples that you can use yourself to get a better picture of my ability. If you have any tests I would be more than willing to take them as well."

This is usually met with more questioning and general apathy in seeing the examples I have made and/or lacking of actual testing of my ability.

  1. What are some techniques for presenting a portfolio?
  2. How does one convince a potential employer to make time for the presentation of one's portfolio during an interview?
  3. if an organization isn't interested in validating the candidate's personal work experience -- as through tests or portfolios -- is it in the best interest of the candidate to stop pursing employment at the company?
  • 1
    Hi Dodzi, welcome to The Workplace! You're facing an interesting issue encompassing several points that you listed. May I suggest you split your three questions at the bottom of your post into three different posts? That will make it easier for people that only know about one of the aspects to provide answers. Also, your third question might be out of scope for this site because we generally can't tell you whether or not to persue employment somewhere. That a more personal question. Hope by splitting it up you will get a lot of good and useful answers!
    – CMW
    Commented Mar 12, 2014 at 9:30
  • Thanks for the edits on my post @enderland . As for why the insistence on the portfolio, for example, the place that I interviewed didn't test me. My resume has some programming experience, but due to financial matters I couldn't do them continuously. I need to prove to them that I have ability and willing said I'll take any tests needed. In addition to my education and work experience I should be good. However, due to the gaps in relevant experience I could be overlooked. In the absence of a test I feel that a portfolio is a good jumping off points for discussion. Commented Mar 13, 2014 at 3:35
  • What's your portfolio like? Is it just code? Do you bring it with you printed out in a piece of paper? Because if so, then that is awful. An interesting portfolio for programming would be something like a list of working smartphone apps you've made that the employer can check out on his own time, or a website displaying some interesting website designs or techniques. Not a lot of people are interested in the code itself, but rather what you can do with it.
    – bpromas
    Commented May 28, 2015 at 19:27
  • My portfolio is basically working code and tests for said code. Agreed that something visible is better, but that also depends on the nature of the person doing the interviewing. At the time of this question I had an @BrunoRomaszkiewicz interviewer with the lead programmer of the company that I was interviewing for. He refused to see my code despite asking a lot of questions that could be answered by seeing the code in question. Previous non programming interviewers at said company allowed my to explain the premise of the code then show them working examples. Commented May 29, 2015 at 10:57

4 Answers 4


In brief and in blunt, I would say:

  1. typically, don't present it
  2. don't try to convince a potential employer if they've not asked for a portfolio
  3. definitely don't ignore an employer simply because they won't view your portfolio.

If I were interviewing you as a programmer, I wouldn't want to see your portfolio either.

(Offtopic but related note: I would prefer an employer that asks you to write code as part of the interview process.)

In much more detail...

Firstly, what does your portfolio prove? Very little, to an interviewer. A portfolio of code is not like a portfolio of artwork: it will not have much subjective beauty; it will not be significantly different to the portfolio that a hundred other similarly-skilled developers would produce. Unless your code is presented as a series of 10-line working snippets, the interviewer isn't going to be able to comprehend your portfolio meaningfully during the interview anyway - code takes time to understand, and all but the most trivial example will take too long to convey. Finally, there is no indication in a portfolio of how or where you wrote this content, and so any skill you may or may not have isn't conveyed: was it a 10-minute exercise for you, or 6 week's tortured work? Or did you actually just scrape it from the results of a Google search? An interviewer cannot know, and so the portfolio is useless.

Secondly, when I want to see your code, I want to have defined the problem you're solving. When I interview, I do ask people to solve a simple coding problem in a reasonably short timescale (typically under an hour). By doing that, I as an interviewer already have a good understanding of what output I expect - which makes my job of analysing the result less complex. It means I have a set of pre-prepared discussion points to follow up with that will allow me to more deeply question the candidate's skills ("what if we need to make this method thread-safe?" or "what if I ask you to scale up to a million users?"). This also makes comparing candidates easier because there is a common challenge that everyone has completed under known conditions.

Thirdly, consider what the interviewer is looking for. Most often, in a forward-looking company, they are not looking for evidence that you can write a perfect MVC structure, use a certain library, or reduce a complex algorithm to three obtuse lines of syntax. An interviewer wants to understand whether you are smart. When I interview people, I want to know that they can have a meaningful and intelligent conversation about design/architectural choices, that they have a good understanding of the fundamentals of computer programming, and that they have an active interest in furthering their understanding. I don't care what their code looks like because, nine times out of ten, they will (to a greater or lesser extent) be required to change what their code looks like to suit the requirements of the team and the codebase they're being hired into. Further, if a developer can have those intelligent conversations, I know that they are capable of learning the patterns or libraries or languages that are relevant to the project they're joining. Most times, they won't know it all already.

Fourthly, consider what I know. Am I even technical? Many times, at least one of your interviewers will not be. If I am, I may not know the libraries you've used, or even the language you've used, or the platform your code runs on. I may not understand the problem you're trying to solve. The problem you're trying to solve might be interesting, but it might not be relevant to the codebase you're applying to work on. You can't see that - but the interviewer can, and they will structure the interview to suit.

As an interviewer, my time with you is limited, and I want to have a conversation that draws out your intelligence, understanding, ability to learn, and experience. It's my responsibility as an interviewer to get that information from you and I might - if it's useful or warranted - choose to ask for a sample of your work to help with that process. Most times, though, I'd choose for a candidate to demonstrate that through verbal and some hands-on problem solving, not through a pre-written project of their own choosing.

As a candidate, you need to trust that the interviewer knows their own requirements, and how best to get those from you. Pushing a portfolio under their nose and insisting that they understand your pet project really only demonstrates that you don't respect their requirements, and won't do you any favours in the interview.

  • -1, A code portfolio can show skill (or lack of it), etc., as long as it isn't fraudulent. Of course, the best predictors are longer assessments that the candidate hasn't taken before.
    – daaxix
    Commented Mar 12, 2014 at 15:54
  • Understood. Great answer with lots of detail. I'm going to put up some links as to why I asked this question. [How to hire a programmer] (goo.gl/OpcJzk) , [A Programmer's Portfolio] (goo.gl/8eKCSG) and [The Guerrilla Guide to Interviewing] (goo.gl/XYyGML) . There are probably lots of job hunters that use these as well as other references as a base for preparing for interviews. If there is no test how are they going to accurately access a candidate's ability? (Asking the candidate to write code or do a problem is a great way as well) Commented Mar 13, 2014 at 3:44
  • @daaxix: If I'm interviewing someone, I don't want to spend that time code-reviewing a portfolio that I know nothing about. If I don't have requirements to review against, or coding standards to review against, I can't get much useful information from the code that I couldn't get quicker elsewhere. (For example: if the provided portfolio includes unit tests, how do I quickly and meaningfully ascertain the value of those tests in context? I'd be better off asking the candidate to discuss their approach.)
    – Dan Puzey
    Commented Mar 13, 2014 at 12:17
  • @DodziDzakuma: the difference between "asking a candidate to write code" and "reviewing a candidate's prewritten code" is huge. The former is one of the most important things I do when I interview; the latter is more time consuming and harder to learn from. (All my opinion, of course.) Also, there's mention in another answer of "providing your GitHub profile on your resume." That is a different proposition entirely, and potentially more useful (as the interviewer has time to review beforehand and prepare thoughts/questions).
    – Dan Puzey
    Commented Mar 13, 2014 at 12:19

First off it is a good idea to show a portfolio at a programming interview as it sets you apart from the crowd. The only time this may not be useful is if you prior work was very generic stuff and doesn't really have a lot of impact. When showing a portfolio always make sure it does not contain confidential or private works, especially if showing code snippets.

While i agree that a candidates code snippets or elements of a portfolio could have been copy and pasted from a Google search most employers can validate this simply by doing a reference check with the candidates previous employer or asking probing questions about the example and how it works. The feedback i have received from interviews where I have show a portfolio has generally always been very positive.

Never push your portfolio onto the employer, if they aren't interested in seeing it then accept that and continue on with the interview as normal. Having a portfolio with you that isn't ever shown is better than not having one and then needing it (A picture explains a thousand words). I generally used to mention "Would you like to see my programming portfolio?" towards the end just before the interview wraps up. Most of the time the employer will say "Go on, let's take a quick look", as they go through your examples tell them how they work and why your created them in that fashion (This shows understanding).

The definition of a programming portfolio in my eyes is the following: 1) Screen shots of your application 2) Description of your application and technologies used 3) A working example of your application (If its a website or mobile app) 4) Code snippets (Not to be shown if confidential or private) 5) Blogs or technical documents that support these projects

Best of luck and i hope this advice helps.


In my experience on both sides of the interview table I have never offered, nor been offered a portfolio.

That said I think having your github.com profile listed somewhere on your resume would be valuable if you have contributed to open source or have open source work there. This allows a potential employer to browse your work at their leisure.

You should also clearly list on your resume any public websites you have worked on and in what capacity. This could be highlighted somewhere, or inline with your work experience.


If you are absolutely insistent on including code examples to show to your employer, maybe you should consider including them with your Resume, along with an explanation for what each code sample is for/what problem each sample solves.

The latter is necessary, because most code samples are not intuitive, even to a well-versed user, as to what they are for or what they accomplish. Put them in perspective for your employer.

If you find most employers aren't asking for a portfolio or code sample, you might want to consider not bringing one unless asked for it explicitly - different interviewers want differnt things, and they may be more interested in you personally than the work you've done in the past. They may also prefer seeing your on-the-fly skill rather than old examples that may be dated and completely irrelevant to their needs.

In general though, it is a bad idea to try to re-direct the interview. This process is for them to find out about you, and if you constantly try to shift their focus where they don't want it, it's not going to leave a good impression at all.

  • @JoeStrazzere I meant WITH the resume. My apologies. I don't think he should be writing out entire code blocks in the middle of his resume.
    – Zibbobz
    Commented Mar 12, 2014 at 15:00

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .