Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question

migrated from stackoverflow.com Mar 30 '11 at 1:54

This question came from our site for professional and enthusiast programmers.

totally misunderstood the question title. Came in here thinking "wtf wouldn't they? google has GREAT coders by most all accounts" –  Andrew Heath Mar 30 '11 at 3:12
The difference is that a cut and paste coder says where I have done that before, finds an example and uses that. A google coder (using google as a verb) says where has this been done before, looks at a number of solutions then chooses the most appropriate. –  dmc7337 Mar 30 '11 at 3:27
If pasting in snippets from all over without knowing the syntax well has resulted in greatly increasing your code quality, I'd hate to see your code without them. –  David Thornley Mar 30 '11 at 16:03
How would you feel if your doctor told you that he doesn't really remember what all those pesky organs were for, he just enters your symptoms into Google to find the cure? ("Ah, apparently you should order these Nigerian Viagra substitute pills...) Or your lawyer? Or the guy that did the structural analysis of your house? –  nikie Mar 30 '11 at 16:09
If your doctor is too stupid to be able to differentiate between a quality site and a site made by a Nigerian scammer, he shouldn't have gotten his degree in the first place. FWIW one of the doctors I've had used the net to supplement his diagnosis. He knew the term for the particular mole he thought I had, and double-checked his diagnosis by comparing it with examples on a particular medical site. This extra step beyond what your average GP does increased rather than decreased the accuracy of his diagnosis. –  user21007 Mar 31 '11 at 0:12

12 Answers 12

up vote 16 down vote accepted

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

share|improve this answer
Having interviewed with both Microsoft and Google, I can confidently say that they don't simply ask for boring programming questions. They asked some design questions, and some fairly non-standard programming questions as well. –  apoorv020 Mar 30 '11 at 9:43
So many "Google" answers I find I have to tweak in some minor or major way to adjust to the subtleties of my problem. I hope you have enough "academic" knowledge to tie what you find into a cohesive piece of software and when something goes wrong you can debug the thing. –  Doug T. Mar 30 '11 at 12:39
to be able to search for an answer quickly you typically need to know 80% of the solution anyway –  jk. Mar 30 '11 at 12:48
I have to say I hate this answer. I agree that interviews are mostly the same old done to death questions, or completely irrelevant questions. However, I feel your answer is an excuse to just fluff through the basics of programming to get through the interview as long as you have a high level understanding of code. –  Shaded Mar 30 '11 at 13:22
Google should serve as a pointer to a solution, not the solution itself. A programmer should try hard to solve the problem by themselves first. Failing that they should look for possible solutions and then re-try. If they still fail then its ok to ask others. But it should not be the first port of call! –  Darknight Mar 30 '11 at 14:37

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.

share|improve this answer
However, clicking "I'm Feeling Lucky" does not count as pseudocode. –  Kaleb Brasee Mar 30 '11 at 2:12
Mike is right. Problem solving is what they are looking for. In an interview I was asked to solve a a problem regarding a company moving pianos. It had nothing to do with programming :) –  Steven Mar 30 '11 at 6:37

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

share|improve this answer

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

share|improve this answer

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.

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,

share|improve this answer
+1. You just made me realize that a candidate could use his or her iPad during the coding tasks in the interviews at my company. –  nikie Mar 30 '11 at 15:36
@nikie, tin foil wall paper! –  user1249 Mar 30 '11 at 17:05

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.

share|improve this answer
ever used a code generator? Or a class template in your IDE? If so, you're a copy/paste programmer by the strict definition. –  jwenting Mar 31 '11 at 6:25
I think that the definition of copy-paste coder was more like "how to solve X, www.somesite.com, copy, open solution, paste, done". But concerning IDEs, I don't use auto-generated code much, most of the time you spend more time cleaning the extra garbage than writing clean class from the scratch. WTL over MFC, templates over generated classes, etc. –  Coder Mar 31 '11 at 17:33

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.

share|improve this answer
Charles - is that by chance your answer at Workplace.SE? Name is grayed there, but the notice on the question says "migrated from Programmers" –  gnat Nov 13 '12 at 13:05

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.

share|improve this answer
+1, but I think no (intelligent) interviewer would have anything against what you call research. If you say something like "oh, you want a shortest path through this graph. I can come up with an O(m) algorithm, where m is the number of nodes closer than the shortest path. But I think there's a better algorithm, so normally I'd look it up" - I think that would be fine for everyone. But if you can't solve FizzBuz without using Google... Well, my colleague will show you the way out. –  nikie Mar 30 '11 at 15:47
nikie, I've had quite a few interviews where if you didn't know the most obscure little things by rote it'd count against you. And what's fizzbuzz? It's never come up in my line of work so why am I supposed to know it? If you're assuming domain knowledge from someone, better mention it explicitly in the job description as a requirement (not a nice to have). –  jwenting Mar 31 '11 at 6:24

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.

share|improve this answer

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

share|improve this answer
+1. And if someone mentions Google for syntax issues in their favorite language, that is a dealbreaker for me. –  nikie Mar 30 '11 at 16:03

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.

share|improve this answer
Totally agree, except that I no longer have the Advanced Bash Scripting guide open as it is quicker to use google than to look up the index of a book. You are right though that books still have value but not to the same degree they used to. –  dmc7337 Mar 30 '11 at 22:35
You're right. I'll only have the ABSG open at the beginning of doing something in bash, if it has been awhile, or I'm not starting out by modifying an existing script. After a short time I'm finding the example I need in my own code, V to select a block in vim, Y to copy it, p to paste it, dd what I don't need, then edit the remainder. e.g. I'm scripting now, but I don't have the ABSG open. When I do, it is easy to CTRL-f, type in e.g. loo -> will go to loop, click, you're there. –  user21007 Mar 30 '11 at 23:02
About the books - I edited my answer to say that books are useful rather than necessary. For complex, difficult subjects, a couple of the best physical books as judged by amazon comments/ratings is often very helpful. For many things, google will suffice. –  user21007 Mar 30 '11 at 23:07

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.