Slashdot Mirror
How To Show Code Samples?
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?"
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...
"Just Smile and Nod." --Huck
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.
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]
--
"It is now safe to switch off your computer."
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.
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.
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.
Yeah! And I always liked Tupper's self-referential formula: http://mathworld.wolfram.com/TuppersSelf-ReferentialFormula.html
On top of that, the in-interview tests are typically problems that are unrelated to the majority of the work out there. If the job is server-side Java, there is no point to asking the candidate to manually reorder Strings, implement a linked-list, or twiddle bits. If the candidate actually did any of that on the job or any of their previous jobs, they would or should have been fired. Java has sufficient mechanisms for all of those built into the platform. So, the last time the candidate encountered any of that was either in school or in their last interview. If an interviewer turns down someone because the interviewer asks the one question the candidate hasn't heard or thought in 10 years, then the candidate is not the stupid one.
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.
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.
Yeah, it's just like standardized testing. It's irrelevant because the conditions imposed by the testing scenario are more important to the tester than the real demands of the job. So what ends up happening is an obnoxious rehash of a CompSci course. Anyone who does that to you is a head-wedged bureaucrat. Interviewing's hard. More than anything this is a sign of laziness or incompetence on the part of the interviewer. Probably means that they're also an inept manager.
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.
Get your teeth into a small slice: the cake of liberty
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."
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.
libguestfs - tools for accessing and modifying virtual machine disk images
I absolutely concur. I'll usually be blunt and indicate that I'm interested in the solution methodology and not the specific answer, and I'll probably send the candidate down a dead-end road to see how he reacts.
... I probably can't teach you how to be less of an asshat. A bad attitude is destructive, no matter what degree of "leet skills" you think you have. Unless you're being harassed or threatened, walking out of an interview is a mistake.
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