http://www.whatwg.org/specs/web-apps/current-work/multipage/...
The example is particularly instructive: ¬it; is parsed as ¬ followed by "it;", but ∉ is parsed as a full entity.
So yes, even for HTML entity parsing (which wasn't the question she was being asked), the correct answer really is "use a library".
Which can be paraphrased as:
"Here's the meat of my point. The correct answer when building a wooden shack is "use a hammer". The correct answer when answering an interview question about building wooden shacks is to make the hammer first".
"Performance under modern software development interviewing practices has a very low correlation with on the job performance."
Not using a library when you should have is a problem solved by a 20 second code review.
Yep, the problem here is that people use parameters starting with an ampersand without escaping the ampersand in URLs used in <A HREF=>.
The reality of the situation is that the author should probably have just taken the question that the interviewer was a techie who didn't know how to ask about soft skills.
Also, I'm still going to use my version as an interview question. I like it :)
IMO- I agree: looking into the box and understanding it is much more fun and provides more than just using the black box.
So you're interviewing for a job as a programmer for a search engine, and your answer to a simple parsing / text processing question is, "I'm going to use some proprietary black-box third-party API to do the parse", and then you refuse (on moral grounds?) to elaborate on how that service could possibly be implemented? What?
I could understand something like, "Oh, I did that last week, and we used the OpenViagra API." OK, cool, but the follow up question is going to be, "but if you had to do it yourself, how would you do it?"
This is a good question for many reasons: for one, it's a basic "how do you handle parsing" question. Parsing comes up all the time in programming, and it's good to know if the candidate knows about regular expressions, parser generators, parser combinator libraries, etc. It's not about "do you know how to get HTML entities", it's about "do you know about parsing".
There's also something weird about relying on third-party APIs for simple programming tasks. Sure, if you need to know your current location, you have to depend on a bunch of orbiting satellites with precisely-set atomic clocks. But if all you need to do is /&([^&;]+);/g, then write that one fragment of code and move on with your life. The simplicity is well worth not having to set up a TCP connection, wait for it to be established, generate a request, send it over the network, wait for a response, time out and throw an error if you don't get one, parse the response, and finally return the answer to the calling code. Think of all the bugs you're going to have to fix with this approach!
I'm going to start asking this question, just to see where it leads. If the answer is more than one sentence, it will give me valuable insight into how the candidate solves programming problems. If they answer, "well, I refuse to do that", then that's valuable insight, too. All in all, a great interview question!
So anyway, technical interview questions are not about getting things done, they're about thinking through problems. Parsing HTML is a solved problem, and of course you're going to delegate to a library. But tomorrow, you're going to have a very similar problem to solve that is more nuanced and difficult to explain in 30 seconds. And that's what the question is really getting at; if you can parse HTML, you can parse the weird config file format you invent tomorrow.
Google's interview process makes me want to work at Google!