Unfortunately, not everyone has time or desire to work on personal projects. Being an engineer outside of work should not be a pre-requisite to being one at work.

>>That's pretty weaselspeak

as a more concrete example, as I get older I'm less interested in working on the computer off hours. I've noticed I don't even play video games as much as I used to. I actually started doing wood working a couple of years ago, and playing with 3d printers. It does go in fits and starts though - sometimes I get an itch to play with something just for fun...

I think swayvil's original point was that you could still speak of work you've done in the past. They said 'show' and 'personal', but I wouldn't take that so literally if your favorite project wasn't personal. Even if under NDA, and I'm a security consultant so I know all about those, usually it's still possible to discuss the general problem being solved and how you solved it, and have a good conversation about that.

That said, I do find this hard in interviews (when asked about past experience) and prefer to just be given a web application riddled with every type of bug and try to bingo them all in the time given to show that I understand them all. That one was my favorite interview. But that might just be a different style of interview for a different type of job.

I thought they made a good point. Make your objection more substantive and I'll get rid of the downvote.

You don't have kids, do you.

I'm not looking to interview, but if I would you'd find that my personal projects fall in categories of either being:

a) outdated, because almost all work relevant to my subfield have been at my job for a some years now (and my experience has grown accordingly, since), or,

b) irrelevant, because by now my personal projects are mostly orthogonal to my job (e.g. stuff involving electrical engineering and digital signal processing), which I am absolutely not applying for.

We did this in the first interview and they did well on that.

Then we gave an exercise* to write some code. In my opinion a junior (but not noob) programmer should be able to do it: the code should loop through a file that is too large to keep in memory and collect some statistics -- e.g. look up numbers associated with keywords and compute the average (where the keyword list is the large file; the lookup table is like ten entries).

This candidate (like the last one) instead worked around the memory constraint and just split up the file using external software such that they could fit the whole thing in memory. Not combining the partial results later or anything, no, just compute answers based on this one slice. Then in the interview afterwards, they could not describe how this could have been done differently, also not with hints (I understand they're under pressure during the interview). The code also had other problems (e.g. opening and re-reading this lookup file inline in the main loop... which runs a billion times). Even though functional (if not always giving the correct result; mistakes happen), they had neither a concept of memory complexity nor computational complexity.

So that's just anecdotal, maybe it was an outlier. From my perspective, talking about projects and code isn't always the same as them being able to work on the problems you're hiring them for.

* Note this was not entirely my choice, even though with hindsight it was a good idea we should at least have compensated their time regardless of the outcome imo.

Or any opensource project they have contributed to.

Yes, that would do nicely.

Doing it because you choose to. Because you like it. That's key.

The trouble with this argument is that it excludes a huge proportion of the best developers out there. A lot of people got into programming because they enjoyed it but after doing it all day at work they want to do something else with their personal time. And the more experienced someone is with programming the older they are likely to be and the more likely it is that they will have other interests and commitments competing for that time.

Most contributions to opensource happen on company time atleast in my experience. I don't code much outside of work yet have plenty of OSS contributions because in the course of my work I discover bugs, desire new features, etc. All the best developers in these circumstances will atleast attempt to get their changes merged so they don't have to carry patches.