Ask Slashdot: How Can You Apply For A Job When Your Code Samples Suck?
An anonymous Slashdot reader ran into a problem when looking for a new employer:
Most ask for links to "recent work" but the reason I'm leaving my current job is because this company doesn't produce good code. After years of trying to force them to change, they have refused to change any of their poor practices, because the CTO is a narcissist and doesn't recognize that so much is wrong. I have written good code for this company. The problem is it is mostly back-end code where I was afforded some freedom, but the front-end is still a complete mess that doesn't reflect any coherent coding practice whatsoever...
I am giving up on fixing this company but finding it hard to exemplify my work when it is hidden behind some of the worst front-end code I have ever seen. Most job applications ask for links to live code, not for code samples (which I would more easily be able to supply). Some of the websites look okay on the surface, but are one right click -> inspect element away from giving away the mess; most of the projects require a username and password to login as well but account registration is not open. So how do I reference my recent work when all of my recent work is embarrassing on the front-end?
The original submission's title asked what to use for work samples "when the CTO has butchered all my work." Any suggestions? Leave your best thoughts in the comments. How can you apply for a job when your code samples suck?
I am giving up on fixing this company but finding it hard to exemplify my work when it is hidden behind some of the worst front-end code I have ever seen. Most job applications ask for links to live code, not for code samples (which I would more easily be able to supply). Some of the websites look okay on the surface, but are one right click -> inspect element away from giving away the mess; most of the projects require a username and password to login as well but account registration is not open. So how do I reference my recent work when all of my recent work is embarrassing on the front-end?
The original submission's title asked what to use for work samples "when the CTO has butchered all my work." Any suggestions? Leave your best thoughts in the comments. How can you apply for a job when your code samples suck?
And therefore taking it with you would be illegal?
Generally, code that you wrote for pay does not belong to you, so you won't be able to submit it as a code sample anyway. So write some open source software, and write it as well as you are able. Then you can submit that.
If a job candidate walked in and handed me proprietary backend code from his current employer, you can pretty much be guaranteed that he wouldn’t be getting the job. Aside from the obvious legal concerns, how could we be expected to trust that he wouldn’t do the same thing later with our code?
Most job applications ask for links to live code
In nearly all companies, what you wrote as part of employment is owned by the company. So asking for live code from job applicants is no different from asking for trade secrets, and there should only be one respond:
"It is both against my ethics and my employment contract to show any of my employer's code to you, but I can tell you my code is being used in production capacity in my employer servicing business function X, Y and Z. I am happy to provide codes which I do own so you can judge the quality of my work."
Essentially, you ignore the unreasonable requests and provide a reasonable alternative. Any company that rejected you for that, you wouldn't want to work there anyway, who knows what further unreasonable/unethical request you would get if they became your boss.
Oliver.
This is a re-iteration of a reply elsewhere in this thread.
I think a reasonable analog would be in terms of musicians - would you hire a musician based on the work of the band they were in or would you want them to audition for you?
The obvious example would be if you were hiring a musician based on them being an ex-Beatle would you be as happy with a Ringo as a John, Paul or George? How would you feel if you got George based on what you heard in the albums and later found out that Eric Clapton played some of the guitar attributed to George on the albums?
As an employer, I would want to see what the applicant could do as an individual contributor to show that they have the required technical chops and then use the interview process to determine whether or not they fit in with the company/team.
Doesn't matter if it's a musician or coder.
Mimetics Inc. Twitter
I haven't kept a practice log since I was in elementary school, and I don't know very many musicians that do. That doesn't mean we don't practice. That said, I'm assuming your intended point was that programmers should practice their craft while off the clock. Unfortunately, using that outside practice as a way to measure ability is a very bad idea.
First, programmers writing significant amounts of software outside of work is relatively rare, both because of invention assignment agreement headaches and because programmers usually have other interests besides programming. For me, my main outside interests are music and photography, both of which are huge time sinks. If I'm spending 40 hours a week writing software, the last thing I want to do in the remaining ~60 hours of usable time is to write software unless there's some pressing problem that I can't solve in simpler ways. I occasionally write software for my own personal needs, but I spend orders of magnitude more time writing software at work than I do writing software at home.
And even ignoring that problem, evaluating a programmer based on spare-time code will usually give you a highly inaccurate impression of that person's ability. I would never want to show anyone the code that I write for myself. I don't write unit tests. I don't refactor. I just hack it until it works. Half of it is a glued-together pile of shell scripts and Perl, and the rest is not much better. I'm the only one who will ever maintain my personal code, and if it breaks, it impacts only me, so the need to polish the code just isn't there.
For example, the last piece of software I wrote was a tool to make printing of wind band sheet music less unholy. It's a PDF filter for OS X that takes an input PDF file consisting of 8.5"x11" pages and reformats it on 11"x17" pages, with a center 8.5"x11" half sheet if (num_pages modulo 4) == [1, 2], then prints those pages in up to two passes per input file (because the double sheets need short edge binding and the single sheets need long edge binding so that they flip in the right direction). Under the hood, it is a colossal hack of deprecated APIs (in part because some of the required functionality isn't exposed in the current APIs), and it is buggy as heck because it started out as a somewhat buggy sample code project, and I never bothered to debug it or convert it to ARC. It still meets my minimal needs even though it crashes every so often, so why spend the extra effort to polish a tool that I use to print fifty or sixty parts every couple of years and then don't use again for a couple of years?
At work, the programming languages and available tools are different, I write tests (probably way more than average), and I frequently do major refactoring work to reduce the code footprint and make code easier to understand and maintain. The reasons for this difference are twofold: A. someone other than me will eventually have to maintain my work code, and B. when my work code breaks, it impacts everybody who uses it, not just me.
So evaluating a programmer based on spare-time coding is like evaluating a musician with hidden microphone in the warm-up room and ignoring the actual audition. It might be an interesting approach to experiment with for laughs, but it is unlikely to get you the best players/singers.
Check out my sci-fi/humor trilogy at PatriotsBooks.
Which means that you should contribute to open source projects now and then just to leave some traces of your worth.
Or even develop some demonstration application that you can show. Doesn't really matter what.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
If you're looking for how well they architecture something or solve non-trivial problems, you might need more than 50 lines.
Indeed. I hire people, and I am looking for way more than 50 lines. At least 500 lines. It should be a non-trivial complete program that does something interesting. It is fine if it is something you wrote for a hobby project on your own time. In fact, it is BETTER if it is hobby code, since that indicates passion and a love of coding.
The first question I will ask is "Explain what this program does." I expect you to walk me through it, explaining as you go. It is surprising how many candidates can't do that ... since they clearly didn't write the code themselves. That is great. I love ending interviews early because I then have free time in my schedule.
Besides listening to a candidate explain their own code, I am looking for useful comments, logically named functions that do only one thing, consistently named variables, encapsulation of state, etc. The code should be readable and easy to understand. It should look like it was written by a competent professional who is proud of his craftsmanship.
I am looking for much more than a "grasp of the language". I am looking for a grasp of professional programming principles.
When the only tool you have is a hammer, everything looks like a nail.
What would you think of a handyman whose answer to everything is "use a ball-peen hammer"? You might notice that's the only tool he has, a ball peen hammer. No screwdriver, no wrench, just a ball peen hammer.
Rust is like a ball peen hammer. There are a few jobs for which Rust is the right tool. For 98% of programming needs, another common tool is clearly a better fit. The limited memory safety Rust fanbois are so proud of is also true of EVERY interpreted language going back to the 1950s.
You newbie fanbois sound like if a Ford afficiando went on and on about "Ford trucks have FOUR cup holders!". The advantage you're so proud of is neither particularly uncommon or all THAT damn important.
In fact, it makes YOUR code less safe because you think that because the language eliminates ONE small class of errors (the same errors every interpreted language also protects against), that means you're safe and don't have to be careful. That's like if you have a great lock on your glovebox, so you leave your damn car unlocked while screaming "nobody can steal stuff from MY glovebox". Well, you're missing most of the risks while ranting about protection from one small category of risk.
Perhaps you should stop hiring them off a street corner.
I work for a respectable company and all our code is Apache licensed (open source) and publicly available. Anyone can see my code.
Let's not jump to conclusions and assume that OP is breaking the law.
That said, my advice to OP is to contribute code constantly to open source and free software projects. This is very impressive to employers for various reasons: 1) it displays your passion-driven, good quality code, in projects that you yourself chose, 2) it shows your delight in code itself, rather than profit, 3) it proves you're ambitious enough to work after hours to further your career.
I hire people, and let me tell you that people listing several open source contributions (including their own independent open source projecs) always jump to the top of the stack.
Why would he post a link to a great job on Slashdot? So he can get inundated with inquiries from bitter jackoff Anonymous Cowards like you?
Here on Slashdot, you can surf the comments at +1 if you want to avoid the tsuris, but you can't post at +1.
Who needs a bunch of resumes from GNAA, APK, neo-Nazis, 4chan trolls, MRAs and griefers? Here, let me illustrate:
Why you dumbfuck. The best advice you can offer is "git gud"? I'll bet you're a goddamn prize employee.
You are welcome on my lawn.
We needed to hire another coder a few years back. One of our greybeards said, "don't just look at resumes and gauge the firmness of their handshakes, make them take a coding test." So I wrote one up that specifically tested the skills we needed the new pair of hands for that fit onto six pages of good old-fashioned paper.
We got six bites for the position through our usual staffing firms. Three were kids barely old enough to go drinking with, so they're out because we needed someone to work, not to be taught to work, and three guys with about a decade plus. All three had impeccable resumes.
The first guy could barely figure out which way was up on the pages I gave him. The second figured out which side of the page was up but promptly got more than half the questions wrong. The last one promptly got slightly less than half the questions wrong. That's the guy we went with, and we lucked out because he learned quickly and has done good work for us.
The first guy, in the process of revealing to us that he couldn't tell C++ from a hole in the ground also came up with this gem among his many grumblings: "This code test is awful! You could get someone at way less than my rate to come up with it!"
The moral of this story: we've all interviewed Guy Number 1 at some point in our careers. Complaints about other people ruining your work and not being able to provide code samples because whateverwhatever will set off alarm bells. You need to prove you can code by yourself. If that means something as simple as maintaining a personal webpage where you just experiment with stuff, do it. If that means contributing to OSS, do it. If that means offering to take any and all code tests during an interview, do it. But what you don't want to do is start the interview with whining and complaining. Even if you're right, you'll be lumped in with all the jackasses that are all bluster and no technical competence and you won't even make it to the interview.
Here on Slashdot, you can surf the comments at +1 if you want to avoid the tsuris, but you can't post at +1.
I think you can actually.
At least 500 lines. It should be a non-trivial complete program that does something interesting. It is fine if it is something you wrote for a hobby project on your own time. In fact, it is BETTER if it is hobby code, since that indicates passion and a love of coding.
Unless you're working on web front end stuff, or open source projects, people aren't going ot be able to share any of the work they've done. If you're then relying on hobby projects, you're restricting yourself to certain types of personality and you're going to miss a lot of great people.
Some of the best pogrammers I've known work had and well during work hours then switch off afterwards, meaning they don't have any hobby projects. I also disagree that to have a passion for something you have to live and breathe it 24/7.
SJW n. One who posts facts.
First of all don't ever make available in any way your companies code unless you have written permission to do so. Second, you simply tell them that you can't provide said code due to NDA / compliance issues. Put together some great code on your own and offer that along with your reason. You will, by doing that alone, separate yourself from the pack as a guy wgo actually understands how businesses work. Finally, that is just going to get you a code monkey job. If you want a real job there has to be documentation including requirements and design specs, as well as test methodology with implementation of same. There is more, but if you get that fat you will be so far ahead of the pack you can worry about that tomorrow, which is exacrly when you should start preparing for the next time.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
I've never taken code from a previous job into a job interview. If I have access to that code, I'd be betraying trust by copying it and giving it to someone else. If I don't have access to that code, I can't anyway.
I have had a job application where a programming challenge was emailed to me with a three day deadline for completion, and sent back well structured working code, compilation instructions, a build script and working unit tests. I got called straight in for interview.
That seems reasonable to me; the programming challenge was a specific scenario so you couldn't search stack overflow for code examples (although this was in the days before stack overflow anyway), it let me demonstrate that I could program to a professional level, and it didn't require to me share any code that may belong to someone else.
Indeed. I hire people, and I am looking for way more than 50 lines. At least 500 lines. It should be a non-trivial complete program that does something interesting
I couldn't have done that. My professional work was in a team environment, where my code was part of a greater whole and a 500-1000 line excerpt might do an awful lot but certainly didn't compile and run standalone.
Shit, even my hobby code has that characteristic. Ask Linus for 500 line of his code and see if you get a complete fucking program back.
So with one stroke of the pen, whilst I read the contract, it is gone and the onus is on them to agree
That's not how contract law works. Unless they initial the change, the presumption will be that they didn't read your alteration, and therefore it isn't binding. Remember, they'll have real lawyers.
That being said, they may well agree to the change, especially if you word it such that you'll be using open source code in places, and such code including changes will remain public. Some very big contractors use exactly this approach (and then don't share their changes with the larger community, but that's a different issue).
Socialism: a lie told by totalitarians and believed by fools.
That doesn't prove ownership
I don't need to prove ownership, only disprove it.
If the code existed before my job started, then my employer has no valid claim to it.
Proving ownership would only be necessary to stop others from using my code. I have no desire to do that.
Never once have I seen this.
I'm not talking about posting using a karma bonus. My point is that there's no way to post only to people who have accounts with ratings >0. As far as I can tell, there's no way to do that.
You are welcome on my lawn.
I have to agree, I see more excuses then actual proof that you can write good code. In short for most organizations the ability to write perfect code is nearly impossible. The aspects of what is considered good code are mostly academic and abstract in nature, rarely consider real world problems, such as speed to delivery, compatibility with legacy systems, having to try to justify to share holders why there isn't any visible change to the product...
As someone who had started out as a programmer and had advanced to Architect and Manager, I find myself having to direct the less experience coders to do things in a way that I know myself would had issues with doing such back when I was started, with my head fresh with ideas on what was right and what was wrong. There is a real balance that needs to take place. In terms of interviewing and explaining your code examples if you could explain the reasons why you did it that way vs other ways, chances are the hiring staff would be able respect your code more.
Normally if I am reviewing a potential employee code samples, I am trying to gauge their technical skills by seeing that they can in fact produce complete code, ingenuity seeing how they are able to work around problems, organization making sure their code is done in some sort of logical order. I am not going to nitpick on how well they isolate classes, or if they decided to make a polymorphic class structure with overloaded operators.
At one employer I had made a test that was rather good at getting good employees.
Problem 1: HTML/CSS I had a picture of an overlapping boxes on top of a grid, and ask them to reproduce it.
Problem 2: I had a SQL command that returned no rows, however the table and logic obviously shows that it should. They were to debug the code and fix the problem.
Problem 3: Make a basic Input form in the language needed asking for an American Address fields (with leading 0 zip codes) with appropriate checks to make sure the address is valid.
I have found that more most people this test actually takes them 4 hours to complete they are allowed to use Google to search for help, but they are not allowed to chat with someone else or ask a direct question, so they are proctored. I had found out that this test weeded out a lot of bad developers as retained mostly good ones. As they knew how to search for information they didn't know, analyse and break apart complex code to find problems and deal with problems which may have a hidden twist to them.
But back to the point, blaming your CTO for bad code is just a lame excuse. I have dealt with bad CTO with stupid ideas, and I found ways to make them work.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
So you are claiming that there are "great programmers" that have never done hobby programming, do not contribute to open source, have never written a single professional program that they are allowed to share, have never written a
That's not exactly what I said, but the practical results are the same: yes.
First, let's get the silly bits out of the way:
never written a single professional program that they are allowed to share,
Plenty, probably most.
have never written a program as a school assignment,
lol. Unless you're only hiring junior programmers then this is (a) irrelevant (seriously? you want to see a piece of code I wrote in the year 2000?) and (b) they probably don't still have their school assignments. I know I don't and I'm only in my 30s. Programmers go older than 30 you know.
, and are unwilling to sit down and spend a day writing 500 lines of code so they can go to an interview?
Hi, come and wirk for me! But first, please take time out of your busy schedule to do a bunch of work for me to prove to me that you actually want to be poached.
Thanks but no. I have rejected places that tried to poach me then asked me to do a bunch of work when I had not enough time for my own work. Naturally I told them I wasn't interested. When it came to hire me, such a tack was an abject failure. I'm not especially unique in having stuff I want to do that's not coding.
that have never done hobby programming, do not contribute to open source,
Never? Probably not. Currently? Not unlikely. A 15 year old hobby project form a 35 year old developer isn't terribly informative.
I've got plenty of F/OSS stuff I've done, and my stuff is out there and in some cases even used. I have no problem meeting your criteria. However, for most of the people I currently work with I think maybe one other would meet your criteria.
Personally, I think you're operating in something of a bubble. You are (presumably) hiring people like you, so all you see is people like you. You can I expect find good ones, so you are making a false correlation.
There are *tons* of people out there who don't meet those criteria. For me, that opens the pool of good candidates much wider.
SJW n. One who posts facts.
I am twice your age.
Pedant point: I said I was in my 30s, not that I was 30. So,you're between 60 and 80-epsilon.
I have every program I have ever written.
I most certainly do not!
Plenty of the stuff I've written I've had absolutely no right to do that since it belongs to someone else. Plenty of programmers spent their entire careers in the commercial world and won't have copies of their code. And if they do when they shouldn't, you probably shouldn't hire them!
I learned to program in Fortran in the 1970s. In 1979, I copied all my card decks onto an 8 inch floppy. Then in the 80s to 5.25 inch, then to a HDD.
OK, so you're an e-squirrel. That's fine, I am too, though not as thorough. I don't have any of the programs I wrote in BBC BASIC and 6502 asm any more, neither do I have all (or even any) of my QuickBasic/QBasic doodlings. And plenty of the stuff I wrote in C when I was a young buck and though I was the bollocks would frankly be an embarrassment. I don't believe I still have my university assignments either way.
My ~/src has 637 subdirectories, each containing a program or library that I have written. When I hire someone, I expect them to have a "bag of tricks" that they can apply.
The good programmers have the bag of tricks in their head. If they're working with modern tech e.g. the (ugh) cloud stack, the specific languages and libraries change so fast, that any squirrelled stuff will go out of date pretty fast. And many already make extensive use of F/OSS libraries and stuff.
The world isn't like the 90's and before now, when if you're hacking in C, you'd be hobbled without your own personal library of stuff to make up for the more or less non-existent standard library.
I refuse to believe that there are "great programmers" who have NOTHING.
Well, of course not. You won't hire people like that so the chance of finding any great programmers like that is more or less zero. All you've demonstrated though is the existence of selection bias.
I want a deep and narrow pool. For a typical open position I get over 200 resumes submitted. I narrow those down to 20 that get a followup email, 10 that receive a phone call, 3 to 5 who get an interview, and one who gets the job. The last thing I need is more candidates who have no ability whatsoever to demonstrate that they can do the job. I already get plenty of those.
Good for you, I guess. Personally, I'd rather not narrow the pool with arbitrary criteria that don't have anything to do with how well they'll do the job.
SJW n. One who posts facts.