Whenever I am asked to complete a technical coding test, I always google the internet for answers and read through three or four examples. Then I ignore everything they did and write it my own way. Let me go into more detail for why this is necessary.
Most of the answers you find on the internet are only going to be technically correct.
For example, if you have a question about how to do X there are very likely multiple ways to do this regardless of what language or frameworks you are using. Some of these will be scalable - some will not. Some will use methods that are rightly deprecated (Eval!) and some will not. Some will be out of date for modern programming languages, and some will not.
Most answers will NOT work in a real-world situation. Are they quick solutions? Yes, but they are usually quick for a reason.
With more then one way of doing something, you have a chance to demonstrate mastery, not just understanding.
This is your chance to demonstrate the specific expertise you bring to the table by being able to demonstrate that you understand the different approaches and when to use which one. For example, I will sometimes provide TWO different solutions, with an explanation of which solution fits which situation.
"You didn't say if this code was meant to be re-useable, I usually assume reuse-ability, but the fast example is here. However, if this was something I was expecting to re-use, I would structure it like so."
If you can Google a solution, expect that the interviewer can to.
I know in the past when I have looked at coding samples submitted by prospective employees, I have put portions of their code into Google to see if they copied it from somewhere. Typically if the code is presented that way, with no explanations, I will reject the candidate outright. If they provide explanations, good on them.
It's important - if you use any other copied code or if you use a framework - to explain why you selected what you did, and not just include them outright. Otherwise the interviewee will simply assume you googled what was best and don't understand the nuances of what you selected.
Interviewers should be more interested in your thought process then your technical skills.
Frankly, anyone can google enough code and with a low level of skill, slap something together these days. Really good technical tests will require you to submit a repository history along with your submission to ensure that they can follow along with how you developed it. This is much harder to fake, and gives a much better idea of how the candidate came to the solutions that he came to.
Copying someone elses code gives them no reason to hire you over anyone else, and no insight into how your mind works and if you are a good meld for their existing team and company culture.
Showing and explaining multiple approaches shows that you took the time to research the project, did not fire from the hip, and put care and consideration into even the most insignificant work that you do.
This cannot be stressed enough - as a hiring manager I want candidates who know what they don't know and have the capability to learn. And as a candidate, I want a job where going the extra mile will be recognized and mean something. Taking extra care, providing additional information and coding samples shows the company want kind of a candidate you are AND gives you a chance to feel out what kind of company they are doing to be.
While copying and pasting might be the quick solution - companies that accept candidates who are just able to copy and past technical test answers quickly and easily are going to have a much poorer base programmer then companies that reject them, and probably aren't a place you are going to want to work at for very long.
