Comment by leros | Hacker News Reader

Comment by leros | Hacker News Reader

I don't like filters like that as they're too black and white. Your idiot filter might test something the interviewee is knowledgeable or not knowledgable about.

I have questions with a variety of add-ons, so I can tune the difficulty to each person. A more junior person might take 30 minutes to give a complete answer while a more senior person might finish the base question in a few minutes so I need to add things on to make it more difficult. Some people might not have the ability to solve the problem at all. Either way, I try to get the interview to a place where the interviewee is beyond their ability to easily spit out answers.

Then the interview should turn into a back and forth discussion where they're asking me clarifying questions and possibly getting completely stumped. Either way, now we're communicating and seeing how quickly they can learn and utilize new information. That might be providing them clarifying info or teaching them something they don't know yet.

I don't care if someone can answer FizzBuzz or spit off facts about hash tables or anything like that. All that can be learned. If I'm interviewing a developer, I want them to be able to work on a project in a programming language they've never used and doing things they've never done before and become reasonably competent in a few weeks of learning.

Please be realistic. At some point, that's like saying "I don't care if a pilot for my airline knows what flaps are, they can learn".

You want a network administrator to know what a routing table does, a C engineer to know basic pointer arithmetic, a web developer to understand URLs, and so on. Yes, those are all things that can be (and have been) learned, but if someone applies to an aforementioned position without that knowledge already, massive red flags should go off for all kinds of reasons.

I've listed very basic knowledge, but the same goes for more deep knowledge in a particular field. The question here is about finding the line that is still useful. Categorically saying that no such line can be found because no question is basic enough to serve as an early filter is not useful to anyone, including the candidate.

I do care if someone cannot solve FizzBuzz, because it's so bloodily excruciatingly simple that if a candidate cannot solve this, please take some time to learn the basics of your craft before wasting your own time with interviews.

I don't disagree your first point.

The problem is that asking questions like FizzBuzz is also a filter in the other way. Higher quality candidates aren't going to bother answering your filter question and bail out of the process.

I spent several years working on a large tech hiring platform and a thing we noticed again and again is that putting up any filters immediately drove away top tier candidates. They're just not going to jump through hoops when they have so many other options available to them.

Now if you goal is to hire a more average quality candidate, then you can get away with filter questions, coding tests, etc.

Forgive me for being glib, but if the candidate jumps off because they don't want to answer a very quick, simple, efficient question, that they should fully know is because it is beneficial to filter out complete duds, I'm not sure I want to continue with them anyway?

I wouldn't even know how that happened in an in-person or video interview, or even phone screen. "I'm sorry, I do not want to answer your simple upfront question, because it is beneath me"? Well, good luck to your future endeavors then.

To be clear, as I explained in my first post, my filter questions are not FizzBuzz, they are much more domain specific. At least if it's past the phone screen stage and for more than an internship. But they are still identifiable as trivial filter question for any serious applicant.

It's not necessarily that it's beneath them, but more that they have so many options available to them.

Imagine you have 10 companies that you are willing to consider:

- 5 of them are willing to immediately bring you into a serious interview

- 5 of them want you to take a coding test or some other pre-interview step

Why would you bother with those last 5 companies? Just go for the companies that respect your resume enough to bring you in for a real interview.

Those latter 5 companies will lose out on a lot great candidates due to their filters.

I can tell you having worked on tech hiring at scale and having AB tested a lot of these things across many companies, you lose a lot of grade-A candidates with anything beyond bringing them in to interview.

The thing about hiring though is that no single company really notices their own inefficiencies. Everyone has their own filters and their own method of incorrectly rejecting great candidates. However, they ultimately hire people so they feel their process works. They don't really know if they could be hiring better people or hiring people faster.

> - 5 of them want you to take a coding test or some other pre-interview step

I don't see the assumption anywhere that the filter question is a separate step from anyone else here. Even if you mean a phone screen, then the easy filter question is only one of the very first questions of that phone screen, the rest will be more substantive.

So let's continue with the filter question not being a dedicated extra step (really, I don't think anybody assumed so):

> Why would you bother with those last 5 companies? Just go for the companies that respect your resume enough to bring you in for a real interview.

Because presumably I want to work at any of these companies. If the thing that's stopping me from applying to them is answering a trivial question, either my desire was not strong at all to begin with, or there is something seriously wrong with me.

Even if this is about the phone screen and not a filter question per se, I'm still not sure I really like the idea of omitting phone screens for more senior positions because you might lose on "better" candidates. For such a senior engineer, a phone screen should basically be a formality, and actually a chance for themselves to dip their toe in. Not just in seeing what kind of technical areas they come up with, but also an opportunity to ask preliminary questions about the company and the position in general. If that is off-putting enough to not consider applying or stop the process, then, again, the desire to work there could either have not been that strong, or the other reason.

> So let's continue with the filter question not being a dedicated extra step

I can't agree with that. I don't see point of a filter question if its not a separate step before the full interview. If you're going to bring someone in for a proper interview, go ahead and give them a full interview session. It's weird to put a filter a question into a full day's worth of interviewing.

And I can say, having seen hiring practices across tons of companies, filter questions are almost always a separate step where candidates have a tendency to fall out of the hiring pipeline.

> Even if this is about the phone screen and not a filter question per se, I'm still not sure I really like the idea of omitting phone screens for more senior positions because you might lose on "better" candidates.

Phone screens are fine because they're usually more about culture fit and trying to figure out if the candidate and company are right for each other. Experienced candidates that get asked basic technical questions on a phone screen have a tendency to report a negative experience and not have a desire to move forward with the company.

> It's weird to put a filter a question into a full day's worth of interviewing.

Some candidates won't get the full day, to prevent wasting a lot of time.

It's true that I haven't seen an individual interview being cut ultra-short after a failed filter question, but it definitely informs whether the next interviews will happen.

> Experienced candidates that get asked basic technical questions on a phone screen have a tendency to report a negative experience and not have a desire to move forward with the company.

Sorry, but, thanks for coming, and good luck in your future endeavors. As an experienced candidate, if I could not stomach that, politely and with a strong desire to move on swiftly on the other side as well, I am asked a simple technical question for the apparent reason that the interviewer cannot divine if I am actually able to program (unlike so many examples in this comment section alone), I'm not sure why I would really be considered a "grade-A" candidate.

I have definitely quit hiring process where I have been asked about FizzBuzz.

It’s outdated, useless, shows a lack of imagination.

I don’t want to work with people asking me whether I can perform a loop with a basic conditions.

And it’s a hill I am willing to die on.

I am financially independent, mostly here for the intellectual challenge. And I have never met anyone asking me about FizzBuzz having then the capacity to entertain me intellectually.

> To be clear, as I explained in my first post, my filter questions are not FizzBuzz, they are much more domain specific. At least if it's past the phone screen stage and for more than an internship. But they are still identifiable as trivial filter question for any serious applicant.

I don't force you to work anywhere, though.

Nobody is forcing anyone. And filter questions are ok, but FizzBuzz is definitely insulting.

It would be like me trying to hire someone to improve my SEO, someone sent me his CV with 8+ years of experience, who talk about long tail keywords, cannibalization issues, internal linking and I ask : "Do you know what is the Google Console?"

I think both parties can have red flags

There may be alternative methods to determining a candidate's skill without starting off with extremely low-ball questions.

I'm thinking you might get better engagement with a binary-search algorithm. Let's say that a candidate's skill is on a spectrum from 0 to 100. You might start by asking a level 50 question, which if the candidate can't answer then you'll assume they're 0-50. Then you can ask a level 25 question and see how they do there before deciding if their skill level is 0-25 or 25-50.

Obviously this is overly simplistic: knowledge/skill can be over several domains and dimensions, one question might not give sufficient signal to determine whether to raise or lower the difficulty of the next question, etc. But I think the principle may be sound.

Also, if you're searching for top tier candidates, you might aim for a nerd-sniping [0] approach where you ask about a genuinely interesting problem. The good candidates will be fine musing over the interesting problem and discussing possible solutions. The lower tier candidates will either be completely stumped, give only one solution, or give poor solutions.

[0]: https://xkcd.com/356/

Sounds like you're thinking about filters the wrong way. You're not finding gold, you're quickly filtering out the poop.

> I don't care if someone can answer FizzBuzz .... All that can be learned.

Of course. But... sometimes it isn't. If a software engineer cannot do a question like FizzBuzz (and this does happen) then you can save a lot of time by cutting short the interview. If you're hiring SEs who cannot FizzBuzz, then I wish you the best of luck.

This isn't some leetcode or data structures trivia question that excellent candidates might fail. This is a test that I cannot imagine any good candidate failing.

I think people get optimistic about the quality of candidates out there. FizzBuzz winds up being "do you know what modulus is", which screens out so so many candidates. So many.

There's a difference between a diamond in the rough who many not know $lang or $datastructure but is proficient elsewhere, and candidates that literally cannot put together a basic looping conditional. It's like hiring a network engineer that doesn't know what a network route is.

I've seen two things here: People getting too optimistic about the quality of candidates, as you say, but also people in entry level positions with entry level knowledge dismissing basic interview questions outside of their aptitude as "useless leetcode/whiteboard coding".

I've seen someone say they have never used a linked list, not even implemented themselves but used, and, on top of that, that they likely never will. I've also seen someone putting down the most basic knowledge about the most simple data structures (i.e. simple questions about what you can and cannot do efficiently with an array) as "premature optimization".

That thinking worked for their job, so they thought that's universal.

There's a ton of solutions to FizzBuzz that do not use modulo.

(I'm copy/pasting what I answered to another similar comment)

I don't disagree with your first point.

The problem is that asking questions like FizzBuzz is also a filter in the other way. Higher quality candidates aren't going to bother answering your filter question and bail out of the process.

I spent several years working on a large tech hiring platform and a thing we noticed again and again is that putting up any filters immediately drove away top tier candidates. They're just not going to jump through hoops when they have so many other options available to them.

Now if you goal is to hire a more average quality candidate, then you can get away with filter questions, coding tests, etc.

Experienced candidates know why these filter questions are necessary and are going to wonder what they're getting into if nobody is asking any.

I was offered a job that had no filter questions and I declined because of that. They were clearly hiring goofballs into senior positions.

> > I don't care if someone can answer FizzBuzz .... All that can be learned.

> Of course. But... sometimes it isn't.

Right, it goes both ways. If FizzBuzz is so easy to learn, it's reasonable to ask, why are you applying for this position without having already learned it?

Not sure if your question is rhetorical but... lots of people get a SE degree just to earn money and they don't even like programming. They still end up earning lots of money.

Reply on news.ycombinator.com