In reality, I have not accepted an offer from any companies who ask me these questions because most of the positions are not exactly what I am looking for.
Also, I tend to disagree. Some of the best security guys out there never went to college. It's hard to expect these guys to know algorithms and datastructures even if they are really gifted exploit developers, or the like.
edit: To clarify. What this really shows is that I am not being interviewed by a security person...ie there is no special interview process for my position compared to a regular software engineer.
My cousin's employer has started using Javascript Under Pressure [1] as the first round of technical interviews - it lightens the mood, and fully half of the people applying for a front-end development position at his company can't finish the first one, which is literally to write a function that returns the argument multiplied by two.
However, getting one of the tests wrong in 4th problem because of two chinese UTF-8 symbol having more length than "tiny" kind of irked me and reminded me why I do not do webdev.
I suppose this is actually a good kind of test, because real webdevs would actually have learned not to use s.length but use something else.
What is it though? This seems like a Javascript fail more than anything else.
Gah, that made me jump.
That would still be a notable effort, but I'd like to know who I'm hiring and for which qualifications (cat herding or design and implementation).
And would that matter?
When the teleprompter reading person applies for a security job they're supposed to do alone? yes.
Interview Process is: HR filter -> Manager interview -> Grandfather (Manager's Mgr) interview -> Peer meeting
The peer meeting isn't conducted in an interview setting. It's more informal, adapted to the needs of the applicant. It could be a lunch or a dinner and once it was even participating together at a hackathon.
We carefully select peers against "buddy bias" and encourage diversity in the workplace.
Our company is over a period of several years very successful in recruiting and have very little turnover. The biggest drawback could be that we are "too picky" and thus (at times) have problems growing fast enough.
The secondary reason to ask these easy basic dev questions is an attitude check. Someone who gets personally offended at being asked to do something that is easy for them has a risk factor for being a poor teammate.
I see statements like this thrown around a lot. Do you have precision/recall/F-measure numbers to back this up?
I wouldn't ask a candidate to implement a min-heap (mostly because it's kind of obscure and I'd have to think about it) but a depth (or breadth) first search is something I'd expect any competent candidate to rattle off in a heartbeat, just because it's such a fundamental cs principle that gets used in lots of places and, unlike things like sorts, doesn't really have a good library to fall back on in practice.