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?"
Be smart (Score:5, Funny)
what am I supposed to show them?
Someone else's code
Re:Be smart (Score:5, Insightful)
Re: (Score:3, Informative)
Re:Be smart (Score:5, Insightful)
Re:Be smart (Score:5, Insightful)
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)
Re:Be smart (Score:5, Insightful)
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.
Re: (Score:3, Insightful)
"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:5, Insightful)
Re:Be smart (Score:5, Insightful)
Re:Be smart (Score:5, Interesting)
What would asking those questions tell the interviewer anyway? Almost nothing. The strength of the engineer's ability to create an algorithm does not indicate their ability to do the job. Why? Because creating algorithms is a miniscule part of the job with all the other technologies currently being used.
Take the server-side Java example. An engineer needs to know how to put together a SQL script, Hibernate XML, Java business class, JUnit test, Struts entry, and JSP page with JSTL code. Add to that the ability to document in Word and Visio. Add to that the ability to create high-level architecture. The interview question to implement quicksort has no bearing on the job, particularly when that solution can be looked up in less than a minute anyway.
Re:Be smart (Score:5, Interesting)
Last time I interviewed, Intuit and Microsoft mostly asked me ridiculous problems like string word reversals and such, as if I had the C string library committed to memory. I was particularly amused with the Microsoft questions because I had to write a replacement for their CString library four years earlier because it didn't handle DBCS well at the time.
nVidia asked me higher level problems that required much more thought, and was actual problem solving rather than how recently I had used the particular library that the interviewer was working on that day. I wasn't really surprised, but was somewhat amused when I received an offer from nVidia, but not from MS or Intuit.
I ended up taking a better offer elsewhere, but I found the difference in interview styles very striking.
Re: (Score:3, Insightful)
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:5, Interesting)
I refuse to comply with interview bullshit. I push back when asked to do things that I think are ridiculous, and have on occasion walked out. It's harsh, but the only way that they'll learn... or at least the only way to keep your self-respect.
Hasn't cost me anything either. I was voluntarily unemployed once for a two-week period. Other than that, 28 years fully employed. So don't assume you have to put up with that crap in order to get a job.
Re:Be smart (Score:4, Insightful)
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.
Re:Be smart (Score:4, Insightful)
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).
Re:journey vs destination (Score:4, Interesting)
During an interview a couple of years ago, the candidate was stunned when I said that I didn't have an answer to the problem, and that we'd solve it together. So I explained, "Son, life doesn't come with a User Manual, Reference Guide, or more importantly, an Answer Key in the back." I think he completely missed the point, and unsurprisingly, had little in the way of problem solving skills. Reminds me of a line in Men in Black - "Gentlemen, congratulations. You're everything we've come to expect from years of government training."
When I came out of college, I went on a particularly brutal interview. One section involved critical timing paths (I'm an EE,) and the interviewer tossed a simple schematic on the whiteboard. I looked at it for about 5 seconds, and told him what it did. He paused and asked, "Are you sure?" His tone clearly indicated that I was incorrect. I looked again, and stood my ground. I further pointed out that he had a potential setup/hold timing violation depending on what parts he was using. I spent over an hour with this guy, and he asked some seriously challenging questions. I found out after the fact that he was notorious for chewing-up and spitting-out candidates, and that his interviews rarely lasted more than 20 minutes (he was effectively the CTO, so time mattered.)
The lesson here is that a proper interview is geared toward making sure you have both technical chops and people skills that are compatible with the company. I can teach you new tech stuff
Re:Be smart (Score:5, Interesting)
I have found that asking interviewees to do some (simple) coding tasks has been useful, but it's not necessarily about whether they succeed or fail at the task.
We set up a computer running Linux and projector in the room and asked candidates to write code. Many of the candidates turn out to have no idea how to use the Linux command line, or don't know what a man page is, or how to run the compiler (and this is after extensive screening of their CVs already for a job which specifies Linux skills). This becomes very obvious in the practical test, and such people can be quickly rejected.
Without the practical test we'd have to rely on CVs giving reliable answers to these things ["10 years experience with Linux" etc] and on asking the candidates what they know and relying on honest answers back.
Rich.
Re: (Score:3, Insightful)
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 :)
Re:Be smart (Score:5, Insightful)
Re: (Score:3, Interesting)
When interviewing someone for a software position, I have always used this question as an ethics question. If the person voluntarily shows me their code from a company they have worked with, they are rejected because I cannot trust them with the code of the company I work for. My response to those who ask me about my coding is to say, "I have no problem showing you the coding I have done for others. If you need to, I will give you the phone number of that past company and you can ask them to see the code
OT - small point (Score:3, Informative)
Chaff is the husk around a grass seed. Wheat is what's separated from chaff, not weed. The chaff is the bad part.
Good Point (Score:5, Funny)
Like the other day, i was interviewing for a job and i said, "Well you know i did all the coding for Amazon.com right? but you see i can't show any of it to you because of the non-disclosure agreement"
For some reason i still haven't gotten a call back...
Re:Good Point (Score:5, Funny)
Re:Good Point (Score:5, Funny)
That is so going on my resume within the next 5 minutes. Thanks for the tip!
Re: (Score:3, Funny)
brainfuck? (Score:4, Funny)
Just translate everything to brainfuck, and send that sourcecode. Problem solved.
(Some people claim that this brilliant---nay, genius---solution will just make things harder for you, but you can never tell until you try, right?)
Re: (Score:2, Insightful)
Please don't mod up, I'm just stealing the reference from david.given [slashdot.org]
Re:brainfuck? (Score:4, Insightful)
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:brainfuck? (Score:5, Funny)
If you really want to throw them in a tizzy, do it in Whitespace [wikipedia.org] (BF implemented using spaces, tabs, and carriage returns.)
Of course, turn it in as a printed copy.
Re:brainfuck? (Score:5, Interesting)
Yeah! And I always liked Tupper's self-referential formula: http://mathworld.wolfram.com/TuppersSelf-ReferentialFormula.html [wolfram.com]
Ask for a test problem (Score:5, Informative)
I usually explain that various NDAs prevent me from disclosing code I've written of significance, and suggest that I be asked to complete a programming exercise.
Most employers have a set at the ready these days, and I usually respond with the 1 hour answer and the 1 day answer, the later showing an evolution of the former, with polish and usually a more generic solution.
Re:Ask for a test problem (Score:5, Interesting)
just tell them the request in not appropriate.
since it ISN'T! would THEY like you to show work you did for them, later on, to OTHER employers?
maybe that's the best answer you can give.
[soap]
the next programming test I take, I'm insisting I bring a laptop, have emacs and gcc at my disposal. I mean, I do NOT write code on whiteboards with markers in my real job, why should I have to put up with that in an interview? I am more than happy to sit down at emacs, have my indent checker, my syntax-colorizer extensions, have my tools at hand (like a normal work day would be like) and THEN see if I can solve the quiz or routine. but in all my years, I've never seen any employer show that level of wisdom in the interview process. sad, as writing on whiteboards is not something everyone is good at and I hate being judged by such artificial criteria. gimme emacs and lemme show you how I really edit/create code in real life. if I fail that, then I'll accept whatever decision you make.
[/soap]
Re:Ask for a test problem (Score:5, Insightful)
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.
Dress and accessorize for your interview (Score:5, Funny)
Show some confidence - don't wear a suit to the interview.
A good-quality shirt if you're a PC, a turtleneck if you're a mac, a T-shirt if you're linux, or a leather jacket if you're *bsd.
Slacks if you're a PC, black jeans if you're a mac or *bsd, blue jeans if you're linux.
Dress shoes if you're a PC, loafers if you're a mac, runners if you're linux, boots or sandals if you're *bsd.
No hat if you're a PC, a kepi if you're a mac, a ballcap if you're linux (a red one if you're Fedora/RHEL), and a shaved head if you're *bsd.
A briefcase if you're a PC, a leather portfolio if you're a mac, a softsider if you're linux, and a pull-behind carrying a 4u server if you're *bsd.
A crackberry if you're a PC, an iPhone if you're a mac, any flip-phone if you're linux, Chuck Norris if you're *bsd.
Your resume in Word if you're a PC, as a video clip if you're a mac, in openoffice if you're linux, and 7-bit clean ASCII if you're *bsd.
Hide your Zune if you're a PC, subtly show off your iPod if you're a mac, wow them with streamripper if you're linux, and run a script to make the sound of the drive heads seeking play "Take this job and shove it!" if you're *bsd.
A business card if you're a PC, a mini-dvd if you're a mac, a bootable distro dvd with customized splash screen, borwser, etc., if you're linux, your phone number and email address on the back of a beer coaster if you're *bsd.
Coca-cola if you're a PC, bottled water if you're a mac, real beer (not that 5% piss) if you're linux, shots if you're *bsd.
Show some confidence - don't wear a suit to the (Score:4, Informative)
interview.
A good-quality shirt if you're a PC, a turtleneck if you're a mac, a T-shirt if you're linux, or a leather jacket if you're *bsd.
You left out a hemp safari shirt.
Slacks if you're a PC, black jeans if you're a mac or *bsd, blue jeans if you're linux.
Cargo shorts.
No hat if you're a PC, a kepi if you're a mac, a ballcap if you're linux (a red one if you're Fedora/RHEL), and a shaved head if you're *bsd.
Beret.
A briefcase if you're a PC, a leather portfolio if you're a mac, a softsider if you're linux, and a pull-behind carrying a 4u server if you're *bsd.
A backpack.
Coca-cola if you're a PC, bottled water if you're a mac, real beer (not that 5% piss) if you're linux, shots if you're *bsd.
Camelback of fruit juice and bottle of homebrew.
Falcon
Re: (Score:3, Interesting)
(ob disc: I am in the silicon valley area).
back in the pre-y2k bust, I do remember going to interviews in my shorts, sandals and a tee shirt (often tie dye). and back then, it 'worked' - at least for the companies I tried for. back then (is it still true?) companies liked a rebel and one who was good at his trade, had a good amount of experience in the field and was confident enough without being over the top. shorts and sandals actually helped with all of that ;)
I would never ever try that on the east c
Re:Dress and accessorize for your interview (Score:5, Funny)
It's funny that you mention that because I've noticed a similar trend in IT where I am.
Wear a tie, and you're generally not going to be taken seriously no matter how good you are. The best approach here seems to be a polo, nice sweater, or button up depending on the weather, slacks or khakis (occasionally jeans, depending on the place), and presentable shoes (nothing too fancy. Half the time, plain black tennis shoes work perfectly).
I used to do the suit and tie thing because that's what everyone tells you to do and because I occasionally like them (yes, I'm weird. It's what I get for some of the things in my past.).
Now I just walk in wearing a nice polo shirt and khakis and get taken a heck of a lot more seriously because I "look more like a technical person". The irony is that the change came because I got tired of getting dressed up just to end up getting jerked around, so I started walking into interviews wearing what I do on an average day.
I've occasionally wondered what would happen if I walked into an interview in medieval style clothing. lol
Re:Ask for a test problem (Score:4, Insightful)
This was not done to torture candidates (or the interviewers for that matter). We were trying to find out things like the following:
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.
Re:Ask for a test problem (Score:5, Insightful)
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.
Re: (Score:3, Insightful)
Re:Ask for a test problem (Score:4, Insightful)
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".
Some won't actually mind... (Score:4, Informative)
would THEY like you to show work you did for them, later on, to OTHER employers?
Some company won't actually mind.
Not every single line of code a developper may write while working in a place is of utmost strategic importance and has to remain secret or otherwise the company will go bankrupt.
The developer should ask his/her supervisors for proper clearance to show some code that isn't a vital part for the company's survival on the market place. i.e.: Maybe you can't show the source code of the product the company is selling, but you can show the source code to tools you have developed to simplify your work.
In fact some places even authorize you to release such non-critical side project under open-source licenses.
Of course this is much easier when you work in a small company. If there are 10'000 developers in you company it's hard to check everyone's code for clearances.
...
Of course as other /.ers have said, the home projects are much better candidates to be shown in an interview.
Unless you work for a paranoid "sell your soul" companies which insist everything developer while under contract belongs, even home projects.
Re:Ask for a test problem (Score:5, Insightful)
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: (Score:3, Funny)
Pfff. vim's version has a much cleaner interface.
Re: (Score:3, Insightful)
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 o
Re:Ask for a test problem (Score:5, Insightful)
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.
Re: (Score:3, Interesting)
Don't bet on it. I've actually run into a company that tried to get me to design a site for them (as in actually for a client and not something test-like) as part of my "interview".
When I informed them that that wasn't going to happen, they started trying to convince me that it was an accepted method for deciding on candidates. When I informed them that I didn't work for free and that it certainly wasn't an industry accepted practice, they got rather furious.
Since it happened at a career fair for my alma
Open source (Score:5, Insightful)
Work on an open-source project, and use that code.
Re:Open source (Score:4, Insightful)
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:Open source (Score:4, Insightful)
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.
Re:Open source (Score:4, Insightful)
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.
Good example (Score:5, Insightful)
use educational examples (Score:5, Interesting)
i.e. for bash scripting:
give yourself some common tasks:
create scripts for them...
i.e. create a script to fetch updates and notify you via mail(or some other means) when they are downloaded and ready for installation.
create a script that analyzes log files(yes these things have all been done by many others and you can download them in tool-kits...but that's not the point)
create a script that updates other scripts dynamically based on what they find out...
Write an open source project (Score:2)
And this is why... (Score:5, Insightful)
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.
Re: (Score:2)
Of course it can go both ways... You might not be able to spend as much time polishing up the code to your side projects as you can on something you do all day long at work.
However, in the end, I think having side projects is extremely useful for exactly this purpose. (Probably extra points if its some open-source project that people actually use.)
jedi (Score:4, Funny)
If you don't write software at home... (Score:5, Insightful)
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.
Re:If you don't write software at home... (Score:5, Insightful)
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).
Re:If you don't write software at home... (Score:5, Insightful)
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.
Re: (Score:3, Insightful)
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.
Re:If you don't write software at home... (Score:4, Insightful)
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.
Re: (Score:3, Insightful)
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.
Re: (Score:3, Insightful)
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
Re:If you don't write software at home... (Score:4, Funny)
You know, you're right.
Incidentally, I'm looking for a job that includes reading scifi books, drinking diet soda, and driving sports cars. I don't have any code to show you, but to demonstrate my qualifications, I'd be happy to offer commentary on the books I've read, show you the mountain of empty cans in my recycle bin, and get the state to verify my clean driving record.
Re: (Score:3, Insightful)
Re:If you don't write software at home... (Score:5, Interesting)
Work to live, don't live to work.
I love programming. I really do. It's interesting, exciting and challenging.
But when I leave the office, I have a wife, a kid, a house and 2 pets. They need me, and I need them. And if I'm hiring & employing someone, I want to make sure that they're maintaining a good work/life balance and not burning themselves out doing just one thing.
My bosses & co-workers insist that I not stay late on a regular basis. They don't want me on-call (I told them I thought I needed a pager due to a system I support; they disagreed). When I'm on vacation, they yell at me if they find out I've been checking email or voicemail. When I leave the office each day, they want me living my own life outside the bounds of what my job description says.
And as a result my overall quality of life is far, far better than it was at my previous place of employment.
Re: (Score:3, Insightful)
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:If you don't write software at home... (Score:5, Insightful)
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.
Re: (Score:3, Insightful)
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?
Re: (Score:2, Insightful)
Re:If you don't write software at home... (Score:5, Interesting)
Oh please.
There are some of us that enjoy our jobs and the tasks we do there but have other interests outside of work. I'm a Sys Admin. It was my "dream job" from the time I took my first comp sci class. I love what I do, I love the challenges I am presented with. But I don't run my own Solaris boxes at home so that I can play around even more when I get off work. I have too many other interests; other things I enjoy doing. That doesn't make me bad at my job. In fact I think it protects me from a lot of the burnout that I see happen in I.T.
Re: (Score:3, Insightful)
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: (Score:3, Insightful)
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: (Score:3, Insightful)
Use basic CS test material (Score:5, Interesting)
Grab a couple computer science tests, some Knuth books, or ACM programming contest sheets.
Find a simple problem (one that'll take 10-30 minutes to code) and write it up nicely in a couple different languages. Use at least one OO language if you know one.
Discuss the projects you worked on, but tell them it was work for hire and stress that you respect the privacy of the other companies, but you brought other code samples for them to see.
Been there (Score:4, Informative)
I've been in that situation. My potential future employer asked to see some of my code. What I did was:
1) I directed them to some open-source code I'd written.
2) I told them that I could not show them the code I was working on at my current job, but I said they could ask my colleague about the quality of that code.
One good thing about 2) is that it also tells the future employer that you're not going to show *their* code around after you leave. Oh, and I got the job, although I chose to go to another company.
Samples not needed for experianced employees (Score:3, Interesting)
If you have been in the industry before and are looking to join a software company like M$ or others they will typically not ask for samples. If you get to the interview you will have to demonstrate in real time your skills.
It is a big red flag if a company asks for samples before hand. It usally indicates you are interviewing at non tech company or they have inferior managers whom can not weed out candidates well.
1000 lines of good code (Score:5, Funny)
I used to ask applicants for 1000 lines of C++ they were proud of. Sometimes you get something really beautiful. Something that's at least decently designed and looks reliable is essential.
I've been known to send such samples back with "Your first buffer overflow is on line 42. Thank you for your interest." I couldn't afford to deal with sloppy coders in a hard real time environment.
Re: (Score:3, Insightful)
You sir are an asshole.
Sample Code (Score:2, Funny)
Open Source (Score:3, Interesting)
Make sure you contribute at least some of your time to open source projects. That you can show.
Personal Projects? OSS Work? (Score:2)
Don't you people do code outside of work? What kind of "for the love of coding" programmer are you?
Admittedly, my personal project code is a wee bit dated (it's older than my children), but it's more current than my resume...
I've already done my share of "code samples," thx (Score:4, Insightful)
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.
Re: (Score:3, Informative)
In the first case, I went to town creating fully-commented, production-quality code complete with automated tests. It was more than they asked for. In that case, it didn't matter, I was turned down for the job. The solution was so damn good that I think they thought I copied it from the web, even though I had not.
In the second case, I produced code that looked more like a proof-of-concept. It worked and matched
Re: (Score:3, Insightful)
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?
Do some contract work (Score:4, Insightful)
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.
Ask (Score:3, Informative)
Periodically when you are working (long, long before you are looking for a new job) ask your supervisor if you can use a particular chunk of code as a code sample in your portfolio. Don't pick a mission-critical routine or something business-centric (those won't translate much into most job interviews anyway).
I've been doing that since my first programming dig and only been denied once.
Make sure you attribute the copyright and permission accordingly and keep the permission in a safe place (CYA).
OSCON (Score:4, Funny)
Go to OSCON this year, attend the sessions with Larry Wall, Guido van Rossum, Damien Conway, etc. Write down the code samples and then take those to the interview.
Why don't you have anything? (Score:5, Insightful)
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.
Make a portfolio (Score:3, Interesting)
For the last 4 or 5 years that I was programming for a living I maintained a portfolio. I wrote a small application (about 2000 lines of code). I followed my own personal process for implementing it. I kept the planning, specification and design artifacts (fairly lightweight since I prefer to do something similar to XP).
Then I chose a couple of interesting areas in the code and annotated them. I explained what I was doing, why I chose a particular design approach, some aspects of my personal coding style, etc, etc.
The whole thing took me a month or two of working on my own. Then a little bit of time to keep it up to date (based on what I continued to learn over the years). While it was a toy problem, I found the exercise extremely useful for my own personal development. And when I applied for jobs I gave a link to my portfolio on my resume. This gave people a really good idea of what they were getting if they were to hire me.
I highly recommend any programmer to do the same. It *is* a fair amount of work in the short term, but the benefits far outweigh the costs. It's not just about getting a job. It's also about really understanding your own personal style.
You don't. (Score:3, Informative)
Instead, show them an executable version (or video of one running) and give narration on how you managed to resolve certain issues, letting them see the results of your work. It's probably vague enough to prevent disclosing any major trade secrets and still gives some idea of your overall capabilities.
For added protection though, you might want to have your employer agree to let you have an executable version of any software you write (or at least, some form of pre-recorded clippings of the software in action using dummy information) for your portfolio beforehand.
Showing off actual code is definitely a bad idea for a number of reasons. First off, it's a huge breach of security as it could expose potential exploit point in the software. Next, it's obviously going to be a legal nightmare should that code show up somewhere you've been with it. Finally, code by itself just isn't that interesting to look at unless you can see it in action. It's unlikely the one's hiring you will be able to read and understand any code you show them, but they can probably recognize the benefits of your code through comparisons of it against something else that performs a similar function. If they see that the code is somehow faster or does a better job than the item it's compared with, it'd probably be good reason for anyone to consider hiring you on as a developer.
Work on GPL projects (Score:4, Insightful)
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.
If you want to show our stuff, suggest pairing (Score:3, Informative)
As a hiring manager I find preconceived code samples worthless. There is only one way to know if someone can code during an interview, and that is to pair program with him/her.
I use a technique I learned from Rob Mee at Pivotal Labs [pivotallabs.com]. I spend roughly an hour test driving a simple project with the interviewee that Rob specifically crafted to determine the capabilities of the candidate, from the basic level of competency up to that Rockstar ability to spot the elegant solution intuitively.
During an hour of pairing with someone you get a good idea of what they can do, much better than you can from reading pre-fabricated code samples or merely asking quiz questions (whether about stuff someone can memorize from a book or silly brain teasers).
Re: (Score:2, Insightful)
Re: (Score:3, Informative)
I've shown some good code to people, and they start saying whats wrong with it without knowing what it's about. For instance, I interviewed with some small startup (some 5 dudes coding in a studio), and I showed them some heavy ajax code, and they said it would be too slow for a high traffic site. I told them it was an internal application with high functionality, and he proceeded to show me a simple html page with no javascript and told me "see this is high performance". I think its just deceit when the
Re: (Score:3, Interesting)
I had something similar happen to me. The interview test question was worded "write a solution for find the exit path from a maze from any starting point". OK, college algorithms class stuff, I thought. I'm a bit rusty but I remember the general techniques.
As soon as I start throwing up code on the board they start adding conditions. It couldn't be a chunk of simple code that showed the algorithm, it had to also show good modularity and separation of concerns. Oh, I thought, so it's also a test of my design
Re: (Score:3, Funny)
Re:Strategy (Score:4, Informative)
I am corrected, Previously I responded that something was the dumbest post, but you win.
Really, do you think that you are so awesome that the crappy little code sample that you are showing me is going to blow my mind. Do you realize how unlikely it is that your sample code is even remotely related to the problem I am working on at that moment?
I want to see an example of what you have written in the past for a few reasons:
1. It shows me your style. Do you design before coding? this is usually evident by simple elegant solutions. An experienced programmer/engineer can tell alot from a small sample.
2. This is much more fair than me presenting you with some problem out of the blue. I am giving you as much time as you want to compose your solution. This is the audition part of the process.
3. I will be asking you questions about this example code to determine that it was in fact you who designed/wrote it, and to understand the thought process that you followed. This has 2 purposes.
a. I figure out if you are trying to bs me.
b. You get a chance to see what the caliber of your peers will be based upon the quality of my questions ( and I am working on the spot, without a net).
Interviewing should not be considered combat. I want to like you, and I want to hire you. I am asking 4-8 of my staff to take an hour out of their day to talk with you and see if you will be an asset to our organization.
A great interview is a conversation, not an interrogation. We both have something that the other wants and we are conversing to see if we are a mutual fit.
Re: (Score:3, Insightful)
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?