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?"
If you dont have time, pay someone on rentacoder.com to write something for you.
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.
You can always "lift" some snippets from here.
DYWYPI?
if your really good you get a hold of their code fix it and give it back to him in the interview - personaly i like the idea of handing the person being interviewed something from the cbfuscated C contest and ask them to take 5 min and tell me what it does - if they know you show them (seen it before) hire them... if they can manage to read it in 5 min and know what it does having never seen it before - hire them.. if they just look at you dumb.. send them home.
but that is my personal view..
'...if only "Jumping to a Conclusion" was an event in the Olympics.'
Tell your employer that it is all classified. There is really nothing that you can do about it. It would be a breach of contract and could leave you in legal jeopardy if you showed any of it to him...
But the TSP has a solution. Tell him that you will code for him if he can give you a terse, yet challenging assignment. This will let him see what he wants to see (i.e., what he wants to test you on), and you're willing to take out a bit of your time just to show him that you're a hard worker. This strategy worked for me and landed me a job in the upper 80's!
10 rem My first program... :P
20 print "HELLO, WORLD!"
30 goto 20
...they ought to give you a problem to solve and expect you to mail in the solution, something like 'ok, let's coordinate, sat morning at 8am I'll send you problem xyz by email, you mail back your code by 5pm, we'll discuss your solution during your follow up interview'.
There's no way that a prospective employer can reasonably expect to be able to look at your current production code, and if they do and they expect you to bend the rules of your current NDAs I'm not sure it'd be somebody I'd want to work for anyways.
-- the cake is a lie
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.
float InvSqrt (float x){
float xhalf = 0.5f*x;
int i = *(int*)
i = 0x5f3759df - (i>>1);
x = *(float*)
x = x*(1.5f - xhalf*x*x);
return x;
}
Just ask them to sign something saying they won't use it or you'll sue em. That will impress them and know that they can count on you not to show off any code you write for them and show off the coolest stuff. Either that or show a simple example of how you fixed a common problem that other programmers leave in most programs and be able to explain how you thought of it and why you implemented it as well as have an example of another popular program that didn't fix the problem (preferably from Microsoft.) For example, if you found a way to sync up the highlighted line between multiple bound listboxes to eliminate the delay between the mouse down and mouse up (I'm even still working on that one) and you show that then there ya go. They'll be impressed that it's yours, it's smart, supposed professionals leave it in their programs, and there's a decent reason for it...though you could find a fix with a better reason than "it looks prettier" like with the listboxes. Btw if you do fix that listbox problem, send me to code too lol.
Google's Super Secret Search Algorithm: SELECT @search_results FROM internet WHERE @search_results = 'good'
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.