Years ago I interviewed an employee that wrote "Expert MySQL and PHP Coder" on his resume. He submitted code that was very well written, commented, no unit tests, but, the code was relatively clean. He showed me his web site where it was running and had substantial evidence in his favor that he was the author.<p>During his first programming assignment, his code quality was horrendous -- certainly not anything like the code submitted. He had passed two Brainbench tests that we had asked for and had other Brainbench test results that suggested his coding issues may have been a result of being immersed into a large codebase. Perhaps he wasn't used to our environment, coding style or method of doing things. Programming was a small portion of his job and he made it through his 90 day probation.<p>After the second project, his code quality hadn't improved. I approached him and was told: "I didn't write that code, I maintain that code." His rational for expert: "Compared to my friends, I am an expert."<p>He beat me. He had a friend help him on the Brainbench tests, he presented code that wasn't his and he lied on his resume.<p>If you claim you wrote code and there is no way to independently verify it, I'm going to err on the side of caution. Other programmers that we've interviewed now take a pseudocode test. I don't care if you don't know Python because language is just syntax. If you know programming logic, you can become proficient in a different language relatively quickly. This is much easier in a pairs environment.<p>You will have a hard time convincing someone you wrote any code where your name isn't present on it. If they are hiring you because you wrote the app, then they have some idea. If they are hiring you and you are presenting that application as a code sample, you need to bring a piece of the code that solves some problem in a unique way and be prepared to discuss why that code segment is coded in that manner. Were there other ways you could have solved that problem? Why did you choose that method? If the code belongs to your previous/current employer, don't even think about bringing it.<p>Stand out against the crowd by being prepared. Bring a few copies of that code snippet printed on clean, bright white paper - in black and white. Don't bring me a sample using your editors language color scheme. Have a copy of some function or class that calls that piece of code handy as well. Bonus credit for bringing a copy of the unit tests for that function/class. Keep it light. I'm going to look at no more than two or three pages and one of the other programmers will probably glance over it as well. There is no time to study code during an interview, so, it needs to be a small sample.<p>As an employer, especially right now, I can pick and choose. Why are you the best person for the job? Why is your code superior to someone else's? How well can you debug code and solve problems?<p>That is what we look for. I don't care if you don't know a particular language -- I want to make sure you have the ability to solve problems without needing someone coaching you.<p>As a sidenote: When asked when you are willing to start, if you are currently employed, your answer is two weeks. If you tell me you can start work Monday, I'm going to believe that you have no respect for your job and aren't willing to give that company the respect they deserve by closing out your existing position. If you don't respect them, why would you respect me? If the company offers to throw a bonus to get you to start in a week, your answer is: It wouldn't be fair to my current employer as I need to close out tasks, finish some documentation/train the new person, etc.<p>Everything you say and do during an interview is going to be analyzed. During the last two interviews, I've taken both to a pizza place during lunch to 'take them out of the stressful office.' This is still a test. Everything, and I mean everything you do during that interview is going to be analyzed. Don't lie. When the question is asked about your flaws, don't give that same old answer that you're a perfectionist and sometimes you spend too much time working on a piece of code. We've heard that too many times. When asked why you are leaving your current position, be honest, but, don't disrespect your current position. I might know someone there.<p>All I want to know is, can you do the job well? Are you a better candidate than the others? Are you going to fit in with the existing team? Can you work unsupervised? Are you a leader or follower? Are you going to make my job easier? Are you going to be honest? When something breaks, are you going to try to lie about the problem or own up to it? I've written code for 25 years, I know there are bugs and they can crop up. If you made a mistake, am I going to get an honest answer when you're under intense pressure to get a solution or are you going to shift the blame? Extra credit here if you can solve the problem. Don't ever break something and fix it and not tell me.<p>I am willing to overlook some things. Lie to me, disrespect your current position, complain that your existing boss wouldn't give you a raise because of this or that and your resume hits the shredder the instant my office door closes.