If you're hiring a senior engineer that claims he spent last 5 years coding Big Table at Google, you have to take his word for it.
I find this assertion to be virtually nonsensical. I've never met a programmer who hasn't written some code that they could show you, if for no other reason than programmers who are passionate about what they do, usually write at least little programs just for fun. And if I were interviewing a programmer, I'd think twice about hiring one who has so little passion for programming that they'd never written anything just for the pleasure of it.
But let's assume for the moment that there are tons of great programmers who've never taken a class for which they could show their code, nor written any code just to write it: Where I work we have a small programming exercise that we ask applicants to submit for code review before we interview them. This process is much more natural than having people code on a whiteboard, because they can do it at their own rate and with their own tools, without having the stress of having someone look over their shoulder. They can also pay proper attention to issues of style and maintainability of their code. The assignments are also something kind of like the work that one might do in the real world.
I write lots of code just for the sheer pleasure of it. None of it is publicly available though nor would I like to share it. Shipping code is a lot of work. The other day I wrote a quick app at my end to analyze and make sense of some parts of a project that I am about to take on. It does what it needs to but if I had to ship it, I would want to proof read it and describe it's purpose to a general audience and make it at least general enough to have some utility outside my immediate needs. That's a lot of work. I write a lot of code for fun and profit. Writing code and publishing/sharing code are two very different things.
Okay, well Google doesn't want to hire you if you can't write efficient and elegant code on a whiteboard for a problem they've specified while they look over your shoulder. Me, I only don't want to hire you if you can't take a few pages of code you've written for fun and make it presentable. Who would you rather interview with? (Assuming, of course, that I was offering jobs as nice as the jobs at Google.)
I might be an exception here but I much prefer the whiteboard. I have one in my room and I enjoy problem solving. Pressure environments really do not impact me much. And if you have a whiteboard in your office and you do use it for actual work and not just interviews, this gives me an excellent opportunity to check your quality as a future problem solving accomplice. It provides me a real if brief window into what working with you would be like and I like that.
Having said that, market realities are what they are and I will probably take a month off when I can afford it and put some substantial code out in the wild. Can't hurt to have both bases covered. I will still like to make the point in here that I will be doing this because of the perceived business climate not because I really want to.
"And if you have a whiteboard in your office and you do use it for actual work and not just interviews, this gives me an excellent opportunity to check your quality as a future problem solving accomplice."
Except that when preparing for an interview, most places will clean the whiteboards before you arrive to make things more presentable, and to avoid accidentally divulging company secrets.
I write code every day, but I don't save it and its been 20 years since I wrote any code for 'pleasure'. For pleasure I have sex, go to a symphony or swim in the ocean. Coding is something I do because I'm good at it and people will pay me for it.
Further, I don't save code. I sell it. If I saved it then I would have to organize it, keep track of it and back it up. Why do that? I'm a programmer. Code I have written for fun or for some small experimental reason has no value to me because I can do it again and again at any time, like breathing. Sure, non-programmers value my code and they save it for posterity but I don't. It has no value to me once I've been paid for it.
Why would I go to all the trouble to keep a complete record of something I could do again at any time? Am I supposed to save what I'm typing right now to prove I can communicate? Do I save lawn clippings to prove I can operate a lawn mower? Do I save my waste to prove I can defecate?
You save code + accompanying documents in order to build up a portfolio to demonstrate to a potential employer how you work, how well you know your tools, and what your idea of a shippable product is. During the interview, you can talk about why you wrote the software, what designs you tried, what kinds of challenges you faced while doing so, and how you surmounted them.
At my company, we offer coding challenges for people who don't have a portfolio already. But really, why not just write software of your own choosing so that you don't need to do coding challenges to prove your ability? It's a far more efficient approach.
> If I saved it then I would have to organize it, keep track of it and back it up.
I really find this hard to swallow. It fails for me on so many counts.
Firstly, code is small compared to just about anything else you might keep on your computer. All you have to do to preserve it is drop it in a directory you keep for that purpose. The code doesn't have to be organized in order to preserve it. If you back up your computer, then your code is backed up. You back up your computer don't you?
Sure, it may be hard to find some useful piece of code later if you don't organize it, but preserving it, at least, is easy.
More importantly, you never write reusable code? You never write a library that can be applied to future problems? If not, then, you may not be the type of programmer that I'd want to work with anyway. I firmly believe that the way to increased productivity for any team is to factor out useful components and make them into more general purpose libraries. To do otherwise, is to end up with a codebase that is bloated with boilerplate.
Thirdly, if coding for you is as natural as breathing, surely you can whip up a couple of pages of code as a "code portfolio" in no time. You could have done that instead of typing in the above for your pleasure.
Not against you personally, but I'm fascinated by how clear people are about aspects of candidates they don't want to hire. There are so many dealbreakers in this thread (in the main), it's like a dating site full of people who have a lot of difficulty finding partners (hint: all dating sites are full of people with dealbreakers).
"I find this assertion to be virtually nonsensical. I've never met a programmer who hasn't written some code that they could show you"...
I've met plenty. Interviewed 6 candidates a few years ago - only one even brought anything beyond his resume. He brought a full physical portfolio of work he'd done. Most of it was web screenshots and such - not much 'code' to speak of, but he'd made the effort. No one else did.
I've been in plenty of places where people say "I can't show my work, cause it's for my previous employer". And they don't code when they go home. Or on weekends.
I brought code samples to an interview once, and the interviewer wouldn't look at it because "it wouldn't be fair to other people who don't bring code samples".
No doubt many people can, but you may be living in a bit of a self-selection bubble where everyone you know and mix with has loads of spare code to demonstrate. Many people don't. Now... if you want to use that as a signal for that person's interest level or ability, feel free to. You may be missing out on some otherwise competent or talented folks. But we all have to use signals to filter out candidates, and that may be a valid signal for you to use.
If you didn't ask candidates to bring code samples, it should come as no surprise that most don't, even though they might be able.
Where I work, we don't ask candidates to bring in a random code sample because instead we have them submit a coding exercise that they can do at home at their leisure. Our entire team then code reviews the code. Given the quality of most of the code submissions, it may be true that most programmers never program for fun, but if so, it shows this fact shows in the quality of their work.
All of the people who've given us nice submissions have also been very enthusiastic about what they do. I know this because we ask candidates if they read any programming journals or books just for their own edification, and the good ones always do. They always show some motivation beyond just completing assigned tasks.
We're a Scala shop, though, so we need people who aren't just programming because it's their job and for no other reason. Such people would have no motivation to become skilled in a complex programming language that is not yet mainstream.
I was doing PHP in 1996. If you were doing PHP in 1996, it was generally because you wanted to do it, learn it, etc (arguably web stuff in general then a bit too). There weren't many "PHP jobs" as such back then, so when you found other PHP developers, you knew they were enthusiasts of some sort.
That's where Scala's been, and almost any 'newish' language. If you find people adopting them, they're probably enthusiastic about it, and enjoy living on the cutting edge. :)
I find this assertion to be virtually nonsensical. I've never met a programmer who hasn't written some code that they could show you, if for no other reason than programmers who are passionate about what they do, usually write at least little programs just for fun. And if I were interviewing a programmer, I'd think twice about hiring one who has so little passion for programming that they'd never written anything just for the pleasure of it.
But let's assume for the moment that there are tons of great programmers who've never taken a class for which they could show their code, nor written any code just to write it: Where I work we have a small programming exercise that we ask applicants to submit for code review before we interview them. This process is much more natural than having people code on a whiteboard, because they can do it at their own rate and with their own tools, without having the stress of having someone look over their shoulder. They can also pay proper attention to issues of style and maintainability of their code. The assignments are also something kind of like the work that one might do in the real world.