[amatecha]

Uh, I absolutely look at interviewee's personal projects, especially if they are using technology directly related to what I'm looking for. Also especially when they are literally a creator/maintainer of one of the open source libraries my team is using. You can very often hear interesting stories of how the person solved unique, challenging problems. To ignore the products of an interviewee's personally-driven efforts seems like a serious mistake, in my opinion.

[gregjor]

An actual maintainer of an open source project that has users would get my attention, but that's not what I call a "personal project." There's a big difference between someone's work on a useful open-source project and their personal to-do list app or social network for people who own ferrets.

If a candidate had a personal or side project that solved a unique and challenging problem I would look at it. When I have seen personal projects they look like programing class assignments or riffs on a language/framework tutorial.

When interviewing I am always most interested in how the candidate will fit into the team and organization, and if they understand the difference between adding value to the business and playing with technology for its own sake. The last time this came up in an interview the candidate had some Raspberry Pi/Arduino code they were proud of, probably fun but not relevant to the job, and so far removed from the business domain that I couldn't judge how relevant it might be.

[rantallion]

Checking out their projects (if they have any and volunteer them) is fine. Just as long as we don't expect them to have said projects.

I can see the argument for a candidate seeking their first job in IT needing to distinguish themselves from the rest of the crowd and how a couple of well-executed projects can help with that. However, it's unfair to expect that any candidate must have projects, especially if they're already in employment elsewhere - few of us have the time or the energy to put into projects of passion after we've done our 40 hours and taken care of other priorities.

[gregjor]

I agree. I don't have any side/personal projects to show because I don't write code for fun. Because the code I write is almost always owned by an employer or client I have to get their permission to show snippets, and rely on describing the problem and how I contributed to solving it.

Code samples are easy to plagiarize so I always ask candidates who have code samples to explain the code, walk me through it. It's disappointing to see how often candidates can't do that, either because they don't actually understand the code or didn't even write it themselves.