Hacker News Reader

Comment by mancerayder | Hacker News Reader

Great, now can Netflix, Google and Facebook do this, too? Not because I want to work in these places, but because they influence everyone else and as a senior engineer in the systems space I feel I shouldn't need to study days or weeks for fizzbuzz sorting algorithms questions that are designed to test comp sci recent grads. I have a proven career, and was never suddenly stumped in a project due to not being able to.. sort letters in some obscure order based on arbitrary rules. How about we look at that, and compare the candidate's past experience to the current needs and interview based on that -- You DID look at the CV before bringing the candidate in, didn't you?

View on HN

I've interviewed and been interviewing for over a decade. I have had the displeasure of interviewing many people who have very impressive resumes yet when asked how they would judge their skillset in an area, and being told from them that they would say "expert", being shown exactly the opposite when it came time to answer some questions in that area.

One data point... Senior engineer that founded the local java user group and wrote a published book on the java language. Couldn't code a simple reverse string algorithm, nor explain whether, after with help devising an answer, the method was thread-safe.

Another data point... A self-described expert in SQL with it all over their resume. Couldn't write a simple join, inner outer or other.

Weed-out questions exist because our industry is flooded with people who don't know, nor care to know, their craft. And there are plenty of employers who continue to hire these people, and promote them. I interviewed numerous "architects" (with development experience all over their resume) who couldn't come up with a naive solution, let alone the optimal, to a very simple problem. Want to fix the interview process in our industry? Figure out a way to weed out the liars? I'm all for it. I would rather not have to do basic algorithm questions, but that's the current environment.

I have very little experience with interviewing candidates, but how can you be certain these people were liars? Maybe they simply were having a bad day, or got too much in their head with stress during the interview. There are many factors at play when it comes to a bad performance and it's not always simply that the engineer doesn't know the answer.

I give them a chance to judge their own skillset. After looking at their resume, I have an idea based on the projects they take credit for, what their experience level should be. If what they state lines up with their resume, and they are unable to answer a simple question, with multiple hints and help, then I absolutely assume they are a liar (edit: or delusional, which is even worse. An expectation I have of seniors and above is to have some idea of knowing what they don't know).

It would be unreasonable for me to pass them through an interview that the other members on the team passed through based on "oh, they had a bad day".

Since you haven't been on the other side of the table, have you had coworkers who obviously were at a position above their skill level? Who allowed the rest of their team to carry them?

I've had periods wherey personal life has affected my productivity. That doesn't preclude my ability to write an algorithm that reverses a string nor write a simple SQL join. I don't ask brain teasers. I ask questions related to what the engineers under me will be expected to solve every day.

How do you know that you're not just crap at interviewing? Assuming people are lying is both extreme and presumptuous, no?

Also, are your people actually reversing strings by hand every day? I sure hope not!

Since you're attacking me, do you have any experience screening resumes? Phone screens? In-person interviews? Have you had the experience of a candidate that has apparently "done it all" on their resume, and confirmed their skill level when asked in-person, only to see them struggle with the simplest question in an area they deem themself an "expert" in?

I've interviewed well over 300 people, for positions from junior/entry-level to principal. If you read many of the comments to this article you'll hear other people with experience interviewing who also call out that candidates can and do lie. I don't like it, I'd rather it not be the case. I constrain the majority of my questioning to what a candidate claims to know on their resume. Here's a tip... If you don't know it (and I'm not talking about bullshit trivia questions), then don't put it on your resume.

Yup... and I don't know, for someone who has "300 people" worth of interview experience, you sure don't seem to be demonstrating in this thread the sort of level headed temperance and soft skills I would expect.

I'm joking. (sorta)

I'm glad to hear that you tailor to the resume, that's actually better than most and my favorite approach.

But if I had a dollar for every time someone walked out of an interview with a braggadocious claim like "they couldn't even do X, they must be lying" but then answer "no" to "did you ask them anything else?". I'd be rich.

Reversing a string is a bad example, it is dead easy. But it seems a lot of people have random substitutions for it of varying obscurity and difficulty.

My interview covers coding, data structures, algorithms, system design and data modeling. I attempt to tailor to the candidate, but there needs to be some level of standardization to be able to justify to the recruiters why a candidate didn't proceed.

Just because a candidate fails or falls short in one area doesn't mean they are cut, but it's a pretty large red flag if a candidate purports to know something, both on their resume and in person, yet can't answer some seemingly basic questions. If you state on your resume that you architected and implemented a system end to end, yet can't whiteboard the result and explain bottlenecks or failure conditions, I absolutely will assume you stretched the truth a bit. And if the candidate feels the need to do that to get the job, what will it be like to work with them? Could you trust their estimates? Would you be able to back them if something they delivered fails and you trusted them as a senior to deliver?

I ask follow-ups. I give hints. Honestly I'm dismayed at the skillset of purported "seniors" and "architects", and that's interviewing for small companies up to one of the FAANGs.

Do you allow candidates to use their normal workflow (which is dependent on access to Google, github and q&a sites) or are we putting people in an idealized workflow where the dev has to know everything? I think many developers and interviewers think using Google and StackOverflow is a sign of weakness. It may or may not be, but it is normal in many developers workflows.

Thoughts?

I tell the candidates that I will happily be their Google/stack overflow. Some candidates ask questions along that line, some don't.

I agree that we don't code in a vacuum. What I'm trying to ascertain in the interview is how someone thinks, how they approach a problem and work through the solution. The more they communicate the better, even if part of that communication is "is there a length property on the String class?"

I note, but don't give it too much weight, if there are minor syntax errors. I ask candidates to walk through their code with an example input, especially the ones that have errors. If they catch their errors and fix them, I note that. If they skip over their errors because they assume the code does what they wanted it to, I note that.

Ultimately, can you reason through the problem, come up with a solution, and talk about the tradeoffs you made in your implementation. Any senior should be able to handle that without any preparation.

I worked at a FAANG where in several loop debriefs I was challenged on the complexity of my question. One of the challengers asks a chutes and ladders question (given a random chutes and ladders board, where you can choose between 1-6 for every move, what is the minimum number of moves to get to the end).

It doesn't take a hard technical question to figure out whether someone knows how to think and work through problems.

I've never counted but I must have done way more than 300 interviews. I have interviewed at 3/5 of the FAANG.

Coding: on a whiteboard or with someone watching over you has no correlation with performance on the job.

Data structures: questions usually end up so contrite that they have no bearing to real-world situations. That or based on luck of seeing an remembering the right one. Data structures usually go hand in hand with algorithms.

Algorithms: questions become more like trivia or reinventing something that has likely got research papers on it. Oh, you want me to invent an algorithm I've never heard of on a whiteboard with your clues?

System design and data modelling: the kind of thing you can do in an interview lacks real-world data. No empiricism. It's all about the trade-offs.

Tailoring to the candidate introduces inconsistency and unfairness/luck.

What if these "seniors" and "architects" are frauds?! How else could they hold down a job for 20 years and not be able to answer my questions? They must be really bad!

Lucky my interview process is really great and I always hire the good ones. I track every rejection and I have proof that they never amount to anything!

If you cant quickly write a function that reverses a string you either don't know the language at all or you can't solve simple problems. So either a liar or a completely incompetent engineer is a safe bet.

I mean, people shouldn't be reversing strings by hand, but being unable to do so is also very worrying. Not because manual string reversal is an everyday problem, but because you need to do similarly complicated things all the time. In fact, you need to do them even if you're not a dev, it's just that devs share a common language that makes string reversal a sensible problem to ask in an interview.

>you need to do similarly complicated things all the time

My policy is to ask about those things instead. The ones you'll actually do rather than the ones that are, at best, tangentially related.

It takes a few days to explain the business rules. It's probably better to use a well understood general structure.

It isn't that hard to isolate a block of code that addresses a small cross section of your business rules and ask a candidate to do something meaningful with it.

That could be an excellent second, more involved, question. The first, super simple 2-minute sanity check question is to reverse a string. It's literally just a reverse for loop.

Then the complaint will be "they gave me a question about a really specific and hard to understand part of their code. It would have been easy to solve if I had familiarity with the concepts involved. Why didn't they just ask a similarly complicated question about strings instead?"

That would be the complaint if you didn't isolate the code and explain the task properly.

If you can't do that then you should probably worry about your own skills before testing somebody else's.

That's not really actionable. Even if my skills aren't up to pytester's standards, we still need to recruit developers now. And for what it's worth I doubt I'll ever be able to explain most of the tasks our business is doing what you refer to as "properly".

I joined a team two weeks ago that built a fairly complex machine learning pipeline. One week in I was told I needed to help interview a candidate.

I lopped off a block of the code, made it run without the rest of the code base and explained what it was supposed to do. This wasn't that simple, but could still be explained in about a minute to somebody with familiarity in ML (assumed; that's what we're hiring for). I then challenged the candidate to spot any bugs and implement a feature.

This really wasn't that hard. I've done the same thing twice before in two completely different industries.

Why would that be impossible for you?

Perhaps I just don't understand what you're proposing. If it's general enough to be presentable without any domain specifics, then it seems indistinguishable from a general algorithm like reversing a string. I don't use tasks quite as simple as string reversal but not far from it.

As I read it the main observable difference between your exercise and the kind of exercise you're arguing against is that you are starting with some baseline code that the candidate is supposed to modify. That seems like a pretty good idea, but I haven't used it yet.

If you're crap at interviewing, you're just not going to do well at interviews.

That's unfortunate, but logically inescapable.

Handling their mental stability should be part of their skill. "Having a bad day" on a scheduled day sounds like almost bad management of ones self.

Back when I worked in an office and conducted interviews, I made a point of always having the candidate sit in front of a computer and solve some very simple problems. It's amazing the number of candidates with apparently strong CVs who simply did not know how to use a computer. I mean, people claiming Linux experience who didn't know how to type commands at the prompt, not even "ls". How were they expecting to get a Linux developer role?? Unfortunately you have to weed these people out, and this was the only way I found.

> Couldn't code a simple reverse string algorithm

You were interviewing senior engineers with Java experience and they couldn't come up with Assert.assertEquals("radar",StringUtils.reverse("radar"));

I suspect you were actually looking for the implementation of StringUtils.reverse() and if that's the case then you were focused on the wrong skills.

It's the start of the coding interview. It moves on from there. This candidate didn't even ask if he could use Apache commons, and I hadn't yet specified that he couldn't use a 3rd party library. So yes. He failed on many counts.

1) not asking clarifying questions 2) not being familiar with some well-known libraries 3) not being able to implement a basic reverse string 4) not being able to explain whether or not a simple method was thread safe (with multi-threading experience all over his resume)

I expect engineers, senior or otherwise, to be able to write code. If you can't do that, don't put it on your resume.

If you honestly think implementing a reverse string method is "too complicated"...

Edit: sorry, leaving the response as-is, but I recognize you didn't state "too complicated". You stated "focused on the wrong skills". I posit that an engineer that can't reverse a string, as a litmus test, will be likely unable to solve a more complicated problem.

If you're interviewing for some core, low level algorithm development then fair enough but I suspect if that's the case you could come up with something a little closer to the real life domain.

It's not that I think the question is too complicated, just not the best marker.

In my mind, more relevant questions are ones that demonstrate real life experience in the field. For example, populating a tree of objects in a high level language like Java from a DB where the tree of objects are stored as many to many relationships. You'd be surprised how many times I've run across production code which does this via SQL calls inside nested loops.

This whole infatuation with algorithm questions like you'd find in SICP might be good for new grads but misses the mark for Senior level engineers.

I asked a candidate to implement an algorithm that reverses a string. I don't see that as a complicated problem. It's literally a for loop, and based on how they choose to implement it you can ask about implications of append vs. prepend, etc.

I didn't ask them to implement dijkstra's algorithm, or even something as "hard" as breadth-first or depth-first search (which I feel any senior that deals with trees should be able to do).

It's a marker of this... Can the candidate solve a basic problem? Once they solve it, can they explain their solution? Do they understand the memory/time tradeoffs they chose? Do they know whether the code they wrote is thread-safe? If you don't feel a senior engineer should be able to answer those questions, to a very basic problem, how do you expect them to tackle something more complex?

What I'm interested in from a senior engineer is how many systems they've designed, implemented, deployed to production and supported in their careers and what their specific roles were in those projects. If I can't get an idea from their resume I wouldn't contact them for an interview.

As for the interview itself, well I've never needed to ask someone to reverse a string to determine if they're going to be of value with the criteria mentioned above.

But to be fair I've never worked on a project where implementing StringUtils.reverse() was required. If I were interviewing someone to work on Apache Commons or the JDK then I suppose that would be a relevant question.

Oh come on, argue the strongest part of their argument, would you, instead of nitpicking over string reverse. They've repeatedly, laboriously, explained that reversing a string isn't the relevant part to be focusing on.

And when their resume looks good and claims they are an expert, and you call them in and talk to them and they say they are an expert, and you start by opening a warmup question on the most basic levels of their expertise and they totally flunk it on multiple levels - unable to even handle the situation with tact or diplomacy in any way, are you still going to trust what they say about the systems they've "deployed and supported"?

Did you know in .Net strings are immutable? Neither did the guy at Google when he asked me to do some "in place" string fiddling algorithm or that guy at Amazon who wanted to reverse the strings in a sentence (yes there's a trick to that one found in some 80s programming book)

How many times in your job did you have to implement reversing a string without calling a library?

I mean, in languages like Python it can be as simple as `foo[::-1]` or some similar method. Anyone who can give a naive answer like that or

    usize len = strlen(foo);
    char* bar = malloc(len);
    for (int i = 0; i < len; i++) {
        bar[i] = foo[len - (i + 1)];
    }

and explain why that won't work for unicode strings, I imagine, would pass that particular fizzbuzz test. Bonus points for pointing out the null byte off by one error.

The only competent programmers I can think of that wouldn't be able to come up with that off the top off my head work in embedded or FPGAs where strings are rarely relevant.

I understand the class of rebuttal you're invoking here, but reversing a string is extremely easy - with or without a library. This is not an academic problem designed to see if a person can study prior to an interview. This is a first pass question designed to see if a person is even acquainted with basic programming. Any such question you could devise would be similarly patronizing or orthogonal to the exact work done on the job.

And yet, despite how easy the question is people still fail it. It's frankly absurd to me that a senior software engineer can fail this question. It's practically a freebie slam dunk for anyone with basic competency. Briefly drop that you can use your language's core function or method to do it. Then declare a new array and iterate through the string backwards, appending each character to the new array. When you're done, collapse the array to a string.

In other words, it's testing if you can write a for loop. How many times in your job do you expect to implement a for loop? I use for loops quite often.

> iterate through the string backwards

What about multi-byte characters?

That would be an excellent question to ask during an interview.

If you were interviewing with me, I'd ask you to do the (usually expected) ASCII/array-of-graphemes version first. If you did that, you'd pass, and get a positive shout-out in the feedback session for asking about multibyte chars.

If you, after solving the array-based form, had some ideas or even working code for how to handle multibyte characters directly, without falling back to the standard library of $language's idea of "what is an iterable character-equivalent unit in a string", and demonstrated similar insight in your other interview problems, I'd give a positive shout-out with the addendum that we might be interviewing you for the wrong (too junior) position.

In my experience, most people don't ask about multibyte chars. That's fine, if they solve the problem. It's not a positive or negative. If an interviewer is building questions with hidden "must-ask" gotchas like that, I think they're doing themselves and their candidates a disservice.

Something interesting does happen occasionally when candidates do ask about byte-width (or equivalent less-common but still very important gotchas like pointer/word size, endianness, etc. in relevant problems): some people ask the question, solve the naïve form of the problem, and then offer some thoughts as to how they'd handle the broader multibyte case. But some other people act as if knowing that gotcha means they won't or shouldn't have to continue solving the problem. I've had candidates tell me that they "figured it out" and wanted to go on to the next challenge at that point, without writing a line of code. I've had candidates tell me flat out that writing non-Unicode aware string processing algorithms was unrealistic and a waste of time, and that they wanted a problem that was more real-world or suited to their level of skill. Those things will also get you a shout-out in the interview review session, but not the good kind.

>>Then declare a new array and iterate through the string backwards, appending each character to the new array. When you're done, collapse the array to a string.

a. You can't iterate a 'String' backwards. You need to know the length first. And that requires traversing the string forwards at least once.

b. Once you reach the end you are wasting the effort of revisiting the elements, since you visited them already once.

c. A better option is build a build a double linked list, as you are traversing the list forward.

d. Once you have the double linked list ready, you have pointers to both start and end, and you traverse the way you like.

e. An even better way would be to design a data structure that contains all this meta data at String creation itself.

    Class CustomString {
        char* headPointer;
        char* tailPointer;
        int length;
        bool isPalindrome;
        char* string;
        /* Add your interview acrobatic things here */
    }

Stuff like this.

Now even though the answer in your comment is correct, they could reject you for not coming up with the answers I gave from point a through e above.

Now imagine some one telling you that, on these grounds, you don't know a semicolon worth programming and are probably a liar.

I hope you understand what's going on here. Every body can be rejected if they don't cut through your cookie cutter.

It was supposed to be in Java.

> a. You can't iterate a 'String' backwards. You need to know the length first. And that requires traversing the string forwards at least once.

That's not at all true in many languages. If a candidate asked "is this string's length known without an O(N) operation on the number of characters in it?" (or knew the answer for the default string constructs in the language they were using for the problem) I'd consider that a positive indicator. If they said what you just said, without consideration for the context, I'd consider that a negative.

This is not a case of someone expecting a given "cookie cutter" solution. Interviewers who do that are doing themselves and their candidates a disservice. This is a case where statements like "I know how strings work because I know how they work in $context" where $context is not what the interview expects you to work in will make a bad impression.

Can you traverse an array? Do you know that a string is an array? Do you know how the end or length of a string is represented in your language of choise? Do you know how each character is represented? Do you understand Unicode? Do you understand memory allocation? Is the string being reversed in place or you allocating a new string? What are the space and performance trade-offs between those approaches? I mean, you can fill a whole interview with just this topic. So yes if your answer is string.reverse() then expect some follow-up questions.

Just speaking to points 1 and 2:

In an interview, there is an unspoken assumption that you won't be using third party libraries to implement algorithms, and certainly not a third party library that implements it in one function call. Using that as a red flag will yield a LOT of false positives.

Also, I have over 10 years experience in Java, have used Apache commons extensively, and had no idea that a string reversal method even existed. You can't use that knowledge to judge anything useful.

I agree about your unspoken assumption, but many interviewees ask. And the post I was responding to pointed to the Apache commons library, so I hazard to say it's not universally known.

A fail is not a red flag. A senior candidate not asking clarifying questions does not disqualify them (what I would call a red flag) but it is brought up in the debrief as a potential gap. I don't expect them to state this could be implemented using a single call to Apache commons. I call those candidates out in the debrief as being aware of the library, as a bonus. But not saying it isn't a negative.

Why do you assume that the person is lying? Why do you start your relationship with your new co-worker on distrust? There is a way to weed out the liars - you hire them and then when it does not work out you fire them. You would be astonished how little people lie on their CV.

They may exaggerate claims - yes, that is why you gave them a call in the first place. But then again you exaggerated your claims in the job posting of which skills are required for the job.

The one thing that I noticed is that only the US companies have this awkward parallel reality 'technical-interview' hiring process. In other countries like Germany or France the interview process is mostly focused on the person and the desire to work for the company and the willingness to learn the skills needed for the job. Just because you fail to answer immediately to a random question it does not mean you are unqualified for the job.

When I conduct an interview I try to only ask open questions like: * What is your favorite IDE? - Whatever the person answers, tells a lot about how he works, what tools he uses, and if he is aware of the common tools * What feature of the new Version of <Programming Language> do you like the most? - A) you may learn about some weird feature, b) you can discuss how that feature will improve code * Do you prefer JavaScript or TypeScript (dynamic vs typed language)?

There is no right answer. It is all about how the candidate argues his answer. You learn more about the person and if you can deal with him on a day to day basis (and if he has the brains to think about things).

> Why do you assume that the person is lying?

There was a blog post "Adventure in the Low Status of Software Engineers" by Michael Church (apparently taken down now), basically if you're interviewing for "low status" positions you're assumed to be a fraud but for "high status" positions (VP-level) you're assumed to be a great candidate even if your resumes are almost identical in both cases.

> There is a way to weed out the liars - you hire them and then when it does not work out you fire them.

In my experience, firing someone takes multiple months. Months in which they are mutating the codebase (with review, but it's a time sink that shouldn't exist for a decent senior), influencing other engineers, etc.

Passing on a good candidate is cheaper in the long run than hiring a bad candidate. Or said another way, false negatives are preferred over false positives.

> You would be astonished how little people lie on their CV.

This has not been my experience. From something as white-lieish as "I designed and implemented" vs. "I was a peer on the team that did it" to flat out fabrications. You learn alot by simply asking "what was your role on the project" and asking follow-ups to dig into their contributions.

I am assuming the you mean the USA I would suspect not months in the case on NCI Non Culpable Incompetence.

Don't most companies have a probation period these days.

> You would be astonished how little people lie on their CV.

That is no doubt your experience, but I assure you it is not universal. I have heard, and in some cases personally seen, some truly shocking things!

> In other countries like Germany or France...

Perhaps the gold digging nature of Silicon Valley entices far more scammers to cook up a SWE resume and roll the dice, but I think it's a very different hiring world here.

I think you're ignoring that hiring someone onto your team takes a long time and significant effort. Say you're allowed to add one person to your team. You interview 50 people and decide on the best candidate. Then you spend the next 6-months waiting on lawyers, processing visas, moving their them and their family to the US, paying for their initial housing, etc. Might not be an issue for a small company in France that hires locals but it sure is for big companies in the US.

You should have a short list of only two or three you actually interview

Totally reasonable response. However, it seems like we're on an endless loop with this discussion. People talk about how they need technical interviews because someone who looks good on paper can't code reverse string, or write a basic join. But here's the thing, absolutely none of my technical interviews have involved anything remotely this simple. They are "find all matching matching subtrees in a binary search tree", or "find all possible matrices with a negative determinant within an NxM matrix of arbitrary size", and it's supposed to be done in about 45 minutes, at the whiteboard.

Really, it's not fizz buzz or string reversal that causes people to re-study for their algorithms and data structures exam before an interview.

In many ways, I think this is similar to requiring that senior actuaries re-study integration by parts prior to every interview. They don't have to, because they have a proper exam that is widely accepted in their field. We don't. So instead, we are taken through full day whiteboard exams, under conditions of great secrecy, over and over, every time we interview.

This is an excellent analogy. I've found that ability to complete esoteric algorithms problems has little relation to productivity in specialized subjects, as in network security.

Did anyone stop to think that maybe, just maybe, in the allotted time there simply isn't enough bandwidth to accurately answer the question of whether the candidate can do the job and will be a good fit and that no matter what strategy you try that perhaps this is an optimization problem for which there is no good solution.

Like this is it. As good as it gets.

I actually think all this back and forth, chopping and changing, people arbitrarily weeding companies out, companies arbitrarily weeding people out is providing just the right amount of randomness for everyone to wind up somewhere.

Hiring is mostly random.

So, I agree you want to see evidence of what's on the resume. But why isn't an actual work project of some sort better than whiteboard coding exercises?

As a hiring manager, I agree 100%. These people are everywhere. I've also given someone the benefit of the doubt -- he wrote a Java book! once we hire him, I'm sure it will work out -- only to find, nope, he can't code on the job either.

Other hand, I'd suggest instead of "lying" that people are just myopic about their skill sets. I'd been writing JavaScript code for years, for example, but on an interview learned about a whole world of "modern" JavaScript that I didn't know existed. Clearly they thought I was a fraud. But I'd just been living on the 3rd floor without ever visiting the basement where all the pipes and boilers were.

Fizzbuzz is a trivial test to detect people who are basically fraudulent in their claims of programming ability. You shouldn’t need to study for it. Sorting algorithms, sure.

You could just ask the candidate to explain how to use modulus correctly, and not even need to break out the markers.

That sets the bar too low for screening IMO. My wife has interviewed people who literally can't write a for loop correctly.

Modulus is a rabbit hole - the mod operator has different behaviour for negative parameters depending on the language (and presumably other language specific quirks?)

Here's another one: when does the abs operator return a negative number?

Why make it a trivia game? Explaining the basics of how modulus SHOULD work is a fairly generic concept that is trivial for a lot of coders to describe, but impossible for non-coders. It's an ice-breaker.

Modular arithmetic ought to be explainable by anyone who’s studied basic number theory. Not just coders.

Hmm, everytime I use modulus I need to double check whether it returns the number of times wholly divisible or the remainder.

I'm thinking the former without checking now.

Meanwhile, my last project has been to set up an entirely self hosted CI/CD pipeline using digital ocean, docker, jenkins, gitea, and docker registry to make changes to my websites I build with erlang, react, html and sass, so I _think_ I can create projects! (No guarantees).

The interview process is tough, and what do you want to root out more false negatives or false positives? It may depend on the size of the company. Google can probably shell out a few bucks to some putz who sounds impressive but isn't in the hopes they'll nab a few more great engineers at the loss of a few paychecks.

An early phase startup may not have that luxury.

Edit: must be tired since just thinking about fizzbuzz for two seconds clearly gives me the answer to what modulus returns ;-)

> Google can probably shell out a few bucks to some putz who sounds impressive but isn't in the hopes they'll nab a few more great engineers at the loss of a few paychecks.

They actually take the opposite approach. Supposedly there is compelling research that low-performing members of a team provide large negative contribution to team performance from knock-on effects of their low standards and low quality work. Google has consequentially structured their interview process to minimize false positives rather than false negatives so as to minimize firings and the associated psychological stress caused by working in an environment in which people are regularly fired.

The differing behavior is because some of those implement remainder instead of modulus: https://stackoverflow.com/questions/13683563/whats-the-diffe...

Fizzbuzz is not really about testing someones understanding of a modulus operator, it would be very easy to make an alternate fizzbuzz that does not require using modulus, and arguably anyone hiring for a large company should have their own as fizzbuzz is pretty widely known.

The point of fizzbuzz though is to make someone create a very simple algorithm on the spot. In my experience, there are some people in this world who simply lack the ability to structure their thoughts and plans into a complete set of ordered instructions. That's why you sometimes find recipes online that follow a structure like:

1. Dice the onions

2. Brown the mince for 5 minutes

3. But first, add the onions and tomato paste to the mince

It's the same personality type that cleans a room by walking backwards and forwards to the cupboard of cleaning supplies as they need them rather than grabbing all the cleaning supplies they can predict needing first.

Now, everyone does these kinds of things to a certain extent, but you can't program anything significant if you can't drop into an ordered mindset on command. Fizzbuzz tests your ability to do that without requiring you to know any apis or frameworks or computer science or even a programming language, since you can just as easily do it in psudocode.

Yup, my experience is that FizzBuzz level complexity is roughly what you want for interview problems. I find that and some questions about algorithms and data structures tell you all you need to know.

I remember a colleague who was affronted at being asked to do Fizzbuzz. I told him it was just a simple screen for fraudsters and bullshit artists and not to take it personally, they didn't know him from Adam, after all.

http://weblog.raganwald.com/2007/01/dont-overthink-fizzbuzz....

Was the affront that it was too easy? Believe it or not, it weeds out candidates.

I think, because he didn't understand the purpose, he saw it as poor company interviewing to make him jump though that sort of crap. Once he understood it was just a simple screening mechanism because of the high number of dodgy applicants, he calmed down.

I interviewed at Facebook and the tech part was completely sane and appropriate, the technical task was a bit fizzbuzzy but not something you'd need to spend nights digging into obscure algorithms book, but rather simple task which required some thinking, but not too much of it. No experience with Google or Netflix. As of looking at CV, I've seen people with great CVs that proved utterly useless and of course the opposite too. CV can be very misleading, both unintentionally and intentionally. You need to speak with the person.

I tech screened at Facebook and the whiteboard question was to partially implement a regex parser.

I got this same question from 2 other companies.

Meanwhile some of us are just happy if candidates know of the existence of regexes, even if they forgot the exact usage, and can mention using them rather than trying to write a parser from scratch when given a problem statement of extracting phone numbers of various formats from several thousand unstructured files of web page scrapes...

How partially? I could probably do a very simple one, without backtracking (though they'd need a big whiteboard if they want full code there) but if it's something like PCRE then I don't think Facebook headquarters have enough whiteboards to fit the code :)

Though I just realized "regex parser" can mean either "parsing some text using regex" or "code that compiles regex syntax into some kind of data structure but does not actually do anything else". The latter obviously is a much easier task.

It's neither. There's a DP solution for this problem and a recursive solution without memoization (with exponential complexity). The shortest solution I have seen was 18 lines of code.

Please show me a regex parser in 18 lines of code! Even 36! I did this exercise once and it took 100s of lines, I think using C++... but it's been a long time. Maybe it's significantly shorter in Python? But still 18 lines is impressive.

I probably screwed something up, but here's a 16 line attempt in Python, where the regex specials are limited to .?:
def matches(pattern, s): if len(pattern) == 0: return True c = pattern[0] assert c not in ("*", "?") if len(pattern) > 1: if pattern[1] == "?": return ( len(s) > 0 and c in (".", s[0]) and matches(pattern[2:], s[1:]) ) or matches(pattern[2:], s) elif pattern[1] == "*": for i, d in enumerate(s): if c not in (".", d): break return any(matches(pattern[2:], s[j:]) for j in range(i, -1, -1)) return len(s) > 0 and c in (".", s[0])

Pretty much something along these lines, except it's also required that both pattern and s end at the same time for a full match (this complicates the base case a tiny bit). The C/C++ solution looks more elegant because you can use pointers. Note that this particular version requires no prior knowledge of the algorithm and can be solved on the spot fairly easily.

Thanks for the demonstration!

This is LeetCode #10, this is a common question.

The question was: Write a method that can take in a regex and a string and return whether the string matches it, with the regex limited to the characters . * ? (And backtracking is definitely where I started coming unstuck)

Ah, that's definitely different than I understood your first post. You're writing a regex to match a given type of string. The regex parser is in the language itself, consuming what you've written and evaluating it.

No, I was writing the regex parsing code. The regex was one of the inputs.

If the regex is really just a sequence of dots followed by a question mark, asterisk or nothing, thus cannot contain literals, the only thing you need to check for is the length of the string.
The minimum length will be the number of dots without a quantifier (i.e. exactly one character). If there is any dot followed by an asterisk, there is no maximum length. Otherwise, the maximum length will be the minimum length plus the number of dots followed by a question mark.
Writing the code for this is left as an exercise to the reader. ;)

The regex can be any string made up of any number of those three characters in any order.

A simple one isn't that hard to put together in an Hour. I've gotten this and thought it to be mildly interesting.

You don’t even have an hour in an initial tech screen.

The issue with that is that if my CV is incredibly specialized in one area that happens to match the job I’m going for (eg compilers), why test my knowledge in designing things like a distributed system and in how great I do dynamic programming (that is not useful in my area)??? It feels like there is no verification at all of what my CV claims, nor does it give me a chance to show off the skills I’ve been working on for them last 20 years, both of which are very relevant to the job. Instead, I’m tested on what I knew when I graduated with my BS, and that’s it; it’s like my PhD was a waste.

In larger corporations it may not be 100% finalized where you would end up.
Knowing that yes, you master compilers (that's usually quickly determined, potentially fast enough for you not to notice it since you live and breath compilers), have basic knowledge in smashing together enough html tags to build a simple dashboard but you never had to deal with processes that spanned multiple computers, allows more flexible allocation:
Ideally, they'll give you a compiler related task, but if they find someone even more suited for that one open position in compiler internals, they might offer you a job in the adjacent compiler-as-a-service team where you'd start out doing dashboards and then move to whatever more complex task needs work.
But they won't need to bother offering you the distributed systems position that scales up the compiler-as-a-service product across the whole world without sending you to some training first.

I’m not going to take the job if I don’t wind up in a group working on problems that interest me. That is part of the bidirectional interview right? I hesitated even applying to a big Corp until a few people there convinced me they had problems right up my ally. I don’t want to work at big corp just to be working at big corp!

The hiring pipeline at every big company I've been at is not always the same. Yeah, part of it is always just a big funnel that takes general applicants in and assumes they might end up anywhere in the company. But, there is also going to be a way for specialized teams to hire specialized candidates. If you find yourself in the big funnel, by all means, just tell them you aren't interested if that's not what you want. If you want to work on compilers, you need to find a way to get into the pipeline for a compiler team, and that's not really much different than finding a job with a small company.

Yes, I already did this with Amazon who hires for specific roles, but the recruiters I’ve dealt with seem to be into bait and switch (substitute very appropriate role I applied for with something completely inappropriate).
The job opportunities are definitely out there, but many of them really require a referral (the JDs aren’t posted), and even then you might have to do a generalist interview because the company is not capable of doing anything else.

Because at big corps engineers might get assigned interviews as a routine work. And any engineer has their favourite questions that they know the answer to. They dont want to take.the extra effort and come up with new questions just to adapt to your profile or expertise. It goes the other way around. I.e.the interviewer is not going to do.extra work to validate the candidate but the candidate has to prove him/herself. Take it or leave it.

The one size fits all interview at a big corp is game-able at least, with plenty of practice material available online. It isn’t a huge hurdle if you have a month or two to practice, but that makes the whole process even more questionable.

I had a junior/intermediate level engineer start asking me minutiae about HTTP and HTTPS...
After about 5 minutes of this I literally said:
"Dude, have you seem my resume? I literally built a petabyte scale full text search engine and wrote 1.5M lines of code to do so and a HTTP framework that parses fetches more than 2PB of HTML per month. If there's some edge case that I might miss I can Google it in 30 seconds".
I no longer keep small tactical issues in my head. It's pointless. Now I try to understand the system as a whole.

It could be _because_ they read your resume that they asked those questions, to see if they believe it. People heavily embellish their degree of involvement in projects all the time.
Or they could just be asking gotcha trivia. It’s hard to tell.

I guess people who allowed hacks like adding -1 fridge to get a free tv in earlier online stores could also claim "but they have build online stores that moved thousands of sales every minute"
;)

A lot of people will write whatever makes them sound good on their resumes, so we have to ask questions about minutiae to make sure candidates aren’t lying.
It sucks, but this is what happens when the job you’re interviewing for has no license or certification requirements (but pays six figures).

Over what period of time did you write 1.5 _million_ lines of code for this one project?

Nothing to take away from the original posters work. He indeed might have written that much code.
But in most cases. Its not very difficult to write 1.5 million lines of code for any project if you are writing code of the style AbstractClassFactoryFactorySingletonDispatcherFacadeInitializer
That sort of the code is basically 90% auto generated by the IDE. You write the remaining 10%.
As a matter of fact I would find it a tad little hard to believe that some one wrote that much(1+ million LOC) and didn't find a way to template it or do some metaprogramming work.
Patterns always emerge from that kind of pile.

The IDE can generate "headers" for a new file, it's not gonna generate tens of thousands of new files by itself, let alone in a meaningful structure.
I don't think a developer would write a million line at work in their entire lifetime.
I'm not saying it's impossible to achieve. I've seen outsourcing agencies deliver 100k lines with just a few block copy/pasted many many times, but that's neither working nor maintainable software.

Red flag: invalid metrics exception
1.5M lines is the output of a team of hundreds of developers over years. I don't believe anyone would write a million lines during a job.
2PB a month, is 125B documents at 16kB each, or 50k documents per second. That's decent. That's where it starts to be interesting in elasticsearch or hadoop.

This is a partially valid point... let me restate.
About 200K lines of code is auto-generated.
A more appropriate estimation would probably be about 400k lines per year as some of this code did a big mass migration and refactoring during this time but I wrote that code as well. Just in the past.
KLOC is a shitty metric anyway.
I'd rather write 100 KLOC that worked vs 10000KLOC that was horrible.

> You DID look at the CV before bringing the candidate in, didn’t you?
I would like to speak to this after interviewing at a few places recently, including Google. I don’t think a single interviewer looked at my resume. I’ve developed a sizable open source project that is used by real people for over a decade. If the company really wanted to know if I could write code they could just go and look at it. Instead they ask puzzle questions that I have no interest in and end up failing. These companies expect the candidate to spend weeks preparing for their hoop jumping, but can’t be bothered to actually read the CV. Multiple people didn’t seem to realize where I lived even when my address was at the top of the paper.

I think they have a policy of not reading your resume so as not to bias the interviewer. Seems crazy I know.

Netflix already does this. Just interviewed with them for a full stack role. All interviews are dependent on the team, but generally feature less whiteboarding than FB/Google. I did a takehome technical exercise, in person interviews were tailored to my experience. They were mostly about system design, general concepts, and a heavy heavy focus on interpersonal skills. Their approach seems to be:
1. Make sure you actually know what’s on your resume
2. Make sure you have the strategic thinking and interpersonal skills to own the system you’ll be working on
3. Make sure you’re a good match for their fairly unique work culture

People lie on resumes. Anyone I am responsible for hiring is going to sit down to a computer with an IDE and solve some problems.

Hopefully the problems will be relevant to the job.

Will you compensate them for this task? Even if they are not hired?

Do you usually get compensated for interviews?

I pay candidates for doing take home tests

It’s not a “take home test”. Half the purpose of live pair coding is to see how the candidate thinks.
It’s a relatively simple project with a skeleton of a class and failing unit tests. They have to fix the code to make the unit tests pass.
If they get through that, I give them a second set of failing unit tests that they have to make pass by fixing the class without breaking the unit tests.

Ah, I also thought you meant a take home test. Do you work for a big company? I’m trying to picture how that interview style would scale. Thanks for sharing.

Well, the first time so saw it Done was for the only large company I ever worked for - what was then a Fortune 10 (non tech company). But on the other hand, the department that I was hired into was actually a recently acquired small company with four developers and the manager was the founder of the original company - so take that as you may.
But, just because a company gets big, doesn’t mean that you can take hiring less seriously. You still have to be sure that you hire the right people. A false positive - hiring someone that can’t do the job - is worse than a false negative - not hiring someone who would be a good fit.

Generally agree except for the last sentence. What if the false negative is Elon Musk? Netscape could have hired him, but they passed. You can always fire a bad hire. You can’t reinterview Musk when you realize your mistake.

Even though most people work “at will”, firing someone always has consequences.
- There are usually HR policies around firing people that takes awhile and a lot of paperwork.
- You open yourself up to lawsuits whether they are successful or not, it still a hassle and has costs.
- you increase the amount you have to pay to your states unemployment insurance fund.
- It puts a chilling effect on other employees. They think they can easily be fired to.
- if the employee is really bad, they do “negative work” and put more work on the other employees who have to work around them or redo their work.
Very rarely will one employee that you don’t hire make or break an established company.

Thanks again for sharing. Great insight. If you had a blog/newsletter, I would be a reader.

No blog. I would rather keep my opinions on corporate America and my real life separate.
Everything I know about management, hiring, firing and organizational theory comes from the Manager Tools/Career Tools Podcasts.
As far as hiring, this is my go to guidance.
https://www.manager-tools.com/2007/04/effective-hiring-set-t...

By "fizzbuzz" I wasn't referring to the "divide by 3 and 5" one that seems common, but something much worse. I once interviewed at a place where they presented a jumble of characters, and about 8 rules, and I was on the phone being watched (after an hour of successfully troubleshooting a broken AWS instance with a bunch of quirky Linux issues). The 8 or so rules involved something like, "You must print each line with one character longer than the last / c must never come right before vowel / x's must be on alternate rows / f's and z's ... " while parsing all of this stuff, I had 10 minutes total since we were almost out of time when we started the questioning. The interviewer said, "Don't worry, just do it in pseudocode."
That's bad interviewing.
I can do the problem easily without someone looking over my shoulder, and I need more than 10 minutes just to think about the 8 or whatever rules he gave me.
He failed me, and I ended up working there anyway a year later after the guy quit (true story).

This sounds like you're having the wrong conversations. With all your experience, why are you still going into companies through the front door? Where's your network?
Fundamentally: Why are you having the "Can you code your way out of a wet paper bag" conversation instead of the "How much value can you add to this company" conversation?
Perhaps my experience as a consultant/freelancer is breaking my perspective. It's been several years since I last had a coding interview as an applicant.

You still have to go through a standard interview loop at Google/Facebook/Netflix/etc... even if you get in via a recommendation. The recommendation (and your cv) helps you in getting a serious phone screen and in getting a good choice of the team you want to join, but isn’t considered very much during the interview itself.

You shouldn't have to only be able to go through your network to get a job. We should judge based upon the same criteria every other damned job judges ...how well they did their last job.

> "how well they did their last job"
Right.... so if you have a mismatched role, that's it, you're done for, huh? Please.

If you apply for a full-time software engineering position at a large company today, you will be run through the all-day series-of-hourlong-interviews, even if you are a referral. It is possible for the hiring manager to work closely with recruiter and recruiting coordinator to craft a more customized interview process, but that's rare (and, impossible at a place like Google, which decentralizes hiring). The value of network is the candidate wasn't subjected to the usual resume review weeding-out, but their info went straight to one or more hiring managers for consideration.

You use the term "apply for a job", which might explain the disconnect. The post you reply to isn't about applying for jobs.
You don't want to "apply" for things. You want your google VP to be having a beer with your ex-boss and worrying that his pet project was going to fail because they just can't find a guy who can really $X.
But your ex boss knows a guy who absoulutely can $X, and just finished $X'ing his company back from the brink of disaster. Lets give him a call to see if he's available.
HR will be told to give that guy an offer and, optionally, collect a resume to keep on file.
That's what we're talking about here, and it's where you want to get yourself if you want to build a career as an individual contributor.

We need more stories like this for the New Years eve.

Since you mention Google, my understanding is that you still go through the standard hiring process

Again, always?
If they buy the company that you built specifically to get access to you, do you think you'll still end up getting screened out by some junior dev on a whiteboard? All policies have exceptions. Your goal is to be exceptional.

Yes, always. It is company policy. Google takes its standardized interview process more seriously than any other company I've heard of, except maybe Palantir.

So, you're telling me they made Vint Cerf do a whiteboard interview?

I don't know, someone would have to ask Vint. But it is a plain fact that Google interviews the engineers of a potential acquisition. For a small company, they'll pick and choose which ones to keep. For a large company, I don't know. The CEO may or may not go through the full interview process -- I've seen it both ways, seems to depend on whether they're buddies with the VP.

The problem is that exceptional isn’t a binary quality, exceptional at google is going to be another level than exceptional at some obscure contracting firm.

> If they buy the company that you built specifically to get access to you, do you think you'll still end up getting screened out by some junior dev on a whiteboard?
In this case probably not, but you'll have to do several rounds with the VPs. Of course the tenor is very different, more conversational / situtational instead of technical questions. But you're still being sniffed out. Unless you're already pals with the VP.

You clearly don’t work in the industry.
Edit: I see from your other post you haven’t interviewed since 1999. Sounds about right. The hiring process does not work how you think it should.

Not true. I've interviewed for and landed several nice gigs since then. But as I said in that other post, always skipping the tech screen piece.
From talking with other devs in my peer group, this doesn't seem uncommon.

I think it's "uncommon", but I also think that one shouldn't confuse "uncommon" with "never happens". I've had more than one job land on my doorstep without some sort of crazy tech screen. But I also talk to front-door companies on occasion too.

He's a contractor. He comes in, does a specific task, and then leaves. That's all.

In my experience it's rare for even this kind of interaction to lead to an interview process-free result. The exception would be if "the guy" is brought in as a contractor (which these days should probably be your goal), but I've worked with a lot of large companies and HR almost always forces at least some portion of standard FTE applicant evaluation even for "the guy" type referrals.

> The exception would be if "the guy" is brought in as a contractor (which these days should probably be your goal)
Could you elaborate on that? Do you mean being a contractor should be your goal as "the guy" or the hirer?

You've essentially described nepotism here - if FAANG would follow this model, they would never hire some of their best contributors because those contributors didn't live in the Valley their whole life to network with bosses. I prefer a process that's at least basically meritocratic to the old boys club type of hiring at any time.

Recommending someone you know who is good at his/her job is not nepotism. Nepotism is when you recommend your family or friends regardless of their qualifications.

> HR will be told to give that guy an offer and, optionally, collect a resume to keep on file.
No, HR will be told to get that guy into the interview pipeline as soon as possible, so he can go through the same process everybody else does for a similar position.

The sad part is that the generic generalist interview will have nothing to do with X, and if you need someone great at X-ing, might yield painful false negatives or even worse, false positives (since you can’t hire specifically for X).

I would argue that if you’re in a position to be picky you would want to hire experts in X who are also good generalists. One-trick ponies don’t do well after project X is finished and they need to contribute to other efforts.

A PhD isn’t really a one trick pony, but whatever. Even if that’s what you want (specialists who are good generalists), those interviews don’t really check the specialist part, just the generalist one.

The hero / rockstar / ninja narrative rears its ugly head again.
Some people will be at the top of their field. Most people won't.

That's completely inapplicable to permanent positions. The current company of a prolific employee is not gonna lay him off and send him to a competing company.
It can make sense for consultants, doing short gigs here and there. People can refer you elsewhere when the current work is completed, they ain't gonna keep you anyway.

Well said. It occurs to me that my last job interview that involved convincing the other party that I was a good developer was back in 1999 when I had just a few years of experience.
Since then every gig has come via an introduction by a former boss or co-worker, or by introducing myself to somebody with hiring authority and using a pile of impressive artifacts to skip the "can this guy do the work" questions.
The first several years of your career should be getting yourself into a position where nobody would ever dare ask you to sort things on a whiteboard.

You should also be young, healthy and happy - noone wants the opposite, right?

Back in 2004, I interviewed for a FTE position in finance - was my first interview for a full time role post college. I was a referral from a close friend and classmate. They sent me through the ringer. Had to take brainbench tests for C++ and C# (position was for C++, but I'd been working in C# and JS for the prior 2-3 years). IIRC, only got like a 65 percentile in C++, but over 95 in C#. Also had to go through an hour plus phone screen, then a day and a half on site. Got the job, but damned if it wasn't a long process. Lots of whiteboard and verbal questions, was never put in front of a computer except for the brainbench tests ar home.

Congratulations, you've never wanted to work for a large company. Perhaps your advice isn't relevant to those who do.

> Fundamentally: Why are you having the "Can you code your way out of a wet paper bag" conversation instead of the "How much value can you add to this company" conversation?
Because people lie. It's that simple. Referrals lie, CVs lie, friends lie to get friends in a position. Do understand that there's a fundamentally different set of problem a 40.000 FTE company has to deal with in comparison to a 30 person startup.
Also is doing a full day interview really such a horrible sacrifice for most paid jobs in the world? Professions like laywers and doctors need to go through significantly longer hazing rituals to get to FAANG income... is a month of study to be essentially among the most paid people in the world REALLY such a horrible thing?

> Professions like laywers and doctors need to go through significantly longer hazing rituals
At least for doctors this isn't universally true. There's continuing education/certification, (which you have to do every $period) there's public reputation, there's lots of networking. From what I've seen the interviews take few hours in one day and people usually already know each other.

Yes, but before that you need years of low-paid jobs and networking to come close to well paid positions. Applying at FAANG requires significantly less.

The hazing the doctors go through is during residency, where they spend years, working like horses, for no money.
I'd much rather deal with whiteboard interview bullshit a few times in my life, then go through residency in the medical field.

I'd honestly rather have the "bulletproof tenure" that doctors then acquire after they get through the hazing. Getting laid off every time a spreadsheet jockey in accounting makes a bad projection, is pretty disruptive. (as are the times when a competitor buys your employer just to shut them down, and etc: plenty of scenarios where you lose a job due to no fault of your own are rather the rule than the exception) - Most competent engineers can always get another job. But in that process, you end up with a different commute, or even having to relocate, deal with setbacks in financial plans, and etc. The instability some of us experience is kind of not worth the other perks. And after 20+ years, it's kind of annoying to have to apply as if I'm fresh out of school when I have a solid work record on my resume, verifiable by contacting my former co-workers and managers I've provide as references.

> Getting laid off every time a spreadsheet jockey in accounting makes a bad projection, is pretty disruptive.
This has nothing to do with how programmers are hired, and everything to do with the business cases that building software serves. Even if programmers were hired like doctors, they'd still be cyclically losing their jobs, because their jobs are closely tied to the willingness of the economy to spend large amounts of money on custom software.
If you want a job for life, then you want to be in a profession that does something unconditionally useful. Healthcare, garbage pickup, teaching, farming, being a janitor. We're going to need people doing all that long after <insert Silicon Valley fad of the month> is dead and buried.

Many people interviewing there are already among the most highly paid people in the world (lots of them are just moving around within that group) so that argument is pretty irrelevant.

Many (as in 10-30% at best) perhaps. Not even close to half or majority though, so I fail to understand how the argument could be irrelevant.

At the beginning of 2017, ~12,000 of Google's current ~72,000 employees had previously worked at other big tech companies, and most of them were probably in their R+D headcount of only 27,000. I wouldn't be at all surprised if half of their engineering interviewees came from similar paying jobs, and a the majority of the remainder were college hires.
https://www.alphr.com/business/1005261/silicon-valley-swipin...
https://www.statista.com/statistics/273744/number-of-full-ti...
https://www.statista.com/statistics/219333/number-of-google-...

I assume Google is looking for people who absolutely want to work at Google. Making the process cumbersome allows them to get candidates who stay at the company even if they have to do work that they don't like.

If that's what they're aiming for, evidence suggests that it isn't working - https://hackerlife.co/blog/san-francisco-large-corporation-e...

Being on the technical interviewer side of the table it was a bit disconcerting to see people get to me who really should have been filtered out at an earlier stage. Still, for the type of lies that are most damaging, I still ask the question "what's the easiest way to uncover the lie?" Hence, FizzBuzz and FizzBuzz style questions work just fine if the lie is "can program". Why stress people out with trivia quizzes on language minutia or implementations of algorithms that CS students usually get at least a week to do (or typically never do)? Why let a too-strong fear of a lying false positive, which isn't that hard to deal with as a big company, become a strong false negative filter negatively selecting for types of experienced candidates you might want who won't put up with your clown nose "everyone is doing it" rituals? It's also easier to grade if you keep things relatively simple.
I have to do a little more to satisfy the process, of course, but I'd be more satisfied if more interviewers didn't just accept the process (as you kind of have to do as an interviewee if you want certain jobs) and continuously asked themselves how they can make things better within their own influence. I could only throw up my hands and sigh when a coworker asked me for interviewer advice, we had a big discussion about interviews, and in the end he just grabbed a random problem off some interview problems site that he hadn't even tested if he could solve himself in the time limit and gave that.

too-strong fear of a lying false positive
You might be a bit optimistic here: it's not always easy to deal with "lying false positives". Depending on the legislation it may be difficult to fire somebody, and involve going to court, sometimes going on over several years. Vindictive personalities may engage in sabotaging the company, the team, their (former) co-workers, as a retaliation for being fired. (Anecdote: I have witnessed all of the above in my work.)
Summary: the cost of a false positive almost always outweighs the cost of a false negative.

I don't think there's any state in the US where lying on your resume/CV is not legal grounds for immediate termination.
And any company that has thought about their hiring process for more than 30 minutes will have a probationary period of 30 or 60 days or so, after which employment can be terminated if the employee is not able to do the work.

Are you not in the US? I've never ever come across such a thing - probably because US companies can theoretically fire you on the spot for almost any reason except specifically disallowed discrimination, and most definitely for being unable to do the work.

The problem is that resumes can be deceiving. If you've worked long enough in the industry, you've met a few incompetent people with stellar resumes. It's why having google on your resume opens a lot of doors. Everyone respects google's vetting/interviewing system.
Also, fizzbuzz isn't anything you really need to study for (certainly not for days or weeks). It's something you should be able to work out during the interview if you truly have developing experience. But then again, I've known people with amazing resumes who couldn't even understand the fizzbuzz question itself.

The Googles of this world don't fizzbuzz you, they want you to implement (close to optimal solutions!) and use tries and heaps & co. during whiteboard interviews. Neither of which I've ever had to implement in 10+ years.

I didn't say the googles of the world fizzbuzz you. I just said that fizzbuzz is so basic and simple that a developer shouldn't be studying for days or weeks for fizzbuzz. I said people respect google on your resume because their interviewing process is robust.

Not sure if I'm misreading, but you don't have to implement data structures for Google interviews

Did you, in your "proven career", ever work on the systems the size of Google Cloud and having same amount of users?
Because cheap stuff you can run away with on 1mil users suddenly falls apart when you need to serve more across continents and suddenly you kinda need to know what all those words in documentation actually mean.
Also, as for CV, everytime I've interviewed people I've gotten more than I few people that lied in their CVs. Persumed "senior developers" who couldn't do a fizzbuzz in their chosen language and tooling. CVs are utterly worthless from interviewers perspective - there will always be someone with exact same CV like you have but will be utterly incompetent.

A new grad certainly hasn't. Microsoft are saying here that the older interviews didn't test for skills that would actually be used.

Reply on news.ycombinator.com