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?"
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...
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.
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]
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.
Open Source (Score:3, Interesting)
Make sure you contribute at least some of your time to open source projects. That you can show.
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:Sample Code (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 skills, that's good because really, what does knowing how to solve a maze show other than you can pass algorithms 101?
After a couple more rounds like this, with ever more abstract and arbitrary issues imposed, (like: "don't use exceptions that way, it's bad style" when I used them in a way that's common in both the libraries and the literature for that language) it finally struck me that these guys weren't looking for someone who knew how to solve a particular problem, they were looking to find someone who would solve the problem in exactly the same way they'd solve it. At that point I just blew off the rest of the interview and every time they raised an objection, I just responded, "yes, that's one way to do it, but not the only or necessarily the best" while changing my solution to match theirs.
I'm glad they didn't hire me though, I could sort of tell when I was sitting in the waiting area until well past the time they said they interview started in their offices in a soulless corporate office park that it was a soul-draining company.
Oh, and it's "shoot holes IN".
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.
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.
My code samples (Score:2, Interesting)
I interview quite a lot. I used to ask people if they'd worked on open source projects so I could see examples of their code. Not one person I interviewed had contributed to an open source project. So I came up with my own code samples. I picked some code from Sun, an example from one of the O'Reilly books, and one more from the web. I ask candidates to read the code, tell me what it does, and what would they do to make it better. These are short code samples, all three print out on a single sheet of letter-size paper. This simple test takes about half an hour to talk through, and is surprisingly revealing about the skill level and knowledge of the language.
Re:brainfuck? (Score:5, Interesting)
Yeah! And I always liked Tupper's self-referential formula: http://mathworld.wolfram.com/TuppersSelf-ReferentialFormula.html [wolfram.com]
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:Show some confidence - don't wear a suit to the (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 coast (where I grew up and spent my first 30 yrs) - but out here, at least back in the dot-com era - it was perfectly fine. perfectly fine.
Certification Code... (Score:2, Interesting)
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:Good Point (Score:1, Interesting)
I'm one-up-ing you :-), and venting.
I was hired doing an IT job where my employer (a very large IT company, you definitely know it's name) deny my existence. Yeah, I checked. I pretended to be a prospective employer checking my work experience.
The job was very important. Very important. I don't know how else to emphasize the importance without telling anything. We were accompanied by bodyguards to protect our lives.
Anyway, it remains a permanent hole in my work experience.. I have this experience and knowledge but I can only share them with limited people.
It's really nice that in slashdot I can post anonymously.
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: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 they purchased from me."
Re:Ask for a test problem (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 mater, I emailed the people in charge and informed them of the shady practices of the company. They were basically hoping to sucker free work out of recent grads or prospective grads that they hoped wouldn't know better.
It may not be extremely common, but it does happen.
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: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:1, Interesting)
I remember this discussion the first time it happened in the 1990s. Back then, all you had in the language was the Vector and it was brutally synchronized to boot. Over the years, the language slowly but surely "devolved" to include more primitive, yet higher performing collection types. At the same time a formalization evolved around generalizations of the notion of collections which made them much more powerful.
So I'd rephrase your advice a little: "Anyone implementing linked lists in Java should be fired, or put in charge of JDK 1.8"