Slashdot Mirror
Where Should I Get My Job Interview Code Samples?
crlove asks: "I'm preparing for an upcoming job interview and my interviewer will want to see some code samples. Unfortunately, all of the coding I've done work-wise since college is not only proprietary, but often classified. To be honest, with long days at work and a busy life outside of it, I haven't had much time to code on my own. So, what should I show my interviewer? Should I start working up some code samples? If so, what would be considered sufficiently complex to take to an interview?"
Anytime somebody tries to show me a code sample, the first thing I ask them is where they downloaded it from. Seriously, any employer that asks for a code sample has no clue what they're doing. They should put you at a whiteboard with a pen and have you write something on the fly.
If you don't want crime to pay, let the government run it.
*cough* you could always spend some time improving support for the linux bcm43xx drivers... ;)
Everyone seems to be in agreement except for a straggler a few posts down from here. Companies that ask for code samples are bozos and you don't want to work for them. But why?
The answer has to do with corporate culture. Companies are made up of human beings and each one has different goals and needs and personalities. Some people get along famously while others will tear each other apart if left alone in the same room. Some people are very friendly and easy-going, others are hard-edged and driven. The type of people you hire will determine the culture of your company.
Do people have fun at your company? Are they tired all the time? Do you have high rates of turnover? Do people think they work for the greatest company in the world? The worst? Do people dread meeting with other employees? Do people have a great time pounding out ideas together? Do people focus solely on their job position? Do people look at the company as a whole and see their role as a part of the greater whole? All these things are determined by the type of people you employ.
The type of people you employ is determined by your interview process. If you make the interview process a relaxed one where the interviewee has the chance to articulate his thoughts well, you'll get one kind of employee. If you make the interview process a difficult, high pressure affair, you'll get another kind of employee. If you ask them to submit code samples, you'll get people who are either incredibly anal or look for shortcuts. If you ask them to code on a white board, you'll get people who can think on their feet.
No one type of company works best for all situations. You wouldn't want cowboy coders in the bank software business. OTOH, you wouldn't want incredibly anal people working on next-generation UI stuff. But the type of people you hire is not only indicative of the culture of your company, it is a clue as to the personalities of the people working there.
Another problem with the code sample thing is that it shows that the company values code quality over quality of character. My cousin BasementDweller78 is a wiz at coding. He can drop his pants and shit better code than I ever could. But he's a complete asshole. He isn't pleasant to be around. He's your prototypical computer geek. He's also the one that will get hired at a company that values code over people.
So when some company asks for a code sample we all react with our gut and run far away. It's because we don't want to be around the type of people who would judge us on inanimate code. We'd rather be judged as humans and don't fear whiteboards nor do we lack confidence in our programming abilities. We are just a certain subset of all programmers. Those who value a pleasant working environment. Pleasant for us, that is.
i had a few interviews fresh out of uni. One place gave the final 3 applicants a puzzle to take home and solve based on a real-world situation, though no "code" was involved, we were asked to provide simple pseudo-code.
I thought that was odd as we could all go to external sources or each other.
The next place asked me in the interview "What can you tell me about this code? Problems, inefficiencies.. anything?". I thought that was a much better idea. Plus who wants to write code up on a white board when all nervous in an interview anyway right?
Of course, not getting the joke, Mr. $87,500 finds another opportunity to casually put it out there, in more detail, to make sure everyone gets it. He was forced! He didn't want to have to name his salary! He knows it's not classy!
And now perhaps the upper-middle-class slashdot chicks will come flocking.
Hey, you never know.
working 60 hour weeks writing code and everything else that comes up on a software project, you think that when i left that job I had personal code projects at home I'd been writing on?
no, at home I was playing computer games, getting out and socialising, shooting field archery and playing snooker.
it isn't that i wasn't interested in code outside of 9-5, it was that the job wasn't 9-5 and i (along with a lot of other people) have more than one interest in life.
Incidentally, one company I interviewed with did send a programming problem through with a "please send a programmed solution through within three days". I wrote it up and sent it in after two evenings and they liked my solution.
Do that if you want code examples, don't expect everybody to be writing code in their spare time, and definitely don't expect commercially sensitive code to be brought along to interview.
However this is a good reason to have considered (at least considered!) doing a bit of work for an open source project. There are lots of them on SourceForge (and many other fine places) begging for help. A few bits added in make nice examples you can point to when asked for code samples. I know, it seems like a huge time investment that you don't have, but it really doesn't have to be. Further, every little bit helps the project guys.
In the time that it's going to take for you to read all of these responses, you could have sat down and written some code that will impress them. They're not looking for your magnum opus... They want to see stuff that shows you can understand a problem and translate your understanding into compilable syntax. In fact, they probably don't even care about compilable syntax. Think of a cute hack and write it instead of reading slashdot. Take it in and say "I can't show you any of the code I've written professionally, so I wrote this last night. You can confirm with google that I didn't download it from anywhere if you like, or you can ask me any questions about it and I'll be happy to answer them." Don't pick something related to the companies' core business. They understand their problems _way_better_ than you do. Second, decide whether you want to work for a company that quantifies you based on your code output. I'm a coder and I only spend about 10% of my work time actually writing production code. The rest is hacking test cases, prototyping, designing, staring at graphs, and attending team meetings.
Ask questions about it. They usually show very quickly if you understand the code. Then there are four possibilities:
1. The code isn't yours and you don't understand it. Bad. You're out.
2. The code is yours and you don't understand it. Also bad. Also out.
3. The code is yours and you understand it. Good.
4. The code isn't yours, and you understand it. Outstanding.
Except they specifically told me not to bring anything proprietary.
I ahad someone do this to me once, I took a look at it and knew immediatly what it did so I told them straight off.
They were unhappy that I didn't 'Walk the process'.
I told them its 8 lines of code, 4 of them that just defining variables. If someone needs to sit down and think about it for more then 2 seconds then they are not principle material.
Needles to say they didn't call me back; Which was fine since by that time I could see they weren't exactly the sharpest knife in the box.
FUnny thing is, I had worked with the guy they hired before, and the y certianly got what they deserve.
The Kruger Dunning explains most post on