True story: in my interview I was asked how I would extract entities from an HTML page. I suggested using OpenCalais.
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!
Side note: /&([^&;]+);/g won't actually parse character entities in HTML correctly. There're a number of corner cases in the HTML5 spec for historical reasons, and this is one of them. In some cases, it's legal (well, it's a parse error, but the parser must return the specified entity) to leave off the trailing semicolon. Except in attributes, where it depends on what the character following the last character of the entity is. The particular cases are enumerated in a table that is over 2000 lines long.
Here's the meat of my point. The correct answer when writing software is "use a library". The correct answer when answering an interview question is code with minimal dependencies.
>Here's the meat of my point. The correct answer when writing software is "use a library". The correct answer when answering an interview question is code with minimal dependencies
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".
It's an attempt to understand how you would solve problems of the class that the question is of, not an attempt to get a solution to a specific problem.
Not using a library when you should have is a problem solved by a 20 second code review.
Code reviews are normally done after the developer has spent some time on the code. That is fine that it takes 20 second to determine the code is totally worthless, but the developer has already wasted DAYS of effort.
I think you're misunderstanding the question. It sounds to me like they're asking about named entity recognition[1], which is a bit more involved than just having to write a parser (unless you're crazy enough to try parsing it by hand). And it's certainly more involved than I would expect someone who works in Developer Relations to have to answer.
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.
The position she was applying for was not a programmer job; it was a community manager position, and doesn't involve any programming apparently. So your arguments, while valid, are besides the point.
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!