When asking an interview candidate to write a program on the whiteboard, do you expect the candidate to write code that is syntactically correct?
I had two candidates, one of which wrote a syntactically correct program but the logic was not up to the mark, and the other had the logic better written but the syntax was crap.
I favor the first candidate.
I would favor the person who was able to reason through the problem, come up with a good solution, and then explain their solution to me. Even if their logic wasn't 100%, if they were on the right track and were reasoning through the problem, asking the right questions, and going down the right path, that would be my winner.
When you are developing code on the job, you have many tools - IDEs, compilers, static analysis, unit tests, integration test, and acceptance test procedures - to find mistakes in syntax and logic. If you're writing on a white board, you don't have these tools and you're bound to make mistakes in syntax (forgetting a method name, a semicolon, a brace), and I can forgive that.
My only question to you: Why are you having your candidates write actual code on the whiteboard, instead of focusing on algorithms, design strategies, and logical thinking? Programming languages change, problem solving doesn't.
I would favour the second candidate. Logic can be hard (very hard, sometimes) to get exactly right. Syntax can be very easy to get right when the IDE and compiler and other assorted tools help out.
The first candidate may never trigger a compiler error, but if his code often fails in all sorts of weird (and less weird) boundary cases, his knowing where to put a semicolon isn't worth that much.
Depending on the actual syntactical errors, I guess I would prefer the second candidate, because checking syntax is usually better left to the machines.
Errors like missing semicolons, forgetting closing brackets, forgetting commas in argument lists, etc, even non-syntactical errors like switching the argument order when calling a function usually get caught by the syntax highlighter, the compiler or when the code is run the first time, all things one usually uses, but are not available on the whiteboard.
However, there are some errors, that, while technically only syntax errors, show a deeper missunderstanding.
As a somewhat artificial example to get the point across: consider a python programmer who prefixes all his variables with $, or writes the for-loop as for list as item. Technically, both are syntax errors, but even with only limited exposure to python one should know how about legal characters and the for loop. It would be a good guess that the candidate knows php (or perl?) and tries to bluff about his python skills
I would prefer the second candidate, on the theory that a whiteboard has more impact on syntax than on logic, and that syntax mistakes are easier to correct - either the IDE or the compiler can usually do it.
I've been writing SQL and CSS (the most simple and basic languages I know) for nearly 13 years, and I can't always remember the syntax.
My friend (also a developer) works for a hedge fund, he can never remember the syntax for an insert statement.
We both end up on W3CSchools, I guess we should be embarassed (he has a degree, and I have a PhD).
However, to be honest, I think we have our priorities correct. Syntax is not an important skill.
Few thoughts about syntax errors...I was wondering if you had made it clear to both that syntax needs to be correct. Sometimes people assume that pseudo code is OK.
Also, if someone claims years of experience in a language and can't make the basic syntax correct, you should doubt the claim.
Syntax errors can vary, so if someone forgets a method name it is OK (to me) but if someone does not know how to refer to a method in a class (dot notation) or does not know a basic think like the syntax for a simple class, then chances are this person has not used the language for a long time.
For the guy who did not get the syntax correct, do you think that his mistakes could have been easily fixed with the appropriate language editor? if so, I vote for him.
I guess what I am thinking of here is that syntax errors are acceptable within limits.
A junior assistant programmer or even a software tool might be able to find and fix bad syntax if the logic is good. Bad logic... any fix is much less assured. All programmers will screw up. I would pick the one who's screw-ups are easier to spot and fix.
Unless the problem is subtle, and most interview questions aren't, the first candidate is disqualified. It's a lot easier to learn language syntax than algorithm design. I will hire a programmer with a history of successful work in multiple languages, even if he has zero experience in my current technology. This isn't the best strategy if I need something done today, but if I need a lot of things done over the next twelve months, then I will always pick general ability over specific experience.
Syntax checking is what a compiler is for. A compiler can't make your logic better, but it can tell you how to fix your syntax. That means that any job where you write code using a compiler, the logic is inherently vastly more valuable than being syntactically correct.
Interviews are always awkward situations - you can tell this because when you walk out, you immediately think of all the things you should have said, or the right answers to the questions and the things you wanted to ask them but forgot. So, given this, expecting perfectly written code with no syntax errors is being unrealistic.
Additionally, your expectations of perfect code (on a whiteboard!) may not match the interviewers - for example, at one interview I attended I was asked to write a class, which I did, only for the interviewer to pull me up on not putting in a copy constructor. So I wrote one in, which did nothing but set a = b, but that was enough to satisfy him. My expectations of the problem didn't require a copy ctor, so I left it out as extraneous to the problem being solved - I didn't expect to have to write fully compliant, compiling code (to his hidden coding standards), simply show my understanding of the solution. (this same interviewer didn't like my solution either, it wasn't how he would have done it so obviously I got it wrong, sigh).
If you want working code from an interviewee, give them a compiler. Then don't complain when they invoice you :)
So go for the person who knows what he's doing, not the one that can parrot the words but doesn't understand the meaning.
During an interview the interviewr is more interested in seeing your
Syntax though is not so important but it does hold a prominent place while solving a problem, with major mistakes in the syntax you cannot expect to get the interviewer impressed.
The proper logic and syntax combined together can do the trick for you in an interview.
A small or minor mistake would never cost you much if logic is good enough.
More over there are may IDE available that could easily make syntax of even any in proper shape. But to use which method where and when and most importantly WHY, would only be known to a guy with the proper logic and knowledge of the actual subject.
I hope and urge you to provide something more than a white board or a notepad to write the code.
I would go with the second candidate...
Well some people want great Java Developers, great C# developers, great C++ developers, etc. If that's your case then go with A and more power to you. One concern I would have is if they cannot reason to solve the problem how can you expect them to reason and solve your business problems?
Other people just want great developers who can work in whatever language is required. They think of/model the problem and then implement it in whatever language. If you suddenly decide .NET sucks and switch to Java or vice versa, these are the developers who won't jump ship or refuse to learn. Also if you get some type of automation package/calculation package which has a proprietary language and you need some tasks automated, these are the types of developers who can do it. Real life example...I needed to figure out a custom proprietary scripting language for a mapping software package in order to extract zip codes for custom drawn regions for an old employer. Another example....my current employer has a proprietary property management system which contains a custom language for writing reports... In any case, if you get someone who cannot think logically but is familiar with the syntax of language X, you will be in trouble when situations like this comes up where you need someone to work in a different language.
Also on the white board there is extra pressure/nervousness so no one is at their best. Plus I highly doubt that when coding you get it perfect every time. I suspect you compile or just run and find some errors. Additionally it depends on the language. C is small enough that you can probably memorize most of the language/core libraries (though I wouldn't require it). Java/C# have such huge libraries (with such frequent changes) that memorizing the library is out of the question.
Also knowing multiple languages can work against you. C# and Java interfere with each other with me. But knowing multiple languages can also broaden your perspective, especially if you know a scripting language and a functional language in addition to C#/Java.
Still if both candidates solve the problem with correct logic, the guy with correct syntax probably has an advantage. If one solves the problem and one doesn't, then personally I would go with the guy who can solve the problem.
Still if someone claims to be an expert in Java and cannot declare an array of use an if statement or while loop, they might be lying. But I might understand if someone is an expert in Java but has been dong a lot of C# lately and tries to do Map or something.... Also if you get into specifics of the library, or someone does myArray.length instead of myArray.Length or string.length()/string.Length/string.length instead of string.length()... Minor stuff I would forgive. Or if they forget the argument order of some library call. Or a typo/semi colon here or there....
I won't take any of them.
A good syntax is useless if the programmer is not good at problem solving. And a poor syntax for a given language means the candidate does not feel himself comfortable with that particular language, maybe for a lack of direct experience.
Anyway, logic is far more important than syntax.
It, as always, depends. If the syntax errors are relatively minor, I'd ignore them. If they're earth-shakingly huge, I'd pay attention to them and try to infer why they are there.
I think logic errors are worse than syntax errors, the latter can almost always be caught mechanically, the former less so (depends, to a degree, on what language you're writing, some classes of logic errors are caught by sufficiently-advanced type inference and checking).
It would definitely depend on the position for which the interview is, and probably on the language as well.
Working on C++, having a guy stuttering on syntax is scary. C++ is full of dark corners, traps lay basically everywhere. A stutter on the syntax means a poor exposition to the language, and C++ beginners make lots of mistakes (not to say that others don't from time to time).
To answer your question, then:
There is only one caveat: people acknowledging their lack of experience. Ideally people should code in their language of choice, or pseudo code if they so prefer (students for example).
True story, I still forget the syntax of C# events when I have to write them out by hand. It happens in interviews sometimes. I don't have the issue when I code at a keyboard.
Choose the guy who can code, not the one who can't but can remember the syntax.
When I'm writing code on paper/whiteboard, even for a job interview, I basically skip a huge chunk of the syntax. I don't use semi colons, I fudge method calls, etc. I'm more likely to write a sentence explaining 4 lines of really basic code than the code itself. Really, I use a php-like pseudocode, and talk through what I'm doing, while I'm doing it, and jot down quick comments to explain things I gloss over (which are, in theory, nothing that's actually important to the program)
My goal when coding in an interview is to show how I solve the problem, not to dictate something a typist could enter in to Notepad and have run.
Long story short: I think you should consider why the first programmer had crappy syntax. He very well could know it but just considered it irrelevant for the interview, and preferred to focus on the parts of this job that are hard (logic and problem solving).
The person who cannot logically satisfy the answer is unqualified. There are too many people in our industry producing garbage code that complies but doesn't actually do what it should do or handle errors or edge cases.
The second person may or may not be unqualified depending on the type and number of errors and the difficulty of what you are expecting them to write. In SQL terms (the language I write in), the person who can't remember the syntax for an explicit join is unqualified for a job requiring you to query a database - no exceptions; the one who can't remember how to to a recusive CTE (but who knows they exist and tries to use one) is not. In other words, I would expect the syntax to be more correct for the basic code you write all the time but not for things done only occasionally and not for complex syntax.
If I was considering a person who I knew had excellent qualifications in a related area but only minimal knowldge of my specific language, I would probably be more forgiving of syntax errors as well. I'd rather hire a great Oracle developer than a mediocre SQl Server developer for a SQL Server job (Of course a great SQL Server person would be best) and would not expect that person to know SQL Server syntax if they could show me how to do it in Oracle. Same thing with Java and C# people, the person with excellent problem solving skills beats the one with excellent language skills, but the one with both wins every time (they are just hard to find sometimes).