Having worked on code with a "Choice" variable (and database column!) spelled Chiose - I have to say that spelling is very important.
So, if the spelling mistake was in a variable name - immediate rejection.
I'd give the rest of the code a serious detailed look, and only because the typo (and there is a difference between typos and errors depending on the cause of the error) was in a comment, I'd treat it as a warning flag. If you look at the content of the comment (separate from its necessity at all), it seems to indicate a possible naming issue and a conceptual issue. Why use a public variable to "remember" the footer block? Should the variable have a better name to indicate which state is being saved (before changes?) since it is going to have wide visibility? If it has a very short life, then why is it public at all?
For instance, in a documentation header where a lot of text is being written (not necessarily to be read on a regular basis), I would overlook typos like this:
/* TODO: Logging here is inconsistent
* Add loging and implement error handlign
In addition, regardless of whether you are a native speaker or not, communication skills are possibly the most important skill when you are working on a programming team, and it's especially important (when people do not share the same language) that when they do communicate in English, they are not making it more difficult to understand the concept that they are trying to get across with bad punctuation, grammar or abbreviations that slow down comprehension, "if U no what I mn."
As far as a resume, it has to be proofread over and over. I put an incorrect year on a period of employment in what should have been a minor resume update and it was a total embarassment to have to correct the interviewer and send out new resumes. Luckily I had only sent it to two people.