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?
Nothing says you can't share that. I think many hiring managers would understand that sometimes clueless coworkers or especially bad management decisions get in the way of producing quality code. Ignore the front end code unless asked about it. If questioned about it, just mention that bean counters higher up meddled with it/forced you to code like that (also shows you obey management, which is a plus for getting hired lol)
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.
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.
[out of the loop]
Who's Chris, and what is a "Cashews" user?
Lots of good points about the possible legal issues of pointing to your existing/previous employer's code from the perspective that a) you don't own the code, b) your disparaging a company's product (which you may not be allowed to do because of past employment agreements) and c) I'm not really sure that you can easily prove that you wrote it in the first place.
Instead, if you think you're a Hotel Sierra coder, create a relatively simple app - it doesn't have to be brilliant in concept but use it as an opportunity to show off your skills. Write it, put it on an (appropriate) app store and reference it in your application and make the GitHub code base available to everyone as part of your resume.
Mimetics Inc. Twitter
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.
Mimetics Inc. Twitter
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.
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
Who's Chris
WE'RE ALL CHRIS
lucm, indeed.
Code samples don't have to be from your job. Have a hobby programming project, and use that for your code samples.
Here are recommendations from a manager at one of the world's largest "professional services firms" -- a multi-billion dollar organization with a large IT practice.
I have also managed teams of people responsible for developing and sustaining IT solutions.
Don't worry about code samples so much.
Instead, worry about coming off as professional, hard-working, collaborative, and competent/ knowledgeable. Demonstrating an ability to communicate effectively would be a plus (especially for a coder, who tends to frustrate with an inability to communicate with other people).
You don't have to show prior-developed code to accomplish this. Here are other options --
Instead, talk about hallmarks of excellent code development, and how you have leveraged them in the past. You can talk about incorporating error handling. You can talk about writing efficient code. You can talk about how for a given function or operation, there might be five different ways of getting to the same goal, but that depending on requirements and constraints, one method might be a better solution than the others, and talk about why. If there are particular languages a prospective employer uses, put it in that context.
You can also talk about the flip side -- where you have seen sloppy, inefficient code, how you have seen it damage the operation of a site or app, and how you might correct it.
Offer to develop a short piece of sample code that performs an operation or function the employer might have interest in, and that highlights your knowledge in the context of the kinds of solutions your prospective employer focuses on.
You don't have code samples, but what you do have are a very particular set of skills. Skills you have acquired over a very long career. Skills that make you a nightmare for bugs in other peoples convoluted code...
Few people get a clean environment in which to create pristine code from scratch, be proud of how you have shone a light into some dark places, made things work where others couldn't find the problem and made the world a better place one line of code at a time
Oh, and for sure write some of your own stuff from scratch to show you actually enjoy it and are good at it, that was good advice.
Nullius in verba
Chef/Puppet
2010 called, they want their unreliable, kludgy alternatives to Ansible back.
lucm, indeed.
1) Write code that solves a problem. In your job, you must have thought a few times, "Someone should write code to that does such-and-such." Ok, for your project, write that code. The interviewer will be more interested in your code, if they want to use it themselves.
2) Make sure that your code is secure. Don't tell the interviewer, "This code assumes that the input data has previously been checked." No - your code should check the input, and reject any bad input.
3) Before the interview, make sure that you're very familiar with your code. If the interviewer asks you why you did such-and-such, you should be able to tell them why. If you're told to change the logic or messages or whatever, make sure that you know how to change it.
You want a pull, image-based deployment strategy? Docker.
You want a push, idempotent playbook deployment strategy? Ansible.
You want something heavy that requires a client on each machine, and that requires a central database that poorly scales and that easily gets out of sync? Chef/Puppet.
Of course if you've learned your Devops skills in 2010 and can't be bothered to upgrade yourself, feel free to stick with Chef or Puppet. Or why not Microsoft SCCM or IBM Maximo while you're looking at obsolete junk?
lucm, indeed.
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.
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.
I seriously doubt that employers are expecting job applicants to hand over proprietary code from their current employer and even if they were would you really want to work for a company with such dubious ethics? Even if you could do that how would you prove what code you've personally written and which hasn't been improved by someone else, unless you also need to bring along SVN logs...?
Normally when I've seen jobs ask for code samples they're talking about your own personal projects done in your own time which you own the rights to. I suggest start using your free time to create your own open source software for things that you yourself are passionate about, stick it on Github and give prospective employers a link to it. This is a much better way of showing your own capabilities without getting the legal problems.
In many companies even the meaningless codename of the project you worked on is under NDA. Do what everyone else does and just describe what you did in vague terms like the technology used, and value to the company. Yes, it may have been a mess, but it was used by the client and may have delivered millions in value to the company. That's what matters in this industry. There are many total garbage pieces of code out there that rake in gazillions for companies. Also, there is an enormous amount of developer jobs. If some have requirements that you can't or don't want to fulfill like linking to live code, just skip them.
If you really want to show off code, write something small and new (preferably slighly related to what you want to do), put it up on Github, and link to that. It can be a tiny project that just shows that you can write code that does something in an acceptable way.
Also, you sound quite bitter about your former employer. I understand that, because well, aren't we all. But, they must have done something right being in business for some time and hiring people. Try to focus on the positive, they are in your past now. Not for some zen reason, but if you give negative vibes about previous employers in an interview, that counts as a red flag to many HR people.
You want a pull, image-based deployment strategy? Docker.
You are doing it wrong then. Docker is for partitioning physical hardware without having to pay the I/O overhead of virtualization (which is about 75%). Image based deployment is dumb but if you want to do it, Packer is better as you don't waste so much time moving image diffs over the network that way. The issue with image-based deployment is the need for a central registry to make it all work and that makes testing a PITA. Its a classic case of operations wagging the company. The most poorly managed companies I've worked at often made that mistake for some weird reason. Seems like celebrating the cheerleaders after a big win by the football team.
"Those that start by burning books, will end by burning men."
If you are smart and you deserve the job, then you will come up with a way to show them your skills. Also, sharing your employer's proprietary code is not the best way to show your wicked skillz, as most prisons do not allow telecommuting to work.
mcdonalds is always hiring.
- As commented in various posts above, what you develop while being an employee belongs to the company. In any case, you rarely validate your work at a company with code samples but with time, generically-defined tasks and, eventually, feedback from the given employer.
- Code samples are expected to be individually developed by you or, at least, have clearly defined your exact contribution. Ideally, you should be the responsible for everything: ideation, implementation, bug fixing, etc. All this seems quite incompatible with what you do as an employee, by implementing what you are being instructed to do, what, how, when and at what cost. Even in case of using company's code as your samples, you would be mostly proving to be a good fit for that company rather than your actual value as developer/worker/person. A slightly different story would be you having a very high flexibility regarding how to implement a roughly-defined set of ideas; but even in that case, your exact contribution and the effect of other factors like company's culture would be unclear.
- My work has always been almost exclusively focused on algorithm development, efficiency improvement, data management, etc. or, in web-based lingo, back-end. I have always had lots of problems to show my work with previous clients because of rarely being public and, most of times, not even shareable with anyone else. I guess that most of developers like me have always had these "problems" which, until relatively recent times, weren't felt as such as far as private, proprietary, close-source software is quite common. The only reason why this issue has started to be seen as a problem is because of the huge increase of low-quality, non-specialised, ignorant offer/demand, where things like "you have people taking care of GUI/aesthetics and people taking care of internals" aren't evident anymore. I am commenting more about this in the last point.
- The most logical way to have good code samples is to spend some time on building them at your own expense. This is also the best proceeding to maximise what code samples are precisely being expected to deliver: a good idea about your skills in the widest sense of the expression. This doesn't just mean having some technical knowledge, being able to follow orders and dealing with comfortable and well-defined conditions, but also coming up with nice/innovative approaches, showing your main priorities or how much effort/interest you put in your work and, in general, delivering comprehensive solutions saying quite a lot about you to people willing and able to understand them. Despite all this, I have personally decided to reduce my number of public contributions/code samples; firstly, because I have done a quite relevant effort on this front already and, secondly, because people don't seem to care about all this as I expect them to do (i.e., objectively and knowledgeably analysing my work as opposed to just counting the number of stars/likes/lines of code).
- My last point is about recruiters and HR/hiring departments with low-to-no technical knowledge/concerns, even when dealing with expert candidates. This thing of a front-end implementation having any kind of impact on a back-end developer is quite indicative of the level of tremendous ignorance and arbitrariness which you can find out there. Just about 1 week ago, I had a "technical" interview where I was (generically and crappily) asked about how I would implement a web interface, what is pretty much the opposite to what most of my experience is about. Note that I have no problem with non-technical staff for as long as they accept their (lack of) knowledge and compensate it with the adequate means (e.g., taking advise from actual experts). These ridiculously bad to everyone nonsense is even more intense under my specific conditions (remotely working/freelancing/external contractors). My ideas regarding how to proceed in these cases are extremely clear since some time ago: zero tolerance with stupidity. I will not be patient or understanding with any
Custom Solvers 2.0 = Alvaro Carballo Garcia = varocarbas.
Another thing you could do is open or spruce up your github account. Backend code could be put there (as backend code) and whatever you do/want to advertise goes up also. Advertising yourself means doing the latest thing. Already I have my doubts about you because 1. You didn't think of this yourself. 2. You want to be on the cutting edge (what's coming in, and I bet the code you have could have been written in the last millenium). 3. "If you lie down with dogs, you get up with fleas." I gather you've got fleas; you've spent too long in that last job. You want a neat, commented, organised, succint code in an OSS project doing clever things. You need to improve continually, show variety and brains.
What does your current employer think of you sharing _their_ code with the competition?
Will your potential new employer not think that you'll steal _their_ code as well to brag for a new employment down the line?
stop dreaming of being a video produce.
Everybody dreams of being a video produce, but in Soviet Russia, produce video you!
Many, though not all, workplaces will work with you when you sign their employment contract to exclude company ownership of previous free software and open source software. Many, though not all, will also work with you to allow you to publish patches to the upstream owners of copyrighted free software, to avoid GPL confusion and to get the patches into the next official release. If your current workplace isn't clear about permitting such work, spend an hour with an attorney familiar with intellectual property law and do some personal, public work on something unrelated to your workplace.
This isn't always easy to do if you are a generalist in a consulting company: you can easily be called in for help because your work elsewhere is noticed. I've had good success protecting the intellectual property personally and with people working with or for me who had technical expertise outside our company's direct work.
stop dreaming of being a video produce.
And here I was, thinking this guy's fantasy was to be lettuce in a TV documentary.
He stands corrected. Did you hear that AC? He wants you to know that while he does not contest anything else you said, he has two dozen websites dedicated to his mediocrity! He sure out you in your place!
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
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
You missed the perfect opportunity to use "csspools"
Suggest multiplier less than 1. That's what I get fore trying to be terse since I an on my phone due to fire related internet outage
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Hmm. Immutable docker images are a beautiful way of assuring consistency through dev/test/prod, across different on and off premise hosting locations, at client sites and when scaling horizontally.
They have downsides, but they're pretty much fuck all to do with partitioning physical hardware.
How about "you write better code samples"? I guess I must be some kind of genius to figure that one out. It's either that, or the OP facing some mental challenges.
It's not a good idea to show samples from work anyway. At the very least you need to ask for permission, and that tends to start a process that ends with you leaving, whether you have a new job lined up or not.
1) you shouldn't be showing ANY code samples from a current job (unless it is open-source licensed). that stuff is proprietary and for many companies, HIGHLY confidential. It leaks copyright, and possibly potential patentable materials. In most big companies, that's grounds for more than just getting fired, but getting sued, too.
2) this is why you should be doing your own "home" projects. make an app, a back-end, a docker instance, anything, that you can share that is yours...especially if you open-source license it. show you can support and maintain a project. be able to talk about areas you did first time that you updated and refactored into something better (so you can demonstrate refactoring knowledge, as well as code structure).
"But remember, most lynch mobs aren't this nice." (H.Simpson)
-- Joe
Specify in your cover letter that you have to give samples because the back-end stuff, where you were able to follow best practices, is owned by your company and your front end code wound up going through a process that pretty much turned it into garbage. Give them links to the stuff you worked on that is live, but also the samples, and you'll be on your way.
If you're any good - I mean, literally, if you have a pulse and don't scream and hurl feces during your interview and demonstrate that you know at least how to slap at the keyboard and make something that works - you'll find a job.
Since I can't tell them apart, I treat all ACs as the same person.
... but if you can't infer my skillset from my code and what I have to tell about it, I don't want to work for you. If you judge my skills by the amount of commits or the amount of lines in a given set of repos, you're an idiot, plain and simple.
With modern PLs there are as many coding styles as there are coders. We get into religious wars over indent, bracketing and tabs versus spaces. Any judge over my code who isn't aware of this bias inherent to all of us is utterly unable to judge code at a cursory glance.
Point in case:
Two weeks ago a potential employer ditched a first interview with me after checking a GitHub account of mine. After I told him that it was only one of many. Provably one of his crew noticed only a few commits every few weeks and didn't realize it was a toolkit I was working on and not some project I couldn't disclose.
Their loss, not mine. If you don't have the time to ask what's up with repo X and my commits you're not qualified as a project lead. End of story.
My 2 eurocents.
We suffer more in our imagination than in reality. - Seneca
The fact that it's also a hardware partitioning strategy is still important, though, for the lack of security it implies between containers.
Socialism: a lie told by totalitarians and believed by fools.
A lot of the developers I'm asked to review have github repos now, with open source contributions or their own personal projects. We still talk to them a bit to verify that they actually can do the kind of work that we see in the repos. We also understand that not everyone has a github repo or code they can actually show us, and the interview really doesn't change that much if they don't. We're still going to ask some technical questions as well as try to evaluate whether we think they'll fit in well with the team. Where it might make a difference would be if you have less than about 5 years of experience. If you lack a degree and have no work experience, some interesting open source projects could still get you an interview.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
My resume points to my GitHub (it used to have SourceForge). Most hiring managers don't actually check your code, they will check your references. But if you don't have (good) code in an open source fashion, make some, contribute to some project that showcases your code skills.
If you can't find a job within ~1-2 months, you should probably review your resume, expectations and skills. It might just be that your code isn't all that great, that you're aiming for a position way above what you're qualified or your resume just sucks. A set of references is also a very helpful tool.
Your code, again, is usually not reviewed until later in the hiring process. If you get through the first set of interviews but never get a second interview or an offer, review your code, add some code to a big enough project where people won't be afraid to make changes or rejections. If your code continues to be rejected, you've got a skills problem.
There are a variety of resume parsers online, Indeed and ZipRecruiter are decent enough, if your resume doesn't parse correctly in those type of systems, you can be sure it won't parse in the majority of business' HR systems and your resume will be rejected. I just went through the process myself, and chiseled at my resume until it parsed, it's not very "eye catching" to say the least but I instantly got better responses from hiring managers. There are services that will actually polish up your resume for a fee, it may be worth it depending on the pay grade you're looking for, if you're aiming for C-level, it almost makes no sense to make your own resume.
Custom electronics and digital signage for your business: www.evcircuits.com
If I'm evaluating your code, I'm paying far more attention to your comments than your code. I'll treat it like I was given this code to fix a bug in it or add a feature, so I want to see if I can figure out what the intent is from comments. Bonus points if the comments explain how the code is intended to be tested. Bonus points if there are notes about oddities in the code, or explanations for cleverness. If the comments are good enough, I won't feel much need to look at the code closely, except for looking for consistent syntactical style (more of a reflection of adherence to coding standards, yes, but let me see that you follow them) and good naming practices.
In short, your comments should inform and excite me. Your code should bore me.
Never once have I seen this.
Yeah, I thought this was obvious: you can't just share your company's code without permission like that. Are companies actually asking candidates for samples of code they wrote for other companies? Do they not even know this? All that code is proprietary, and sharing it without permission is a copyright violation or worse. Would these companies want their own employees sharing company code like this?
If they need code samples, you just have to give them code that's all yours, meaning anything open-source, or code you wrote for some personal project that never was released, etc.
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.
Make your own side-project or contribute to an open source project. Showing that you've had pull requests accepted by a respected project is a major plus on your CV. A lot of companies (all the ones I've worked for) will ask you to complete a coding test. If the company you're applying for isn't going to test you then ask how they suggest you can demonstrate your ability. Don't show proprietary work from your current employer - not only is that illegal but more importantly its unethical.
Either get your shit together or pick a different career.
It does not matter how good or bad code is, the most important thing is how it is understandable. Every project is written with basic simple language abstracts and uses standard APIs of existing libraries. Nobody ever complain about existing languages, libraries or frameworks as long as they are well documented and have a lot of samples on-line to comprehend how they work. The development nightmare starts when volume of code to read exceeds 100s of written text pages and has no structure and proper logical isolation of its components and modules. We can write ugliest code, using tons of "code sugar" in order to kill code readability, but as long as it has simple logical separation of responsibilities it is not a big deal to comprehend and support. Long time ago I head following statement: "The automation of chaos provides automated chaos". If people don't understand how process should work, it is impossible to structure it and code it properly. So when you ask for code samples, whose job do you really want to see?
I did no such thing to confirm your ignorance. You skipped over the part where I challenged you: I employ a lawyer to ensure I meet my legal obligations ... What do you do?, the obvious answer is, nothing.
The US is a signatory to the Berne convention. As programmers I think your country has specifically given up some of the rights you had to the MPAA simply because you did not defend your rights. I don't specifically know what your situation is wrt local laws because as I said: I am saying what is legal for me, where I am. You have to take responsibility for yourself.
Seems like you didn't and the truth hurts you so much you're willing to falsify your own reality so you maintain ignorance about what you have lost evidenced by the contempt you are projecting onto me.
I don't see where I made a claim to be super smart, only that I've retained a lawyer and reseached enough about copyright law to protect my rights. I write and record music, I had to learn. When I did I found it applied to the software I wrote. Instead of decending into responding to your emotive outburst and abusing you, let's re-visit the comments I made that everyone seems to have a problem with:
If you are a contractor then they don't own your code. Even as an employee you still own the moral right to your code.
Specifically, if you are a contractor then you own the copyright to your code unless you agree to contractual terms to give up those rights. Anyone with sufficient deductive reasoning should be able extrapolate their legal situation to a corporate entity that has exactly the same set of rights that you do. The difference is they are negotiating from a position of strength so that you will relinquish your rights. But let's not let logic get in the way of me demolishing this "argument" with the relevant facts.
First, Article 10 of The TRIPS Agreement contains an interpretive provision stating that computer programs, whether in source or object code, shall be protected as "Literary Works" by the Berne Convention. Article 4 of the 1996 WIPO Copyright Treaty (WCT) includes a clarification in very similar terms.
Article 6 and Article 7 of the WCT document determine the framework for negotiation. You give up your rights according to WCT 6(2), I maintain my rights according to WCT 6(1) and WCT 7(1,3).
Therfore source and object code are protected as 'Literary Works' under Article 2 of the Berne Convention as original works and nothing in that treaty applies to you submitting your source code to a larger tree negates that right unless you specifically give it up. Specifically Berne Article 2(1,3,5), limited by local legislation which is why I say you need to take personal responsibility for knowing your local laws.
Second, as to Moral Rights, this is the specific position of the OP covered in
My ism, it's full of beliefs.
Explain the job you're leaving does crap work and your standards are higher, so you have to leave for moral and ethical reasons. Then ask if you can show Open Source code that you maintain on your own.
Having just recently gone through the interview process and providing links to my GitHub account (as well as respective npmjs / nuget), I found that it wasn't necessary to do any "developer assessment tests" or provide any samples tainted by crappy work done by others. All the crappy work in there was my own, along with some stuff I don't hate.
(If you don't think that you wrote crappy code at some point, you're either not learning or you're simply deluding yourself.)
I wouldn't take code from an existing job - that's just looking for trouble. For my last code sample, I took a tool I built for my own use, modified it slightly to be more general-use, and submitted that.
It was a custom exporter for several Autodesk programs that demonstrated my 3D math knowledge, use of existing commercial APIs, and a full OpenGL rendering system. It was about 1500 lines and got me the job without issue. Took me about a day to make, including the original tool development.
how hard can it be ? isn't that how the word goes ? get a loan, put a mortgage on your life sign your soul to the devil and startup ... if you're lucky you sell something before you have to pay the first quarterly :)
Free speech was meant to be free for all... how can anyone grow up in a nanny state ?