Slashdot Mirror

← Back to Stories (view on slashdot.org)

Where Should I Get My Job Interview Code Samples?

Posted by Cliff on 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?"

6 of 249 comments (clear)

  1. A total waste of time by toddbu · · Score: 4, Insightful

    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.
    1. Re:A total waste of time by zullnero · · Score: 5, Insightful

      You know what works even better than a "lets stare at the poor guy as he tries to scribble some code clear enough for us to understand, then begin to nitpick like a bunch of chest thumping, thirtysomething, 'I'm an experienced coder and should be the manager'" orgy? Checking references. It doesn't take that long to do. If you can't get anyone, you contact the guy and ask them for someone else, and make sure it's either a college professor or the actual manager/supervisor. Doing that, in conjunction with sending the guy a short project and having him do it over the weekend, is as good as anything else.

      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.

    2. Re:A total waste of time by quantaman · · Score: 4, Insightful

      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. A whiteboard is a lot different than a computer and all its associated resources. I've seen great coders freeze up when asked to code on a whiteboard and useless people come up with something great, especially when how clever they can be when writing an algorithm isn't what I'm interested in.

      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.
      --
      I stole this Sig
    3. Re:A total waste of time by Anonymous Coward · · 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.

  2. Why is asking for code samples a bad sign? by BadAnalogyGuy · · Score: 5, Insightful

    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.

  3. Re:Be honest! by Ihlosi · · Score: 5, Insightful
    How is the interviewer to know that it is yours?



    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.