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
are you a front end engineer? I'll hire you right now!
(only half joking)
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.
It's probably too late for your "upcoming" interview, but if you donate some code to the odd open source project here or there, then you have something you can be proud of -- especially if the prospective employer uses the stuff you helped to write.) Many projects list names of contributors in a "credits" or "release notes" file, which gives you a way to show that the code is yours -- instead of stolen from someone else.
Not necessarily at least for code (not data access and representation). Depends on the code example and language.
If the target language is sufficiently diverse and expressive the code example can tell you about the way a person thinks at least as much as the interview.
There is no point to ask for code samples in java, python, ruby or smalltalk. Different people asked about the same problem will usually end up with the same implementation sans variable names and minor stillistic differences. That is the reason why these languages are popular nowdays - they allow industrial programming.
Now asking for a code example in perl, c and to a much lesser extent c++ is a completely different story. In these languages there is usually more than 1 way to hang yourself (in perl 5 on the average, in C around 3). As a result the code snippet can actually give you some insight on how the person thinks.
Asking for a data representation and access example and especially online ones (not save/snapshot) is also a completely different ball game. There you have multiple ways of hanging yourself even in otherwise limited choice languages like java and Co. It also gives an insight how a person thinks with regards to scalability, interaction between multiple threads, etc. Example - if a person in an online data representation and access example piles all of their data access in a single thread, locks the access with an exclusive mutex, reads/writes it non-transactionally and the data is passed to other threads via shared data segment - just ask them to turn around and leave. That is just one example. Plenty of others to go around.
Baker's Law: Misery no longer loves company. Nowadays it insists on it
http://www.sigsegv.cx/
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'
That's a useful exercise for ~15 minutes, but what are you doing for the other 45 minutes of the interview?
I tend to break a 60 minute interview down into 10-15 minutes talking about the candidates previous experiences based on his resume, asking him questions about projects he's listed and such, why he designed the solution the way he did, his role in designing and implementing a solution, etc. The next 15-20 minutes are spent on a simpler item like you mentioned, though I'll usually do a "trivial" programming task (something like reversing words in a string -- relatively simple, no "a ha!" solution requirement, and lets me see how they think about memory management and algorithm complexity). I'll use the remainder of the time on a larger question that focuses more on design. Something like designing the behavior of a Minesweeper game when you click on a cell that's not adjacent to any mine (good exercise in recursion, data structure management, and edge case detection). If there's any time left after that I'll field any questions the candidate may have about the position, the team, or the company.
Of course no two interviews are the same. Some people may end up spending a full 45 minutes trying to figure out how to reverse the words in a string. Others might blow through the design and code for minesweeper in 15 minutes. You at least have to tailor the interview questions to the level of the job (if a candidate for a senior developer position gets stuck on reverse words, it's game over), and to some extent the candidate himself (I give candidates the option to answer in whatever language they feel most comfortable in; to date I've mostly received C/C++/Java/C# answers, but I've had a few Javascript answers. I'm still waiting for a TSQL answer ... :).
In case it's not obvious, what interviewing I've done has been for development positions. Interviewing for QA, project management, or people management would be substantially different. Then again, I wouldn't be a part of any of those interviews since I'm a developer.
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.
what's truly funny is the lack of response on that note. Here's some other figures:
.NET though. Those surveys are probably too optimistic for you, and that's another thing I've seen far too much of - people that think they're great programmers (or even architects!) but only know 1 language, and don't even know it well. They do, generally, have some business knowledge, and smooze factor. But that's no reason to think they're technically inclined or capable.
$40K
$60K
$90K
$120K
$150K
Those are all figures of programmers at various levels I know personally. Yes, the $40K guy is a novice and getting screwed to boot. The remainder are an excercise for the questing reader. What kills me is that most of my friends and I consistently hit far above the highest posted salary averages, and we know we're not exactly the highest paid folk in the companies we work for. Considering the breadth of companies we cover, it's quite reasonable to come to the conclusion that salary surveys are more vehicles for employers to keep pay "low" than for employees to ask for raises. If you're below those averages and are a good programmer, you're getting hosed. This does not mean you believe you're a good programmer and you only know how to code in PHP, Java, or
If they request code samples, then they are anal and you don't want to work for them (as others have stated), or two, they are looking to see if you lift code from another source. Depending on the company, that can be either a good thing or a bad thing. If they are an ethical company, and they find you lifting code, then you are toast. If they aren't an ethical company, why do you want to work for them?
Either way, if a company asked me to bring in a code sample, I would cancel the interview, since obviously, I don't want to work for them.
Oh, and ANY code I worked on for previous employers is not my property, and to display it to someone else is violating the no compete clause I may have signed when leaving the previous company, or with my current employer.
In many job interviews over the last 25 years, not once have I been asked to show "code samples". With one company I was asked to take a basic programming test, but that only took a half hour. (Stupid test, they had an invalid question on it, where the correct answer would depend on the setting of a compile time switch in several languages).
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.