Slashdot Log In
Where Should I Get My Job Interview Code Samples?
Posted by
Cliff
on Thu Dec 14, 2006 01:59 AM
from the delivering-the-goods dept.
from the delivering-the-goods dept.
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?"
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Easy solution (Score:5, Funny)
A total waste of time (Score:5, Insightful)
Re:A total waste of time (Score:5, Funny)
But since they asked, you might as well think big. [kernel.org]
Parent
Be honest! (Score:5, Informative)
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!
Parent
Re:Be honest! (Score:5, Funny)
Parent
Re:Be honest! (Score:5, Funny)
Parent
Re:Be honest! (Score:5, Insightful)
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.
Parent
Re:Be honest! (Score:5, Funny)
Parent
Re:Be honest! (Score:4, Interesting)
That's the approach I take. "Here, what does this script do? Go into as much detail as you'd like." It's not so much what they say, but how they approach the problem that I'm interested in.
Parent
Re:A total waste of time (Score:4, Informative)
Parent
Re:A total waste of time (Score:4, Funny)
Parent
Re:A total waste of time (Score:5, Insightful)
Seriously, how much of your project will this potential employee be doing on the whiteboard? NO one codes that way. Once in awhile, you stand in front of someone else and scribble out a flowchart or a diagram to clarify something. That's it. Just because the guy forgot a semicolon somewhere on a whiteboard scrawl doesn't mean he'll take 5 times longer to get something done working within an IDE that has built in context checking, has a help system loaded with code samples, and an internet connection that allows him to go out and find snippets made free to everyone when he's stuck on something.
In fact, I'd greatly prefer employing someone that resourceful over someone who will sit there and bang their head over some problem for days or weeks. If you have someone who can find code, understand it well enough to incorporate it, and is detail oriented enough to refactor it clean, that's worth a heck of a lot more than some altruistic chump who thinks it's better to rewrite the wheel for everything. Resourceful people get the work done on time.
There are occasionally situations where a coder has to solve a problem that hasn't been solved before, or where there isn't a solution readily available. However, those situations are really, in this day and age, few and far between...and if a coder can understand and incorporate a snippet of code into a project and make it work, he probably understands enough to write code on his own.
Parent
Re:A total waste of time (Score:5, Insightful)
Programs are large and very complicated systems, in my opinion a great programmer isn't someone who can write the fastest sort, it's the person with the skill and determination to quickly understand, and extend, large complicated programs.
Thus when interviewing I like to have someone bring in a bit of their code. I then ask them to give an overview of what it does and how it works. I then ask them about how they would go about making a certain change in the requirements. What I'm looking for is how thoroughly they understand the design of the code and how well they can communicate that code to someone else. Even if they did download it they still have to really understand it and that's the hard part.
Parent
Re:A total waste of time (Score:5, Interesting)
I disagree. I could be very useful in the interview process. We used it just to give us something very concrete and technical to discuss with the engineer. Throwing some people questions makes them very nervous, like they're being tested. Having them bring some of their own code to discuss makes most good engineers very relaxed. Here, they get to show their prospective employer something that they're reasonably happy with. If I ask any questions, they're usually very quick to answer. Now, I'm the "newbie" in the code, and they're just showing me around.
I suppose that it depends why the potential employer wants it. Ask them. Many programmers just "steal" a page of code from some system they're working on even if it is proprietary. If you don't feel comfortable doing that, just work on something for a few hours. Whatever you have time to do. It might not have to be complete or very complex.
When one of my managers started asking new candidates for code samples, it was actually quite useful in the interview process. I really didn't care whether they wrote it or downloaded it. We weren't looking for "do you know how to write code." We were really interested in hearing you talk about code. Hopefully, you sent us something you wrote. But it wasn't critical to the interview that you did.
That is, you'd send us a page or two of code the day before the interview. It didn't even have to be in the programming language we were hiring you for (Java, C++, or Perl). One guy sent us some LISP code. Your interviewers would read over the code. Then, during the interview, we'd take out a copy of the code, ask you to give us an overview of what it does, and ask some more specific questions.
Some examples: For a systems/tools job, one guy just pointed us to a little module in CPAN. The CPAN code had good PERLDOC comments, of course. It was packaged as a module. The guy could explain why he ended up writing it and talk about the code even though it had been a few years since he touched it. Another guy sent us code to a CGI script that he used on a personal web server to track some data between him and his friends. That code was okay, and the guy could explain what he was doing. But it was also a giant flat script. No subroutines. Almost no comments. Program logic and HTML output intervleaved in a somewhat confusing manner. The developer who sent us the CPAN code got the job. Not just on the basis of his code, but it just confirmed everything else we got out of the interviews.
For another position, some developers sent us a page or two lifted from some of their Java code. Of course, in any real application, a page or two of code doesn't show you much. Still, one guy sent us code with what were almost certainly errors in it. Rather than telling the developer, "Um, this looks like an error," we just asked him to explain what the code was doing. I've rarely seen a candidate look so nervous. He didn't really seem to know what the code was doing. Either he didn't write the code, or he didn't really feel comfortable talking about code. Bzzt. Not someone we wanted on our team. In any case, if you're going to steal code, try to have good enough taste to steal good code. And if you're showing me code that you didn't write, at least take the time to read it and understand what it does.
For the same job, another developer sent us code for a few methods. As soon as I started asking about the code, she looked so relaxed. Now we were just two engineers talking about code. She started sketching in the margins of the page to show a rough system architecture and where this code fit in. She explained a bit of the data flow and some use cases where the users interacted with the system. We talked about the data being passed in to one of the methods. At one point, she wanted to explain something, realized that she hadn't sent us that code, and sketched a rough version of the code on the back of one of the pages. Her quick version had a silly error. When I pointed it out, she just laughed and said, "Oh, right. It should be like this," and she fixed it. But she was eager to get back to explaining where that sketched code connected to the other code. That's the kind of developer we were looking for.
Parent
Re:A total waste of time (Score:5, Insightful)
That's a horrible idea. What the hell are they supposed to write? "Write down a linked list object, you have 30 seconds on the clock!"
Haw! I just had a job interview yesterday and that's exactly what they asked me to do on the white board! Then they left me with my laptop and a coding assignment. In the past I had fantasized about doing that to people whom I had had to interview, so I didn't mind. After all, they want to make sure you can code.
But, I've gotta say, I think this approach favors 1) people who've recently had programming classes where they cover general algorithms and data structures, 2) programmers who tend to think at an abstract level, whereas what I've found to be a more typically useful skill is the ability to translate business requirements (ie, what the customer wants) into code.
Parent
Re:A total waste of time (Score:4, Interesting)
Parent
If you can't think of anything (Score:5, Funny)
find theirs (Score:5, Funny)
but that is my personal view..
Here's a code sample from my younger days... (Score:4, Funny)
20 print "HELLO, WORLD!"
30 goto 20
If they want to ask for a code sample... (Score:4, Interesting)
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.
Just say you invented this: (Score:5, Funny)
float xhalf = 0.5f*x;
int i = *(int*)
i = 0x5f3759df - (i>>1);
x = *(float*)
x = x*(1.5f - xhalf*x*x);
return x;
}
mod me down for obvious... (Score:4, Insightful)
you're wasting your time .... (Score:4, Insightful)
Why is asking for code samples a bad sign? (Score:5, Insightful)
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.
Parent
Re:Why is asking for code samples a bad sign? (Score:5, Funny)
He probably isn't pleasant to be around because of his coding style.
Parent