I recently interviewed for a security engineering position at a startup, and while I got offered the job, the interview was quite silly.
The first thing I was asked to do was to write a lisp interpreter. It was a pretty trivial task, but it left me scratching my head since not only did it not tell them about whether I would be qualified at all, but I had explicitly avoided writing parsing code since I found ANTLR during undergrad.
In the end I wrote a basic stream abstraction and wrote my lisp interpreter on top of it with no real difficulty, but it was a completely stupid question. I told them on the third interview that they weren't asking me anything relevant and I still got another question later on about how to iterate over a tree in a specific order.
Part of the issue was that most of my interviewers were fresh out of college, it was literally their first job and they had no idea what to ask besides the kinds of questions they had been asked in their own interviews.
In the end there were a lot of other issues that made me not take it, but not knowing what is necessary seems pretty typical wrt security. However, in those situations you want to have wide latitude to affect change because the thing they hire you to look at is probably not really where their problems are.
Infatuation with "coding competitions" and high flux intelligence tasks is often an anti signal.
Sure, what they demonstrate looks good at face value, but unless you attach a micromanager over their tasks, they'll constantly deviate to the new-shiny every week instead of staying on task for the long haul.
I know even YC has been bitten a few times by accepting people who are top-performers in very narrow contexts (e.g. people obsessed with winning coding competitions every single weekend) only to see they can't do anything coherent for more than a week at a time.
Just because someone is great in a narrow context doesn't mean they can carry that over the months and years needed to deeply iterate (and suffer through the low points) on successful projects.
Basically, imagine that there's two ways to graduate college with a CS degree - you're either the kind of person who's smart enough to get things if you work your ass off for them, or you're a genius and you coast through. If you're a genius and you work your ass off, you get a doctorate or found a startup, and aren't in the candidate pool. So you wind up with a choice about what to compromise on: work ethic, or smarts.
Ideally, you compromise on whatever makes the least difference to your organization, compared to your competitors. Hiring smart/motivated people out of non-traditional backgrounds is a great option for this.
They're more interested in how you approach real world issues (the questions I got asked were conceivably real-life issues a company like Google would face with its products). If you can solve that issue by applying efficient and well understood data structures and algorithms, then that indicates you understand the problem space and solutions that may apply.
It's not like they get you in a room and ask you to draw a linked list or a binary tree.
I had two phone interviews - the first had quite a few questions about my prior experience (over a decade) and how to approach real-world problems from a high-level, including some that I had worked on at my current position. The second was primarily purely technical, but did have some more theoretical/project-management-y type of questions. In neither one was I required to write any code.
On-site: one interview was entirely whiteboard-coding (in a collaborative style), on a set of related generic problems. Next was one with a set of problems related to my experience. Third was almost entirely telling war stories. Last two were some generic graph-theory-type problems and some simple problems involving data structures relevant to the my area of experience.
As I hadn't interviewed for anything in 11 years, I did spend some time brushing up on my basic algorithmic theory, and essentially followed Steve Yegge's suggestions. I honestly think I probably could have done the vast majority of it without any studying, but spending time practicing solving problems on paper (with a countdown-timer as an artificial pressure-inducing device) certainly did help me, I think, in the on-site. No amount of memorization could have helped with most of it, aside from basic knowledge that anyone who's taken Data Structures should know.
I didn't find the process to be insulting at all; it was an enjoyable challenge. Everyone I talked with on the engineering side of things I can only say the best about, and so far as I can tell the team I'll be with has some really great people. I am a more senior developer, so perhaps I got a different experience than some.
I was later declined. Had a couple of friends at google ask the interviewer. He said I was declined for not finishing my data structure.
Their interviewing process was quite frustrating. I'm fine with getting declined but not under those circumstances.
That was my first technical interview over the phone so it was pretty obvious it was related to that single interview. One of the Googlers I knew that checked the system said the same.
I had the impression that they all had to agree for a hire. Hence one no means no hire.
Once you get to that point, though, if they asked me "and how would you invert the tree in-place?" I'd answer "well, first I'd make sure we aren't just using a tree structure that already knows how to invert itself, or could easily be extended to know how. Then, assuming that didn't pan out, I'd google 'in-place invert binary tree' and read three or four solutions that already exist to burn the semantic structure of what I'm about to write into my head so that I don't subtly screw it up and have to fiddle with it for the next hour when I could be coding something else. Then I code it."
And that should be enough.
Another in the same interview got in my face (this should be easy) when he thought it was taking me too long too multiply two numbers like 637 and 41 during an estimating problem. I understand the point of most of these questions is quick and dirty estimation (600 x 40), but seriously...
637 is an awkward number, we'll start by rounding up to 640: 640 * 2 = 1280, anyone in tech knows 2x that is 2560.
Make up the missing 3: 3 * 4 = 12, 2560 - 12 = 2548.
2548 * 10 = 25,480.
25,480 + 7 = 25,487
25,487 + 30 = 25,517
25,517 + 600 = 26,117.
That said, I did make a screw up when calculating it, and added the 637 before multiplying by 10 (which may have been the differentiating part of that question, combined with the intentional stress, to see how you cope with pressure? Although I didn't sleep last night, which might be the cause :D). I dunno if they wanted you to do it as quickly as 600/640 x 40 though, which obviously makes it much more difficult.
Afterthought, due to sleep deprived state, quicker way to solve:
600 x 40 = 24,000 40^2 = 1600 25,600 quick and dirty, for accuracy: 3 * 40 = 120 25,600 - 120 = 25,480 25,480 + 600 = 26,080 26,080 + 37 = 26,117.
Sorry, this comment turned into a bit of a ramble.
And yet the OP was turned down for not being able to invert a binary tree (based on limited information, etc etc.)? What do you feel that is, if not a "whiteboard this algorithm" question?
As for many of the other companies who try and emulate Google - this is exactly what they do.
Your source is a series of salty tweets.
And in either case, my original comment was directed at the idea that "algorithmic interviews provide false negatives, but not false positives".
You say that as if it's a good thing. Do you expect that most people could be e.g. effective teachers, effective marketers, or effective taste-testers, with no previous experience?
Obviously he didn't give 1 shit about "how you approach the real world issues".
On the other hand, knowing that DFAs are equivalent to regexes are equivalent to NFAs is already a step of theoretical knowledge that any "Just let me write code" so-called "dev" is likely to complain about being asked for.
I too don't remember much.
Regardless, I only meant to make the point that I disagree with the comment "They're more interested in how you approach real world issues" and that this statement is false: "It's not like they get you in a room and ask you to draw a linked list or a binary tree"
edit: by "expert" I just mean something I'm particularly skilled in, not something I'm an authority in from theory to practice.
It's important to know how a person approaches a hard new problem and how easily or not they give up. I'd guess that a person who didn't solve a hard problem, but got close enough by displaying creativity, curiousness and a solid thought process might have an edge over a person that implemented a familiar algorithm with ease but got a little flustered, and didn't show much creativity or inquisitiveness, when challenged with something new.
Whiteboard interviews might miss eccentrics who can't express their clever thoughts verbally or visually, but it can depend on how tuned in the interviewer is to these eccentricities or how much value their team puts on expressive skills.
Algorithm/data structure interviews, whiteboard or not, also have the added benefit of being exceptionally good at eliminating candidates that:
1) Drastically misrepresent their skills
2) Give up easily at difficult tasks
3) Don't seek help from others
4) Frequently have a bad attitude
I had them attempt to solve the problems on a whiteboard that I would give to our intern candidates. Both totally bombed hard, and our other "re-interviewers" had the same result when they asked some design-related and algorithmic related questions.
This wasn't "regurgitating algorithms". It was basic problem-solving and software design. From their track record of development we didn't believe them to be qualified (despite their own opinion of themselves), and they only confirmed it by totally bombing the "re-interview" process (which was identical to our normal interview process).
The only way to validate your highering process is to randomly accept people you would otherwise fail. Anything else is meaningless.
In practice, they select for people with good memorization skills. If you can remember the details on a ten dozen different algorithms and data structures, you can pass one of these without having a single lick of creativity or skill.
I say this as an employee who has worked alongside many unskilled drones who made it past the algorithmic interview process.