Would a cut and paste coder ever get past a job interview?

Question

As a long time cut and paste coder I never committed much of the syntax of a language to memory. Even worse, I now use google to solve many of the coding problems which are of the type typically used in job interviews. This has greatly increased my productivity, the quality of the end result and stops me perpetuating the same bugs across all my code. However it means I don't actually remember the detail of the solution. For some reason in a job interview "I would look that up on google" does not seem to be the right answer.

Am I better off in the interview to pass no comment on my coding style and simply pull out an iPad and produce the solution?

Answer 1

Great question, I've faced this scenerio myself.

I hardly even think when I code nowadays. Samples are readily available online or specific questions answered in sites such as stackoverflow. Personally, what I look for in a good coder is how fast he can find a solution online, that's 90% of the coding game. Alot of people like to think it's more academic than that, or people that like to make things more complicated then they should be.

But for your standard everyday application (which makes the majority of the applications out there) it's all there. Everything is online via a zillion samples, coders aren't inventing anything. It's just a matter of knowing how to find info and how to mesh it together to produce product. Now, I'm not talking about slapping together stuff to produce a mess, you definitely need to know what you're doing: you need to be organized and be a great problem solver and have a passion for this craft.

But you wouldn't believe these "reputable" coders in my company that peck at the keyboard and look through ages at search results in google, like they're reading some kind of endless almanac or something, it's sad. They get to a solution in hours whereas I can take minutes or even seconds to find it. I'm the google master blaster.

Having said that, you can't rely on that for job interviews unfortunately. Job interviews --and especially in big companies like Google or Microsoft-- are purely academic type questions. Just know this, just accept this reality (I have). In other words, pull up your sleeves and learn your standard boiler plate interview questions that everyone asks. I do this every time I'm in between jobs. I take 1-2 weeks to learn this stuff (it never takes more than 1-2 weeks), just like a midterm test. Go into interviews and blow them away. The great part about it is that no one is original and all interviewers look at the same boring questions on the top 20 search results on google for "programming interview questions" ... things like "what's an algorithm for finding if linked list is circular or not". or "what's the difference between an abstract class and an interface".. "explain to me what a delegate is" ... "how do you do a breadth first search tree traversal"... and on and on... after which, get a little bit more domain specific. so if you're applying to be a c# front end guy or a backend java guy or whatever, make sure you know all the big news and buzzwords and technologies behind those, even brush up on the new language features for your chosen technology. Trust me, it's a game. and the better you play it the better chances you'll have in scoring a job. In interviews, Knowledge is POWER.

But to sum it up, there's nothing to do but bite the bullet and regurgitate what the corporate masters want you to do. Get "Programming Interviews Exposed" and study, study, study. Take notes. I would suggest a good 20 page summary of what you learned during that time...

Answer 2

If they are asking you to solve a problem, it's not so much that they are worried about you knowing the syntax of a language, it is that they want to know if you have good problem solving skills, and know how to get to the right answer(or at least know how to come close).

There is no issue at all giving them pseudo code to solve the answer.

Answer 3

There has to be some sort of happy medium here. Instead of totally relying on Google searches, I'd be more impressed if you came up with a better strategy: cheat sheets, personal coding database reference, templates, some automation tools, anything. Hopefully the coding test during the interview is not a pop quiz.

You should know the basics. I wouldn't expect someone to create a FoxPro 2.0 connection string off of the top of their head, but at least know you have to open and at some point close the thing.

Memory is a weakness of mine, I do have a track record of gaining fluency when I use a language..

Answer 4

everyone is a cut and paste programmer to some degree, in that everyone has bits and pieces he uses over and over again. Favoured constructs, code templates, and who doesn't at times copy parts of samples as a start for their own code?

It is of course a matter of degree. Someone who can't do anything that doesn't involve blindly cutting and pasting bits and pieces together in the hope it'll yield a working system isn't going to survive for long in any serious job. If he gets past a job interview the interviewer didn't do a good job. But I know from personal experience that many interviewers don't do a proper job...

Answer 5

Hey bigdave,
Yes, cut and paste programmers make it through
I cut-and-pasted my way in to a development job. You probably know what you're doing, but I DIDN'T.

Getting In
Getting in is pretty easy. Some employers will just ask high level questions like, "what's a Singleton", or ask you to email a code sample. My guess is for every 10 jobs, 3 of them have poor screening, and would let you in without question.

Being Discrete
I knew a guy that used his IPad, and was discrete about it. High/medium security companies will screen your Internet activity, so be carefull. Also, watch out for your peers looking over you're shoulder.

Peers 'the biggest challenge'
They may think you're a poser or not-one-of-them. Software engineers would view you the way a musicician views a wedding DJ. I think it's OK, but a hardcore engineer may not.

I heard one coder say, "I'm tired of seeing the stupid people get ahead", referring to cut-and-paste programmers. That's how they see it. Engineers have good work ethics and value craftsmanship, but they can also be ruthless. They may throw you under the bus if you make a mistake.

Quality
Once you get you're foot in the door, you should set higher standards and code by hand. Hand coding usually results in better architecture and debugging.

I'd be careful building a career on out-of-the-box solutions. It's fun to see maverick types get ahead, but it may not be worth it. If your skilled enough to to your job this way, your extra time can be invested in your knowledge and skill.

Best of luck,

Answer 6

I can't find the reference, but Raymond Chen in his The Old New Thing blog once wrote that copy and paste programmers drove him crazy. This was back in the early days of Google or maybe even pre-Google, so the problem was developers blindly copying and pasting from MSDN. The problem he constantly saw was that the supporting expository documentation would contain all sorts of caveats and explanations about when certain API should be used, when they should not be used, and the required setup and tear down steps to use them. However, copy and paste programers would jump right to the example code in the reference section, copy and paste without developing any real understanding, run into some sort of horrendous bug, and then write him asking him to explain what they were doing wrong, or why were Microsoft's APIs were so broken and screwed up.

I don't think any sane person would object to Googling for a bit of syntax, the exact name of a function, or the order of parameters, but it is not a substitute for understanding an API or a language.

Answer 7

There is a subtle but important distinction between research and plagiarism.

Everyone thinks that have a really great interview process that screens out the lousy coders that don't know what they are doing. But the reality is that I've never worked anywhere where the majority of coders were not copy-paste coders.

I've noticed three anti-methodologies for copy-paste plagiarism-code that show up quite often

1. Fun house mirror code. Where the same bits of code are copied and then modified slightly so there are dozens of similar but distorted copies of the same bit of code. The methodology used is how can I get X to do Y rather than how can I do Y
2. It's a dessert topping and a floor wax! Where parts of projects are cloned to solve unrelated business problems because no one knows how to start a new project. Thats how you end up with an inventory system that also manages HR data and prints sales reports.
3. We've always done it this way! When really old tools are used well past prime and despite better easier tools because there is no new code to copy from.

What links these three common examples is a philosophy of I don't know how and I don't care to learn. As long as it works, I can keep my job. STFU.

On the other hand, some copy-paste coders are doing research. They think I need to do X but don't know how! So they look for some code that does X and reuse it. In the best cases they are on their way to their 10000 hours needed to become an expert at which point their examples will be used by the next generation.

As for syntax, I recently found myself unable to describe the syntax for a closure in ruby. But I was able to type it without thought. I'm sure there is a reason for that.

Answer 8

Unfortunately, I will have to say that I'm very much against copy-pasting. I can only stand it where I have to work with other team members, and teamwork always takes the priority over arguments. But if you would come to an interview where I am interviewing you, that would be a very big minus for you.

I know that most people swear by "don't reinvent the wheel" axiom, but it's abused for whole lot of wrong reasons.

I have been coding for like 10 years, mostly C/C++, including tons of low level array manipulations, with all those buffer overflow hazards built into language. And I got to say, through all these years, I've spend most of the time catching bugs and working around 3rd party frameworks and copy-pasted code, than I have been battling buffer overruns.

There are multiple reasons why copy-pasting sucks:

• Unknown bugs, undocumented behavior (you're trading your bugs, for unknown bugs)
• Security vulnerabilities (mostly because of the previous one)
• Code bloat (every copy-pasted code usually weights 5-20x times what you need, which causes longer compile times and so much more places to have bugs)
• Different coding standards (now you have a code base with hundreds of conflicting styles)
• Licensing issues (GPL codez? Please, can I look at your commercial source)
• Coder has no clue (You see that security vulnerability in that copy-pasted class, Ln351?, Take a look again. See why it will fail on XP Home because of line 591?)
• Performance issues (try to track down slowdowns in 5th level hierarchy of unknown spaghetti code)
• You don't learn a damn thing (We have a new project which requires research, new approaches and so on, do you game?)

Despite all that, there are some exceptions.

• STL/Boost/ATL (They are foundation of foundations, even though even STL has some bugs, these will be better than your code most of the time, be careful with everything not STL, even ATL and Boost, especially exotic, less used stuff)
• Security algorithms (try to reuse code from well respected sources, Microsoft/MD5/SSL developers/Intel/C++ board)
• Some file handling libraries (Intel's JPEG libs, PNGlib, that sort of things)

So my approach is - if it's not security, performance critical code, or huge code, DON'T ever copy-paste it! Google, find solutions, see what authors did, analyze how much of that applies to your problem, look up used API documentation, pitfalls and write your own code based on the resulting knowledge.

You will have up to 100x times more compact code, you will have known code-base with known bugs vs. some codeproject sortofworks solution with ton of problems that might or might not come up during testing phase. And you'll learn a lot.

Coding is fast... Understanding, designing the architecture, and tracing bugs is slow, and very, VERY expensive! Especially if you throw in threads. Dangers of C are nothing compared to bug-hunting and workaround coding for unpopular 3rd party libraries/codes.

Answer 9

Being a copy paste coder only works as long as you have a large body of code available on the net. What will happen when you run out of "copyable code" for a new task? What if the copied code is of an older incompatible version? Worse, what if you work on a new platform with absolutely no copyable code. The only way you can survive is with good progrmming skills. It isnt just enough to copy if you dont know what your copied code is doing. You need to know whats happening. They only way you can understand that is by knowing the syntax. When I take an interview , any mention of google is a red alert. Not a deal breaker but a big minus

Answer 10

user21007 is spot on. With .NET, for example, industry leaders, like Hansleman, say flat out that your best bet is to try to get good at the domain you enjoy; it's just too vast. I'm a copy/paste coder. I copy/paste the code from the blogs of industry leaders. I copy/paste code from the books written by those same industry leaders. If I tune in to a podcast of dotnetrocks, hansleminutes or herdingcode, and the guest is there to talk about the domain I work in, they get added to my feeds as a resource.

And Plural Site should be in every developer's back pocket. Pluralsite and many of the books written by the industry leaders come with a fully fledged, architecturally sound, best practices project template in a domain to head you in the right direction.

I'll copy/paste code from Billy Hollis, K. Scott Allen, Scott Gu or Hansleman anytime. Copy/Pasting code from an industry leader is what I would expect, at the very least, when hiring a developer, because they understand that industry leaders write better code than they do and that they'll never publish a book on the subject.

Answer 11

If google didn't exist, I would have a completely different approach to doing my job. I am really, really good at finding what I need with google. From diagnosing and fixing some of my own medical problems, to engineering projects, to code, to financial stuff, google is my primary resource. I use google to find programming books on amazon, which will supplement google. Books are often useful to gain a good overview of a subject when depth is needed.

If you aren't an idiot, you won't blindly pick the first answer that comes your way unless it is right. Often it takes several iterations of refining search terms, analyzing why your code breaks, etc to come across the right answer. And if the source comes from someone who has a bajillion posts and lots of rep points on whatever forum you've googled, chances are it's good information. A lot of factors come into it.

I'm always researching or learning something. I learn so many different things, quickly, and in a reasonable degree of depth (my major was in engineering, so in many cases programming is a means to an end, not the end) that I find it difficult to remember the specifics of any given language. So sue me. I don't have a favorite language, just languages I use for particular problems.

And I quickly forget the syntax. I remember the syntax by looking at my code, or if I can't find it or I'm starting out, by googling. e.g. If I'm scripting in bash, I will have the Advanced Bash Scripting Guide or whatever it's called open, and just click to loops, conditionals, functions, or whatever. The important thing is that I know what I want to do and how to do it.

As a result, I've done some pretty cool things in a variety of different languages. But I don't waste my mental cache on remembering syntax. I certainly know the difference between a for loop and a while loop though. I know data structures, or at least I know where to look them up if it has been a while. I know what non-normalized tables in a database look like (but I will refresh before doing a database related project). I know that if I have a heavy text parsing project, Perl is a good choice. For databases, it's PostgreSQL. For typical systems administration stuff, bash or sh is good.

These are the "take home" messages I have internalized. As far as remembering syntax, I don't. It's absorb, purge, absorb, purge, absorb purge. I must have taught myself regular expressions and then forgotten specifics about a dozen times by now. There are far more important things to dedicate to your mental HDD to than language syntax, IMO. Syntax is arbitrary. Every language has a different one.

Of course, I know the commercial reality expressed by foreyez in his answer and that's just life. I would approach a job interview the same way he does, bone up for that, and meanwhile be able to point to what I've accomplished and my references. What I do works for me. I bet it works for many others.

Answer 12

Depends on the product the shop makes. If it's standard cookie cutter product, a cut and paste culture should be fine. If it's something more demanding technically or innovatively, well that's not gonna cut it.