I don't understand how there can be a good hacker that does not, at least on some intuitive level, get such basic data structures or algorithms. I don't mind if someone doesn't know what depth-first search is, but I should be able to explain it quickly and they should be able to come up with at least pseudo code. The relevance of this to software engineering roles just seems too great.

Cramming these questions online does not work. I don't know what Facebook/Google et al are doing but I can spot a candidate who studied interview questions from a mile away. They may bang out a DFS by rote but that's just warmup; they should be able to talk about details, deal with changing requirements, discuss the algorithm/efficiency/design of their solution, be able to talk about underlying data structure primitives, etc.

To be fair the grandparent was talking about a specialized position in security engineering for which the generic coding interviews could be a bad match.

>I don't understand how there can be a good hacker that does not, at least on some intuitive level, get such basic data structures or algorithms.

And I don't understand why someone who spends his time up to the eyes in crypto proofs, exploit code, and research articles should have to cram for an Algorithms 1 exam for each interview.

I've seen these questions used well (had a neat discussion with a start-up CEO in Boston once about reimplementing a toy Twitter in Scala), and really brilliantly (another start-up in Boston once asked me to describe my favorite algorithm and got a short, ad-hoc tutorial in lottery scheduling), and really, really badly (BigCos asking stuff you'd see on an undergrad-level exam from years and years ago).

Strangely enough, I'm praising the two startups that didn't offer me a job (though I'd really like to reapply to that second one), and condemning the BigCos (you know who I mean) that did offer me a job.

You're right it isn't well suited for security people.... But is it well suited for software engineering types? Most code people write is not a search sort insert etc. Most of the details of using these data structures are invisible in oop and the difference is only what class was instantiated.

I'm not saying it isn't important to know, but I think there are better indicators for someone who will perform well on the job

Sure, but these tests are necessary without being sufficient. I'd expect that performance in these tests is predictive up to a certain level but that being really good at them versus just performing decently is not nearly as predictive for actual job performance.

Similar story here. Now not only these "big" companies as Facebook, Google, Microsoft focus mainly on algorithms and data structure during interview, to my surprise some of the early startups ask heavily for whiteboard coding...

It's no surprise these companies rejects many really good hackers (at least from people I know... yes, I admit the small sample size) and accepts these just optimize for algorithm preparations by doing a set of online coding problems.

The startup industry saw the same kind of interviewing voodoo in the 90s, copycatting how Microsoft conducted them.

They're asking you that because there are lots and lots of candidates who look great on paper but don't actually know anything. I have personally met several.

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.

Believe me, I can and do implement them, but I always do so backhandedly. ``I am a security engineer, what does this have to do with security''.

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.

I really doubt that it's possible to be a top exploit developer and yet be unable to implement BFS/DFS in under fifteen minutes. Some things really are just the absolute basics. If it never goes further, then that's a problem, but there are enough people out there who can't write ten lines of code that you have to weed them out.

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.

[1]http://games.usvsth3m.com/javascript-under-pressure/

Relaxing with a few beers at home, this was fun. "12 minutes, 19 seconds for all 5 levels. Well done!" Don't care that I'll be blasted for being a slow old man. Come on, you know you want to! Stallman, babbage, lovelace and torvalds await.

That was great fun for non webdev Javascript coder, and I was about 3 mins in and finishing 4th problem.

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.

I just did that and I'm pretty sure I used "s.length()" and I didn't even notice any Chinese characters.

I had to check typeof (apparently those two chinese characters are not a string) to fix this, again this is actually useful, but was not expected given the ease of first 3 problems.

Please put a warning if you link to a site that auto-plays audio.

Gah, that made me jump.

Ok, that JavaScript under Pressure is a lot of fun and it would make a great ice-breaker.

I doubt "the best security guys" end up with the same interview experience. If you are widely known in the industry as an expert or the best at something I think the process to obtaining a job is significantly different from someone applying for jobs.

Not here. I am way more scared of the "best" candidates than I am of the normal ones.

I would imagine with someone like Bruce Schneier, you'd be paying them for the name and not their output. Google did it with a bunch of legendary computer scientists. Their role is mainly to get top notch junior people to come work there.

Really, that's surprising to me. Would people of Bruce Schneier/Fyodor/et al stature go through the same interview process that everyone else goes through? I'm pretty sure they wouldn't at a big company but you guys do things differently (for the better it seems) so maybe?

Yes, they would. I am 100% sure of it.

For all I know Fyodor is a collective of cheap developers and designers from far-far-away coordinated through an outsourcing agency with a single front figure reading from a teleprompter.

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).

Do you also feel that Bruce Schneier could be a collective of cheap developers? That seems like a pretty odd position to take give Fydor's identity is widely known. (http://insecure.org/fyodor/)

"For all I know Fyodor is a collective of cheap developers and designers from far-far-away coordinated through an outsourcing agency with a single front figure reading from a teleprompter."

And would that matter?

In general? No.

When the teleprompter reading person applies for a security job they're supposed to do alone? yes.

What kinds of questions would you expect to be asked for an interviewer to distinguish you from someone who looks good "on paper" but is a big phoney?

We apply a "peer" interview model, where candidates before being offered a job have to sit down with two of their future peers. This takes care of the phoneys as their (already successful) peers see through the posing.

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.

Exactly. A false positive in the interviewing process (hiring a dud) is much more likely than a false negative (turning off a great candidate).

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.

> A false positive in the interviewing process (hiring a dud) is much more likely than a false negative (turning off a great candidate).

I see statements like this thrown around a lot. Do you have precision/recall/F-measure numbers to back this up?

The most famous example I know of is the guy who implemented a FizzBuzz test and thereby eliminated the vast majority of programmers who otherwise appeared qualified on paper and in person. I don't have the link handy but I think it was covered in codinghorror.com.

I have been very interested in running a similar experiment myself, but alas I am not a hiring manager. As I recall from that example, there were no details of what counted as "qualified" on paper and in person.

> [...] unlike things like sorts, doesn't really have a good library to fall back on in practice.

Depends on your language. Some are better able to abstract and express this `pattern' as a library.