Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Programming

How To Show Code Samples? 485

Todd writes "I've been looking around at 'help wanted' advertisements for programming jobs, and almost all of them demand that you not only have professional experience, but also that you show samples of your work. This got me wondering; with the work product, trade secret, and non-disclosure laws/agreements, how exactly can you show work that you've done in a professional capacity to a prospective employer without violating the privacy of the company for which the code was written? For instance, I can't say I've written many BASH scripts (at least, not large ones) for myself personally, but the assortment of such scripts written for my current job is wide and varied indeed. I can't very well just deliver these scripts, or even small portions thereof, to third parties to help demonstrate my scripting prowess. With that in mind, what am I supposed to show them?"
This discussion has been archived. No new comments can be posted.

How To Show Code Samples?

Comments Filter:
  • Open source (Score:5, Insightful)

    by Tablizer ( 95088 ) on Friday July 11, 2008 @08:01PM (#24159911) Journal

    Work on an open-source project, and use that code.
           

  • Good example (Score:5, Insightful)

    by overshoot ( 39700 ) on Friday July 11, 2008 @08:02PM (#24159917)

    With that in mind, what am I supposed to show them?

    ... of why clueful programmers contribute to software libre projects -- it's good advertising.

  • And this is why... (Score:5, Insightful)

    by chaboud ( 231590 ) on Friday July 11, 2008 @08:03PM (#24159937) Homepage Journal

    You should have side projects.

    The big win with side projects that are entirely under your control is that the code is entirely your style. Almost all of the code that you write for work will have some legacy or shortcut warts, but your self-made utility code can be entirely of your own style and principles. This can be good or bad.

    If you don't have any code that you can show, ask your prospective employer to concoct a reasonable example.

    If you don't have any code of your own to show them, that tells them something. If they can't come up with a reasonable task for you to demonstrate your abilities, that tells you something.

  • by MythoBeast ( 54294 ) on Friday July 11, 2008 @08:05PM (#24159955) Homepage Journal

    Generally, when looking for software engineers or system administrators, I try to find the people who enjoy what they do enough that they don't mind doing it when they get off of work. If you haven't written anything interesting outside of work, and you're completely uninterested in doing so, then this automatically drops you down a notch among those that I would hire.

    Beyond that, though, you can't show prospective employers things that you've done for other companies unless you own the source code. On the other hand, the company you wrote it for absolutely cannot bar you from producing derivative works from memory. That would result in devaluating your skill set, which is considered an unconscionable harm by our courts. Write something similar but less ambitious at home and present that instead.

  • This is on the right track, but I think that there's another aspect of any candidate that could be gleaned in a half-hour ... their ability to *think*. Being able to write code is only half the job (the easy half). Give them a goal, and ask them to describe on the board their thought processes as they analyse the problem, and how they'd go about doing the data design, the code, etc.

    You'll get a feel for whether they're agile on their feet, enthusiastic, can grok something quickly and come up with some useful ideas, etc., without actually having them sit a a computer and write code. If they get lost at this stage, there's no need to see any code.

    It also lets you see if they're a "I know this particular "hammer", so everything looks like a nail that's best whacked with that particular hammer" type of dev., or whether they actually have a grounding in more than one solution.

    It's a LOT more accurate than a written test at weeding out the "I can write the code if you hold my hand" types. You'll *know* if they're enthusiastic or not.

    Alternatively, just ask for their slashdot user id, or just say "CowboyNeal". (Don't laugh - it works).

  • by cjb658 ( 1235986 ) on Friday July 11, 2008 @08:16PM (#24160033) Journal

    After spending 8+ hours in a cubicle writing code, the last thing I'd want to do at the end of the day is come home and write more code.

    The same is true if I spend the entire day opening up computers and repairing them, setting up networks, etc.

  • by Austerity Empowers ( 669817 ) on Friday July 11, 2008 @08:17PM (#24160037)

    That's really a better way. We have some people come in (for a HW job, but same restrictions) bringing in PCBs they've designed in other places, etc. In addition to the obvious potential theft question, it's not appropriate to even look at designs done by another company.

    It's really not that helpful as an interviewer to ask someone to show work they may or may not have done anyhow, you want to be sure they presently have the capacity to do so.

    Another alternative that meets the interviewers demands, however is to design something of your own that solves a relevant problem in your field, and present that. It doesn't have the be huge. Point to GPL work you've done, or a pet project you worked hard on. I personally think it's not as practical, again I want to be sure the person sitting in front of me is the good problem solver.

    I'd never dream of even "testing" someone by asking him to bring in work done for another employer, even one that's relatively permissive. I wouldn't want even the appearance of impropriety. If it's brought in, especially with all the crackdowns going on in large corporations wrt licensing...it will only count against you.

  • by Octorian ( 14086 ) on Friday July 11, 2008 @08:19PM (#24160063) Homepage

    I also hate whiteboard coding. I love using whiteboards for drawing diagrams, though. Probably the only code I'll normally do on a whiteboard is an interface or syntactical illustration anyways.

    Of course another issue I have is that I tend to get quite nervous during interviews, whether or not I have a reason to be, and that probably makes matters worse. Standing up there shaking while sweating in a suit and trying to code something on a whiteboard... Lets just say I'll come across like a stumbling idiot on something I could do trivially in a normal environment.

  • Re:brainfuck? (Score:2, Insightful)

    by Bill, Shooter of Bul ( 629286 ) on Friday July 11, 2008 @08:25PM (#24160115) Journal
    Stole my joke. I'd suggest my new favorite language Malbolge [99-bottles-of-beer.net].

    Please don't mod up, I'm just stealing the reference from david.given [slashdot.org]
  • Re:Sample Code (Score:2, Insightful)

    by Zenne ( 1013871 ) <hannahmariebear@gmail.com> on Friday July 11, 2008 @08:32PM (#24160185) Homepage Journal
    Christ. Is the site listed as your homepage the one you show to potential employers?
  • by javajedi ( 81810 ) on Friday July 11, 2008 @08:33PM (#24160187) Homepage

    Dude. I write code for free. The salary is just so I'll sit through the meetings and deal with my coworkers.

    If you don't love writing code so much that you want to do it when you get home, maybe you just shouldn't be writing code. Life is too short to do something you don't love for a living.

  • by kv9 ( 697238 ) on Friday July 11, 2008 @08:36PM (#24160197) Homepage
    that's pretty sad.
  • Re:brainfuck? (Score:4, Insightful)

    by v1 ( 525388 ) on Friday July 11, 2008 @08:41PM (#24160227) Homepage Journal

    being able to properly translate anything large to brainfuck will either guarantee you the job, or get you tossed out of the office by the interviewer, depending on the job.

  • Re:Open source (Score:4, Insightful)

    by v1 ( 525388 ) on Friday July 11, 2008 @08:44PM (#24160267) Homepage Journal

    being able to direct them to a search on a repository and start pulling up your code all over the place definitely looks good.

  • Re:Be smart (Score:5, Insightful)

    by clarkkent09 ( 1104833 ) on Friday July 11, 2008 @08:48PM (#24160291)
    Funny, but it's a good point. How do the employers know that the candidate is showing his/her own code? Even if they are, most likely the code for show will be polished to perfection over however long that takes, and probably not representative of their code while working on a deadline. Far better to give a test during the interview and have your best engineers present to evaluate the candidate
  • by Anonymous Coward on Friday July 11, 2008 @08:49PM (#24160307)

    You sir are an asshole.

  • Re:Open source (Score:4, Insightful)

    by wonkavader ( 605434 ) on Friday July 11, 2008 @09:01PM (#24160401)

    This extremely good advice. The impact of having your name on a well-known open source project to many people cannot be overestimated. Won't work on everyone, but to many, you'll acquire a slight glow.

    And yes, you can show your code.

  • by KermodeBear ( 738243 ) on Friday July 11, 2008 @09:07PM (#24160437) Homepage

    That is far too idyllic for the real world. As true as it may be, doing something I love for a living would mean having little to no income. It simple is not feasible.

    And so I suffer through 8-10 hours a day of writing code and putting up with my coworkers. It isn't fun - but I get paid to do it. I get paid pretty well, too. Enough that I stay.

    At least I can pursue something I do enjoy in my free time. Currently looking into a Wildlife Rehabilitation license.

  • by NewbieProgrammerMan ( 558327 ) on Friday July 11, 2008 @09:13PM (#24160481)

    Oh yes, let me rush to burn up 4-8 hours of my time doing some contrived, over-specified programming exercise for each job application. I have a medium-sized stack of bug fixes and improvements to open-source projects I can point to, but that's not good enough for some companies: I have to do their extra-special lame example program, because I might not be uber enough to work at their uber-elite programming company.

    Once upon a time I thought code samples might be a good idea, but now I'm starting to think that it makes a good lameness filter for my next job search. IMHO they just use up everybody's time for very little benefit; you'd almost be better off just hiring them at a low probationary pay rate and see how they actually perform in your work environment.

  • by lewp ( 95638 ) on Friday July 11, 2008 @09:20PM (#24160521) Journal

    I did some smaller contract work on the cheap with the stipulation that I could use the code I wrote however I wanted. That's where most of my code samples come from. Smaller shops are often willing to compromise in ways bigger corps aren't, especially when it's possible for them to save money.

    You could also just whip up a reasonably professional sample app and explain that your "real" code is locked up with your old employers. Companies worth working for, and recruiters worth talking to, will understand your situation. They probably have clauses in their standard employment contracts that restrict their employees in the same way, after all.

    By the way, this is another good reason to contribute to Free Software.

  • by LanceUppercut ( 766964 ) on Friday July 11, 2008 @09:25PM (#24160555)

    No, most of the time it indicates that it is the reviewer that either a) doesn't know his stuff or b) thinks that everything that doesn't comply with his favorite one and only true coding standard is flawed.

    Needless to say, judging by the tone of that poster he's not the type that would even consider reading a further response from the code author explaining why there's really no buffer overflow in line 42.

  • by bigsteve@dstc ( 140392 ) on Friday July 11, 2008 @09:43PM (#24160703)
    In my last job, middle to senior level developers were involved in the process of screening and interviewing candidates to join their team. It was common practice to ask questions that involved coding on a whiteboard ... or over the phone.

    This was not done to torture candidates (or the interviewers for that matter). We were trying to find out things like the following:

    • Could the candidate actually program competently. You would be surprised the number of candidates who "exaggerate" (i.e. lie about) their programming skills.
    • Could the candidate think through a problem and come up with a good algorithm on the fly.
    • Could the candidate perform under pressure.

    These are all important attributes that you want to know about a developer ... before he / she joins your team and messes up an important project for you.

  • Generally, when looking for software engineers or system administrators, I try to find the people who enjoy what they do enough that they don't mind doing it when they get off of work. If you haven't written anything interesting outside of work, and you're completely uninterested in doing so, then this automatically drops you down a notch among those that I would hire.

    You look for people who live to work not for those who work to live? Or just someone who's single minded?

    Falcon

  • Re:Be smart (Score:2, Insightful)

    by Anonymous Coward on Friday July 11, 2008 @09:46PM (#24160723)

    Once again, John Gabriel's greater internet fuckwad theory [penny-arcade.com] rings true.

  • Re:Be smart (Score:5, Insightful)

    by p0tat03 ( 985078 ) on Friday July 11, 2008 @09:50PM (#24160749)
    In-interview tests are just as ineffective as code samples. For one thing, you would allow your engineers much more time under far less stressful conditions when they write their code, with access to many more resources (references, books, colleagues, etc.). The code that they're pumping out in an interview is also not totally indicative of their real skill.
  • Re:Be smart (Score:3, Insightful)

    by Anonymous Coward on Friday July 11, 2008 @09:56PM (#24160783)

    If you've written that many bash scripts you should be able to whip up a few examples really quickly to show people. Shouldn't take more than a few hours and you'll probably have fun doing it :)

  • by Anonymous Coward on Friday July 11, 2008 @09:57PM (#24160797)

    The vast majority of human beings have exactly that existence. There are only so many lucky ones who get to follow their passion (if they have one) and only the luckiest of them get to actually have good work environments where they can shine. Even for those of us who love coding, there's noisy/distracting cubicles, constant interruptions, stupid deadlines, micromanagement, insane coding style mandates, worthless proprietary tools that you "have" to use, and so on and so forth.
    At the end of the day, you go home and your mind is fucking numb and even though you might have some projects you'd like to work on, you're barely even coherent enough to even play a video game. So that leaves the weekend (assuming you don't have to work then) and somehow you have to squeeze in time to do chores, cook, go grocery shopping, and hopefully get out of the house and have at least a tiny bit of actual social life (even if that just means playing some D&D with your buds).
    In any event, if everyone followed your suggestion, then nobody would work the shitty jobs (which means most of them) and therefore the whole system would collapse because it's not based on what people feel like doing, but rather what people will accept to do for a certain amount of compensation.

  • by skelly33 ( 891182 ) on Friday July 11, 2008 @09:58PM (#24160803)
    Amen. Interviewees who make it to my top three are the ones who are passionate about something that they've done on their own which is as technically demanding as the position. I specifically look for bright people who are self motivated - you can't get more self motivated than doing the stuff on your own free time. That does not mean a pale-faced social recluse who never leaves the basement.
  • Re:Be smart (Score:5, Insightful)

    by ed.markovich ( 1118143 ) on Friday July 11, 2008 @09:59PM (#24160809) Homepage
    Funny, but it's a good point. How do the employers know that the candidate is showing his/her own code? Even if they are, most likely the code for show will be polished to perfection over however long that takes, and probably not representative of their code while working on a deadline. Far better to give a test during the interview and have your best engineers present to evaluate the candidate There would still be value in this. It's understood that your code would be better than your average code in this case but that's ok. If the code submitted is good, it will mean one or more of the following: 1. You know what good code looks like. 2. You understand that the job application process is important and took the time to make code good. 3. You possibly gave it to someone else to review. Trust me, it's rare enough that someone would be good enough to do that. Most people would submit crap even given all the time in the world to polish it off. The ones who manage to submit a good sample would still form a better candidate pool, no matter what technique they used.
  • by Anonymous Coward on Friday July 11, 2008 @10:08PM (#24160865)

    From reading the other posts here one can quickly surmise that the other techniques for evaluating a candidate's coding skills have serious drawbacks: legality, ethics, time commitment, relevance, etc. The whiteboard coding method is free of those drawbacks. Yes, the candidate might be hindered by nervousness, but that is always a factor in interviews. As for firing up emacs on a laptop, that doesn't seem conducive to a give-and-take discussion. Even if a large monitor is available, it would be awkward and invasive for the interviewers to take over the candidate's keyboard to demonstrate a point.

    Maybe whiteboard coding is something you can simulate and practice at home with a pen and paper, conducting one side of an imaginary conversation with an interviewer.

  • by Mongoose Disciple ( 722373 ) on Friday July 11, 2008 @10:19PM (#24160951)

    If you don't love writing code so much that you want to do it when you get home, maybe you just shouldn't be writing code.

    I disagree here.

    I'm a coder. Sure, I have shitty projects or shitty clients sometimes, but overall, I love my job. It's great that I get paid to do something I enjoy and am good at.

    But, you know? A lot of the time, 40 or so hours of it in a week is enough. It's possible to love something in moderation and have room for other interests in your life. I wouldn't want to do any of the other things I enjoy for more than about a third of my waking time in a week, either.

  • by haroldag ( 962342 ) on Friday July 11, 2008 @10:29PM (#24161041)

    Ya know, I went out to a bar once and saw this beautiful blue-eyed brunette. Got her a few drinks and one thing led to another...she did not ask me to enumerate which chicks i've been with - she just expected me to make her a woman...

    you get the picture

    Being asked for code samples in an interview is bullshit. It has never happened to me.

    Go find another employer, one who will discuss previous projects, pitfalls, solutions, science, the passion behind what you like to do and what you'd bring to the organization, stuff that demonstrates your ability and skill. No need to kiss and tell.

  • by adamkennedy ( 121032 ) <adamk@c[ ].org ['pan' in gap]> on Friday July 11, 2008 @10:31PM (#24161055) Homepage

    On behalf of the people that are the ones asking for code samples, your response answers 50% of what the employer is looking for.

    We're not necesarily looking for someone with tons of open source experience, or who does lots of other work at home.

    But for the sort of positions where you DO ask for sample code, you are intentionally looking for people who ARE programmers, not that just DO programming.

    For high level positions, I generally ask for 5,000 lines.

    The really top notch people are going to have SOMETHING they can provide. This could be work on an open source project, or some insane project they only do at home, or even some shareware tool they make some money off on the side.

    But there's generally something.

    If you don't have the code, then the question is no longer one about assesing your programming skills, it's now about assessing your personality and profressionalism. Will you make excuses? Will you write something just for the request? Will you offer to program something?

    I've even had one guy who came to us from a bank that responded, "I can't show you the code, but I could give you the header files and documentation?" (he was hired)

    Since you obviously don't have the code, bear this mind.

    In India (at least until recently) it's fairly easy to hire people cheaply that can't afford or doesn't use a computer at home, for whom programming is something they were only trained for an just do at Their Job.

    If someone is asking for code samples, at that point they DON'T want people of that calibre. They want GOOD people that they can give responsibility to and trust the decisions of safely.

    Your job is to demonstrate that.

  • Re:Be smart (Score:5, Insightful)

    by Anonymous Coward on Friday July 11, 2008 @10:38PM (#24161105)
    How do you know that those other sites had not copied your interviewees code?
  • Re:Be smart (Score:5, Insightful)

    by castoridae ( 453809 ) on Friday July 11, 2008 @10:41PM (#24161125)

    Which is how any real developer on the job worth his salt would code! I don't want any of my developers wasting their time writing code that they could find that easily on the web. Their job is to integrate and polish that code (same thing they did for the interview) and to write only code that is really unique and proprietary.

    (Obviously in practice there are a lot of cases where its just faster to write something that to find the exact right code scavenging the web, but I think the theory stands)

  • by corbettw ( 214229 ) on Friday July 11, 2008 @10:43PM (#24161145) Journal

    If you haven't written anything interesting outside of work, and you're completely uninterested in doing so, then this automatically drops you down a notch among those that I would hire.

    So in other words, you don't hire guys with wives, children, dogs, bowling teams, dart tournaments, Warhammer league nights, wine clubs, poker buddies, or who are going to night school to finish their degree? Because you're missing out on some really great employees when you do that.

  • Re:Be smart (Score:2, Insightful)

    by Anonymous Coward on Friday July 11, 2008 @10:51PM (#24161183)

    Maybe they could... ask you to explain part of it?

  • Re:Be smart (Score:5, Insightful)

    by Dragonslicer ( 991472 ) on Friday July 11, 2008 @10:56PM (#24161217)
    That's why you give tests that are short (maybe ~10 lines of code) that demonstrate reasoning and problem solving. You also don't necessarily expect perfect syntax, depending on the level of skill in the particular language you're looking for.
  • Comment removed (Score:3, Insightful)

    by account_deleted ( 4530225 ) on Friday July 11, 2008 @11:17PM (#24161383)
    Comment removed based on user account deletion
  • by torokun ( 148213 ) on Friday July 11, 2008 @11:24PM (#24161417) Homepage

    Well, I have to call BS on the anti-whiteboarders. A good coder can think out some code and write it on a whiteboard. I'm not saying you don't erase or correct anything, but railing against it is just admitting your limitations, and I don't think most good coders would balk at this.

    People have been coding on boards and interviewing in that fashion for years and years.

  • by Keeper ( 56691 ) on Friday July 11, 2008 @11:29PM (#24161467)

    The correctness of the code you write in an interview on a whiteboard isn't what you are being judged on. Rather, the interviewer is trying to gather insight into your problem solving skills (or at least that's what I'm looking for when I interview someone).

    In a problem solving exercise like this, I don't care if you miss a semicolon, put a bracket in the wrong place, or can't remember the exact name/argument list for a function (though depending on what the problem is I'll probably end up telling you the function isn't available). I can teach a smart person how to write better code, but I can't teach someone to be smart.

    Some of the basic things I ask myself about the whiteboard question after the interview is over include:

    - did you ask questions about the requirements?
    - what did you do if I give you a requirement that contradicts an assumption or previously defined requirement?
    - did you just start writing some code or did you take some time to consider multiple solutions?
    - if I asked you to come up with an alternative/better way to solve the problem, were you able to?
    - if not, and I describe an alternate way to solve the problem, are you able to implement it?
    - did your solution consider boundary conditions?
    - does your solution scale?
    - do you show a fundamental understanding of programming theory?
    - can you communicate your ideas and solution effectively?

    The next time you get a whiteboard question, remember that correctness isn't necessarily the most important criteria -- it's the problem solving that matters. The best way to succeed with this type of problem is to think out loud and interact with the interviewer.

    As a side note, getting a good back and forth going with the interviewer is also the easiest way to "forget" that you are nervious, and you might relax enough to have a bit of fun...

  • Re:This is BS. (Score:3, Insightful)

    by Anonymous Brave Guy ( 457657 ) on Friday July 11, 2008 @11:30PM (#24161473)

    You'll probably get away with it, but you are in fact violating the contract you signed.

    And worse, you have just demonstrated to a potential future employer that you are untrustworthy in this respect. If you were a bank manager, would you hire someone to handle cash when they had a criminal record for fraud or theft?

  • Re:Be smart (Score:5, Insightful)

    by PietjeJantje ( 917584 ) on Friday July 11, 2008 @11:38PM (#24161515)
    Sure, but that's another issue alltogether which is true for some cases and not true for others.

    The question was "show me some of your code, something you programmed", not "show me some of the code you reused, with attributions taken away and your name on top" to show off your time saving skills. Also, the guys who do this, they're not exactly..uhm..code polishers if you catch my drift.
  • by TheGratefulNet ( 143330 ) on Friday July 11, 2008 @11:44PM (#24161555)

    It's much more informative to me to see you correct your bugs based on visual review of the code rather than because the compiler or a test-run drove you to it.

    I like division of labor. let the machine catch a lot of what *it* can, and I'll do the rest. it works out fine for me. no, I'm not saying "if it builds, ship it" (lol) but I am saying that I don't desk check what the compiler can more quickly and thoroughly catch.

    compiling is interactive, today, its so fast. I can use the realtime error output of a compiler, quickly do a fix in the source and retrigger another compile. I can have it inch my way forward and not have to spend a lot of effort if its not necessary.

    is that a crutch? sort of. is it a bad thing? I don't think so. tools are tools.

    The whole point is to see what you can do based on your knowledge alone, w/o trial and error afforded by compilation.

    sometimes, the brainless stuff is BETTER done by trial and recompilation. seriously! I like to meter out my brainpower. as you get older, you learn that not every problem needs vigorous brain effort. you learn you need to conserve your effort to cut down on burn-out. inevitable burn-out. whatever you can do to keep the mundane stuff from burning you out, that's a good thing (imho).

  • by Anonymous Coward on Friday July 11, 2008 @11:49PM (#24161591)

    Wow. You should get out more.

  • by Free the Cowards ( 1280296 ) on Friday July 11, 2008 @11:58PM (#24161637)

    That "emotional/philosophical bullshit" is often what causes a programmer to choose the technique that will scale enough to still be viable in a year, rather than the easier one that will fall down in a month. It's often what causes a programmer to write clear code for the next guy, instead of spaghetti that's easy to turn out now.

  • by SilentBob0727 ( 974090 ) on Saturday July 12, 2008 @12:10AM (#24161713) Homepage

    That's great if you want programmers with absolutely zero insight into the code they're asked to write. So many managers complain that they ask their developers to do a "simple task" and it doesn't get done because the developers get "uppity". Get a clue. We wouldn't be "uppity" if the task you were asking us to perform truly were simple. Usually what you are asking us to do is impossible, impractical, will probably break something you previously asked us to do, or is vague and we need more information. But you don't want to be bothered with pesky details. No, developers that hate their jobs so much that they'll churn out shitty code without a word are a stronger asset than developers that will alert you to potential problems with their "emotional/philosophical bullshit".

    Look, programming simply isn't assembly-line work, and managers like you just don't get that. It takes insight, wisdom, planning, years of experience, and a love of the craft to code well. It's NOT a nose-to-the-grindstone, clock-in-clock-out, don't-disturb-the-water skill, or they'd have built robots to do it already.

  • by XopherMV ( 575514 ) * on Saturday July 12, 2008 @12:21AM (#24161769) Journal
    Writing code on a whiteboard under the pressure and limited time constraints of an interview, without tools, without resources, and without a well-thought design is the opposite of how good developers actually develop code.

    You're not weeding out candidates who "exaggerate" about their skills. You're removing the engineers who haven't recently seen the problem you're asking.

    Further, with all the various knowledge of technology required to do software engineering from SQL to ORM to business code to frameworks to front-end code to test code to documentation to design and architecture, having your main requirement be the ability to implement a single algorithm from CS 101 is stupid. Coming up with a new algorithm is a miniscule part of an engineering position. If you're weeding out candidates because of that, then you're the moron.
  • by kidgenius ( 704962 ) on Saturday July 12, 2008 @12:30AM (#24161827)
    You're not asking someone to write perfect, syntactical code. You're just asking them to do some pseudo code on the board. See how their mind thinks. See how they develop algorithms. What paths do they follow. Writing syntax perfect code isn't what's important. Thought processes are.
  • Do you have any idea how many times I've said that on this site (and how many times I've been told how wrong I was by people who, in my opinion, don't actually work anywhere)? lol

    On a side note, I'd *love* to find a sane company like that. A place that wants me to have a healthy work/life balance? Yes, please. Those are far too freaking rare from what I've seen.

  • Re:Open source (Score:2, Insightful)

    by knavel ( 1155875 ) on Saturday July 12, 2008 @01:01AM (#24161965) Homepage
    Keep in mind, you don't just pull an open source project out of your ass, you first must find a need, before you can fill it. This is not always so obvious or easy a thing for someone to do.

    Not to mention, some people legitimately don't have the spare time. I myself was lucky that I worked on several open source projects here and there /before/ I started developing full-time, because now that I spend all day doing it, the last thing I want to do is spend all night doing it just to pad my resume. I still maintain my existing projects, but I don't go looking for more work.

    If all I did was code 24 hours a day, I'd probably snap and murder my wife...
  • by XopherMV ( 575514 ) * on Saturday July 12, 2008 @01:14AM (#24162023) Journal
    The idea that you can "see how their mind thinks" is a load of crap. Engineers are too used to dealing with machines. They are the absolute worst when it comes to interacting with other people, even though they often think otherwise, like you. The concept that you can read the lifetime of someone's development experience in a 5-minute exercise is completely ludicrous. Psychologists are far better at reading peoples' minds than you and they can't do it that fast, especially for the level of accuracy you seem to claim.

    That is certainly one reason why there are so many "shitty engineers" out there despite the fact that these engineers have had jobs giving them years of experience, and yet each company out there hires the "best and the brightest".
  • by toddestan ( 632714 ) on Saturday July 12, 2008 @01:23AM (#24162059)

    Even if you love writing code, do you also love optomizing code, debugging code, troubleshooting, checking for corner cases, and all that stuff you would want to do to a piece of code before you would consider it presentable as a code sample?

  • by Anonymous Coward on Saturday July 12, 2008 @01:40AM (#24162123)

    A lot of people are really smug and say "Sorry my NDA won't let me". This is a clever way to get people to admit they never code anything for fun, and as far as I'm concerned, that is a *very* damning statement about an engineer.

    This is crazy. I've worked with some incredible engineers in the past. One guy designed satellites for the US government (he won't say what sort, you take a guess). Another one, among other things, designed the command unit for one of the Pioneer Venus landers as well as the Ku-band antenna targeting system for the space shuttle. Yet another was a member of the X Consortium responsible for the initial implementation of international language support and worked on the original Xlib documentation. You're running his code right now.

    You would not catch any of these men outside of work writing code, at least back when they were working. Two out of the three are now retired millionaires. having founded and grown a company to great success. Yep, true "failures" there. The third is gearing up for an entire summer of mountaineering.

    What I learned from these three men was that life is too important and wonderful to waste on any one thing. You have what you are good at -- in this case, programming and electrical engineering. You can also be incredibly passionate about this. You also have your other passions. You also have your family and friends.

    I do write code from time to time outside of work, for fun. But not every good programmer does. How would you apply your arguments to civil engineering, for instance? Do transportation engineers build roadbeds in their back yards on the weekends? If not, would you consider these people poor engineers?

    To be hypothetical, if I was a hiring manager I would probably ask if a person wrote code outside of work, and to briefly describe it. If they said they never did such a thing, I'd ask what they DO outside of work. I certainly wouldn't want somebody who just sat on their ass watching TV every evening, but if I heard that they spent their spare time studying the chemistry of wine, or hybridizing tomato plants, or some other interesting thing, I'd be happy.

    If you want to see what somebody's code looks like, provide them with a problem and ask them to solve it.

  • Re:Open source (Score:4, Insightful)

    by BrynM ( 217883 ) * on Saturday July 12, 2008 @03:17AM (#24162457) Homepage Journal

    Work on an open-source project, and use that code.

    I do a related type of thing. I write a stand-alone tool to solve one of my repetitive problems every so often and OSS it. If the code belongs to my employer in any way, I ask them about it as I'm developing the tool. Usually the small bits of maintenance on the tool done by the community is worth it for an employer (they can have my attention elsewhere and the tool gets a small level of free support or bug reports). I have yet to hold a position where I was not allowed to do this when I have asked for it. I mention the strategy at every good interview I have. I have found that potential employers are attracted to someone who can write and spin-off such things.

  • by Splab ( 574204 ) on Saturday July 12, 2008 @03:35AM (#24162521)

    You speculate that they turned down your application because it was too good?

    So you didn't actually ask why they turned you down? You just sit there with a grudge, making most likely false assumptions. Smart move.

    Ever crossed your mind that they might have found someone just as good, but with, perhaps more experience? Or asking less pay?

  • Re:Be smart (Score:4, Insightful)

    by Anonymous Coward on Saturday July 12, 2008 @04:32AM (#24162729)

    It is important to ask yourself as the interviewer, "what am I trying to learn by asking this question?"

    I think the naive answer to that question for an algorithms question is "I'm looking for good server-side code."

    No, I prefer that the candidate has not looked at algorithms problems in some time. What I'm looking for by asking these supposedly useless problems is:
      - the ability to write rudimentary code
      - problem solving
      - how well can I work with this person solving a problem to which they may not know the answer
      - is the solution direct or did they jump through unnecessary hoops
      - or if they jumper through hoops did they identify that they'd like to revisit and refactor the code
      - how well to the take to help, hints, and prodding? offended, reasonable, push-over?
      - can they write readable code that follows coding standards (I've had candidates that don't even follow they're own coding standards in the same block of code, that's just sloppy)

    In the end, it almost doesn't matter if they solve the problem. I'm more interested in how they attempt the solution.

  • by Antique Geekmeister ( 740220 ) on Saturday July 12, 2008 @04:33AM (#24162741)

    There are thousands of useful coding projnects over at Sourceforge: pick one or two that relate to tools you use, and help update or debug them. Post patches, and you'll have it online there as a matter of public record. If you management doesn't want you to publish such tools, gently steer them to the details of GPL licenses: GPL code is particularly good for this. Perl modules are particularly good for this, published over at CPAN.

    At my last job interview, I was able to point to 3 products that they used that I'd contributed to at least 5 years previously, and one product they were contemplating using that I pointed them to bug fixes I'd published.

  • Re:Be smart (Score:3, Insightful)

    by forgotten_my_nick ( 802929 ) on Saturday July 12, 2008 @04:57AM (#24162843)

    "I don't want any of my developers wasting their time writing code that they could find that easily on the web."

    Your opening yourself for serious litigation issues if your developers for your application are just nicking code from the net. Finding code to learn how to do something is different to copying code verbatim.

    SCO vs IBM went the way it did because IBM legal are strict on what code goes into applications and its history.

  • Re:Be smart (Score:3, Insightful)

    by lgw ( 121541 ) on Saturday July 12, 2008 @05:03AM (#24162873) Journal

    Microsoft once hired top-tier programmers, and their reputation for skill in interviewing dates from that time. They now have average programmers and ask the usual stupid questions.

    For a C/C++ programmer, basic linked list and string problems are needed to ensure the candidate actually knows how to use pointers, but I don't think Microsoft does any C/C++ programming outside the kernel team any more, which makes such questions even more ridiculous.

  • Re:Be smart (Score:4, Insightful)

    by lgw ( 121541 ) on Saturday July 12, 2008 @05:14AM (#24162905) Journal

    It is important to ask yourself as the interviewer, "what am I trying to learn by asking this question?"

    I think the naive answer to that question for an algorithms question is "I'm looking for good server-side code."

    No, I prefer that the candidate has not looked at algorithms problems in some time. What I'm looking for by asking these supposedly useless problems is:
        - the ability to write rudimentary code
        - problem solving
        - how well can I work with this person solving a problem to which they may not know the answer
        - is the solution direct or did they jump through unnecessary hoops
        - or if they jumper through hoops did they identify that they'd like to revisit and refactor the code
        - how well to the take to help, hints, and prodding? offended, reasonable, push-over?
        - can they write readable code that follows coding standards (I've had candidates that don't even follow they're own coding standards in the same block of code, that's just sloppy)

    In the end, it almost doesn't matter if they solve the problem. I'm more interested in how they attempt the solution.

    Giving the AC comment a boost - whether an algorithm question is silly or not depends on what the interviewer is actually looking for.

    I ask an algorithm quetsion that just about everyone figures out, but most take about 30 minutes to work through all of my related questions. Obviously, getting the answer isn't the filter here, it's how well do we work together solving a problem in a stressful situation. How much initiative does the candidate take, and how easily does he see/admit it when he's wrong.

    The guys who go down some rat hole and can't admit they're wrong, even in an interview with the interviewer hinting strongly that this is the worng direction, are the worst sort of asshole to work with, and it's worth the time just to screen those guys out.

    But really I'm mostly asking to see what part of the problem the candidate spends his time on - inexperienced guys spend time talking about the coding details, more senior guys on exploring what problem I *really* want them to solve, and top-notch guys on ensuring their solution is scalable and versatile (and we spend most of the time discussing how you evaluate the scalability of a solution, what actually matters to performance in the real world, etc).

  • by remitaylor ( 884490 ) on Sunday July 13, 2008 @06:13AM (#24171169)

    Make an open source project or open source one of your current side projects. Or contribute to an existing project.

    Direct them to the projects' websites and/or online source code browser.

    If someone wanted to see my code, I'd just send them to my git repo with many of my open source side projects.

    If you're a coder and you don't have side projects ... you're not a coder :P

An authority is a person who can tell you more about something than you really care to know.

Working...