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?

Comments

write your own samples

[Anonymous Coward]

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.

Re:Share the backend code?

[Anubis IV]

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?

Ignore them

[khchung]

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.

Re:Ignore them

[dgatwood]

Actually, the only correct response is to hang up the phone.

Employers might ask you if you have any open source code on GitHub or something, but beyond that, no legitimate employer should ask for examples of recent code unless you're a new college hire, for precisely this reason. Forget about whether they would still hire you if you say no. Any employer that even asks should be immediately disqualified from consideration.

Re:What about when your old job owns the code?

[berj]

If a job applicant came into my office with another company's work product on their laptop (and I knew/they told me it was something they weren't supposed to have) two things would happen.. 1) I would make sure they understood that I wouldn't be hiring them because I couldn't possibly trust them not to do the same thing to me and 2) I would let management at the other company know.

Ethics Question to be Respectfully Answered

[mykepredko]

dgatwood,

I could see an employer asking this question as a way to ascertain what the applicant's moral character is.

I thought the response by khchung was perfectly worded - you're not going to violate any laws or ethics by providing a previous employer's intellectual property. But, you're happy to provide samples of your own work that you have created on your own.

If a programmer can't provide code they've written on their own, I would tend to doubt their skills in exactly the same way I would doubt the skills of a musician that couldn't provide proof that they practiced their instrument on their own time but wanted to be hired based on the recorded work done with other musicians.

Re:Ethics Question to be Respectfully Answered

[dgatwood]

If a programmer can't provide code they've written on their own, I would tend to doubt their skills in exactly the same way I would doubt the skills of a musician that couldn't provide proof that they practiced their instrument on their own time but wanted to be hired based on the recorded work done with other musicians.

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.

It's not avaliable!

[chromaexcursion]

if you were working for a company, your code is proprietary. You can't share it.
Simple answer: you can't legally share your code.
If they balk, tell them they are being unprofessional.
In 32 years I've never been asked to provide code. Good thing with the number of NDA's I've signed.

If they're asking you to write a code sample, that's a different story. Make something up.

Re:What about when your old job owns the code?

[lucm]

Think of it this way:

1) You won't get caught. The company interviewing you most certainly won't tell the other company that you shared code, and as long as you just show it to the interviewer on your own machine (not give them a file with the code) it won't escape into the wild, so you have nothing to worry about.

2) True, the company you are interviewing for many get a few ideas from what you showed them. But regardless, they would have to code it themselves (see point 1), and secondly, if the original company had management issues like that, it's almost their karma for treating their employees like that (should have trusted them more, in which case they would have stayed and not shared code).

You are the worst possible kind of candidate for a job in IT. No ethics, no pride, no class. Those are not things you can learn, you were simply born with a few missing parts.

You don't belong in IT but you probably have a future in used cars sales or marketing. Time to pivot, my friend, otherwise it won't be long before your name circulates on the informal do-no-hire network.

Re:Share the backend code?

[Z00L00K]

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.

Re:Share the backend code?

[ShanghaiBill]

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 all you have is a hammer

[raymorris]

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.

Re:Share the backend code?

[MrKaos]

If you're a contractor, being paid for time, you don't usually own anything you produce while you're being paid, it will be in your contract.

So what? With a common law contract (at least where I am) the default position is that the contractor owns the intellectual rights to their code. You have to ADD that condition to a contract to override the common law position.

So with one stroke of the pen, whilst I read the contract, it is gone and the onus is on them to agree or explain why the common law position is not acceptable and we are back to rate negotiations. I think you need to learn some negotiation skills and to not be a pussy. Keep your code and the money. That's what I learned contracting for over a decade, it's money in your pocket.

Isn't it obvious to you they have time and budget constraints if they are seeking a contractor? They just want to get on with it, if they think you're good enough to offer a contract to then they think you can do the job and don't want to fuck around. You need to foster a business mindset if you are going to contract program they aren't buying code, they're buying time.

Re:Share the backend code?

[johnw]

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.

Re:Share the backend code?

[serviscope_minor]

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.

Re: Well, Chris, here's what you do

[Zero__Kelvin]

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.

Re:Share the backend code?

[Cederic]

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.