Why is non-professional technical experience sometimes snubbed by interviewers?

Question

I once interviewed for a software developer role in a big IT company. The interview was done in front of two interviewers: a "regular" one, and a "trainee" who was shadowing and taking notes.

When asked about a technical challenge that I faced in the past, on the lines of: "tell me about a bug that was particularly hard to investigate". I gave him an example and digged into the details. The interviewer was very satisfied with the example, but then asked: "where were you working at when this happened?" and my answer was simply: "I was in school at that time, this happened while I was working on this open source project that I was maintaining".

At that point, the interviewer turned to the trainee and said something like "note down that this was amateur experience". I can't remember the exact words, but he explained that everything that I did while I wasn't employed was not relevant for the interview.

What could be a reason for that? Computer programs work the same, whether you are paid to make them or not. I could understand such feedback if the question involved costumer relationships or service level agreements, but this was a question merely about problem solving and debugging. This is not the first time it happens. Any hints?

Answer 1

Technical work you do in a non-professional context is different from work you do while employed. Not necessarily in terms of the technical nature or difficulty of the work you do (I've known people who do much more difficult work outside of the day job because they find their paid work insufficiently challenging!) but more in the mindset and environment.

If you decide you don't want to continue working on something such as an open source project, either through a lack of time or motivation you can simply walk away and nothing happens. Similarly you can royally screw the pooch and nothing happens.

This is very different from a professional environment where there is expected to be a degree of responsibility and accountability for what you do (or don't do as the case may be).

Personally I don't agree with the attitude your interviewer took - I consider non-professional experience to be valuable (technically speaking), not quite as valuable as professional work true but not so much that it's irrelevant.

I wouldn't go so far as to call them "idiots" as others have done because I can at least see how they got there, amateur experience has very little formal quality control associated with it and it's difficult to judge it's worth - take your example of a tricky bug investigation. Doing the same in a commercial environment when you have business needs/customers etc pushing for a resolution yesterday is different then when you can take a day, a week, or months to resolve it. If at all! I'd still be interested in hearing your story of that though as it would tell me a great deal about your thought processes. So you interviewers weren't idiots - but they perhaps missed an opportunity to garner valuable info on you the candidate.

Answer 2

I can't remember the exact words, but he explained that everything that I did while I wasn't employed was not relevant for the interview.

What could be a reason for that?

You met a human. As with every other human, there is a good chance that their flow of logic is not yours. This is an example. Why do they have those thoughts? I have no idea. And yes, this is the more neutral version of saying that dude is an idiot.

There is no difference between work you did and other work you did when one of those two later got you a paycheck. It's the same work, the same experience.

However, there is a huge difference between working as part of a team in a real world scenario (commonly called a "job") and a personal pet project at home.

For obvious reasons, one's own personal pet project has no conflicts over coding style (or maybe doesn't even have one), has no testing outside the very person who programmed it (and we all know as developers we don't see our own mistakes), has no owners that change their mind midway into the project, and even if it uses source control, that's just a token statement because source control with a single developer is not what is complex about source control.

So I would absolutely agree with anybody saying a personal pet project counts for a lot less than real world job experience simply because there is no way to experience these issues as a single developer/manager/tester with no oversight and no coordination problems at home.

As a junior, the main problem might be to make the computer do what you want. And that is what you can learn from a pet project. But the more experienced you become, the problem is no longer the computer, the problem are the communications in teams, whether is technical merge conflicts, client communications, project planning or acceptance testing. And you cannot learn that in pet projects because it does not happen or it's all in your head anyway.

Now before you jump on me, let me repeat: personal pet projects. If you are part of a large team maintaining a big open source application, with a user base that logs issues and wants new features, that's not a little personal pet project. That's real world experience and it does not matter if any of them get a paycheck.

Finding a bug is finding a bug, whether you got paid for it has nothing to do with it.

So... you met an idiot. Sorry. That's a chronic condition. It will happen again countless times over the course of your life.

Answer 3

Yes, people can think that if you aren't paid for programming, you aren't:
1. Doing your best work
2. Learning from others
3. Working hard enough to get a "real job"
4. Good enough to get a "real job"

There may be some truth to it, since getting paid means you likely have deadlines, co-workers to help you get unstuck, are working 8 hours a day at it, and you've passed someone else's idea of "good enough" in order to get hired somewhere. Unfortunately, this all can apply even if you're working as a programmer and doing this on your own time.

Sometimes doing after-hours programming will be held against you, as "obviously you aren't working hard enough during the day so that you still have energy to work more at night."

However, there are some (few) good reasons for these perceptions.

There's a lot of posers, or just plain noobs, that think they are the worlds greatest programmers, even though they definitely aren't. They think that all the time they've put into learning something immediately qualifies them for a Senior role, even if they've never worked as a dev before. Ok, so most of us have been there, but there are people who go into an interview thinking this and try to convince the hiring manager. And they get a job, try to tell the actual Seniors how to do the job, and generally make life hell until they can be strapped to their seat and shown just how bad their code is.

Not every noob is like that, but there's enough to keep people wary.

Having examples of your work to go along with the time you mention would be a good way to go, as James Khoury mentioned in the comments above. Having a code repo that you worked on, your own code repo (GitHub, BitBucket, whatever), or even a website of your own that can show the source code you produce. As many people say about a lot of things, "Show, don't tell." This is why artists have portfolios and musicians make CDs.

You can tell someone you climbed Mt. Everest, but if you don't have selfies at the top, it doesn't count, basically. Prove your worth.

I've been programming professionally for 6 years, but started programming on my own over 25 years ago. I've done a wide variety of projects for myself and for various positions I've held over the years. Do I want people to see my code from more than a few years ago? Probably not. I've learned 2 metric tons since I started doing it professionally and even looking at my own old code, I cringe.

Also, if you haven't been a professional for a while, your personal programming isn't likely going to be up to many coding standards. This isn't necessarily a bad thing for a Junior position, but it can be for someone looking for a Senior position. Really, I should rewrite most of my projects to make them look better on my own portfolio. I've done some of that, but not much. I've also posted the old code to a code repo, then pushed the changes to show not only my new level of skill, but also how much I learned since doing the project originally.

And yes, Dan Neely is correct. The interviewer was an idiot to put too much stock into it being "amateur" work, instead of looking at it and then deciding the quality of the code. There's a lot of people like that. Realize that if you don't get those jobs, it's probably a good thing, for your sanity.

Answer 4

[The interviewer] explained that everything that I did while I wasn't employed was not relevant for the interview. What could be a reason for that?

We can't know for sure (you'd have to ask him), but there are a few possibilities.

• Perhaps the interviewer lacks an understanding of what software development is really about (or as others have put it, he's an idiot).
• Perhaps he recognizes that personal code has no (or few) external users, no paying customers, no deadlines, no (or few) other team members, and no commitments, and is therefore more prone to being "amateurish", even if that's not inherently unavoidable (which other answers have discussed very well).

Another possibility I have not yet seen discussed relates to the mentor/trainee situation that you mention between the two interviewers. It may be that the interviewer was trying to conduct the interview in the fairest and least-biased way he could manage.

Interviews are a difficult subject to get right - very few interviewers have actually had any interview training (mostly assuming they can "wing it") and in my experience most interviewers are very bad at interviewing, in one way or another. A particular difficulty of interviews is ensuring fair treatment and equal opportunity for the candidates, attempting to eliminate bias (subconscious or otherwise) on behalf of the interviewer.

One way to improve fair treatment during interviews is to ask all candidates the same questions in the same way, and form a judgement based only on their answers. This reduces the risk of favouring candidates with the same social background as the interviewer, compared to a more informal process where the interviewer asks whatever they happen to think of at the time (which will be influenced by the flow of the conversation and especially by how much the interviewer has in common with the candidate). The interaction you describe between the two interviewers in this case suggests the company you were interviewing at may be trying to take this approach.

Another way to improve fair treatment is to leave out from consideration anything from outside of work. This sounds silly to people who have always been told that their extracurricular activities will give them a good CV, but the simple fact is that it is much harder to find time for activities outside of work if you are poor, a parent (especially a single parent), a carer for a disabled relative, and so on. Such people may still be perfectly capable of doing the job, but are disadvantaged by their particular life circumstances (which may end up in a vicious circle; e.g. if you're too poor to afford to do things outside of work that sound great in an interview, you can't get a good job, so you stay poor). It may be that the reason the mentor interviewer told the trainee interviewer to disregard your amateur experience was to avoid giving you a potentially unfair advantage over other candidates.

Answer 5

Correcting a bug in a professional context can be really different than in open source projects: you can have way more stress due to deadlines or SLAs with financial penalties, you can be asked to do "quick & dirty but efficient" work you wouldn't do in an open source project context.

I wouldn't discard your non-professional experience, but yeah, that's different when you are part of a community without real responsibilities on you and when you have to debug with your client yelling at you because he paid 10k$ for this feature and it isn't working as expected.

Answer 6

Others have spoken to the variations on mindset and motivation between job, school and side projects. There's another facet that your specific example speaks to...

Laziness. Understandable laziness and brought on by constraints, but laziness nonetheless. It's much like resumes often getting weeded out for trivial or even counterproductive reasons because they to differentiate by something. Though digging deeper, interviewers still have the need to differentiate and fairly limited time so they bring prejudices with them. All humans have prejudices so as another said about not calling them "idiots", it's very natural but not necessarily productive.

Take college, for example. An elite school may tend to draw more elite students, but that in no way means everyone from a standard school is inherently inferior. It's just playing the odds to pick from the elites. For that matter, I've known a developer or two who had little formal education but was flat out great at slinging code.

I find your example a good argument for considering this a lazy tactic. First off, there are cases where simply the nature of the issue being more outside the box might make it more challenging than most business purposes. Secondly, the fact you solved a complex issue without the additional motivation of a paycheck, bosses and dependencies arguably speaks better of you than having done it when you had to.

There's even a dose of the fear that leads to purple squirrel requirements. Given the impact and cost of development, they are trying to be safe. Everything outside of the box is inherently less safe. Given ramp up time anyway, if they make a mistake it could be months before finding out the bottleneck isn't just tribal knowledge.

Answer 7

There are a few possible reasons:

1) The interviewer conflated 'open source' with 'college/university stuff' (tell that to Linus Torvalds)

2) They are under the (fairly accurate) impression that most 'open source' projects have no real organisation or structure. This is mostly true but there are notable exceptions, the kind where you can name the project and most people in open-source communities will know what you are talking about. Most places want people who can not only code but also coordinate with a team to do so.

3) When they asked the question, they were looking for details on the process. With hobbyist software development, it is as simple as seeing the bug/report and firing up the IDE. With professional software development, you need to raise a ticket, sync your local GIT to the latest branch, find and fix the errant code, submit your new branch for testing, submit a pull request, detail what you did in the pull request notes, sign off the support ticket... you get the idea. THAT'S what they wanted to hear about.