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?"
...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
That was it. No other direction, no manuals. Ah, yes, there was "man"...but the $MANPATH was bare-bones and the guest account had extremely limited access to anything besides /usr/* and /home/guest. On top of that, the only editor that worked was "ed" (vi couldn't handle the term I was running in) and "cc test.c" threw a whack of errors [though I could fix it by tweaking $INCLUDE]
After 5 minutes of mucking around, I left the interview room to track down my interviewer to ask for some tweaked permissions. That was win #1; apparently only 20% of interviewees came foreward before trying some type of coding, and even then most didn't know what exactly to ask for in terms of help.
Once I was able to "man opendir", they left me alone for another 45 minutes then cut me off because they'd seen enough (watching the files from another account).
Now, mind you, this was for a junior position so they weren't looking for much in the way of overall code structure, etc. They were more after whether the interviewer knew what Unix was about and if they would take the initiative to overcome some obstacles.
It's a simple matter of complex programming.
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'
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.
If a job's not worth doing, it's not worth doing right.
An interesting idea, but topics 1 thru 3 require complicity in grand theft. Topic number 4 is intrigging; Why not have the interviewer present code, and have the candidate describe it?
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.