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

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: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.

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.