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.

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

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.

It may have been ruined by this year's Advent of Code, but for over a decade now my standard warm-up question has been: Write a Boolean function that determines whether two closed intervals [a,b] and [c,d] overlap.

No loops are required, no data structures, no algorithms, really: just a simple predicate expression. It is one example of what I think of as "programming in the small", this basic survival skill of being able to relate some values and correctly characterize a situation. You just have to be able to do this correctly if you're going to write correct if statements and while loops. Lots of bugs boil down to errors in examples of this kind of expression.

I've had PhDs from good schools write doubly-nested loops looking for a point in common. I've have very experienced engineers write expressions that have false negatives or false positives. A depressingly small proportion of candidates can think of a good way to test their answers.

I happened to want a generalization of this problem once and I went down a long rabbit hole: https://github.com/RhysU/intersection

Tests, QMC, the works.

I've been programming for decades, and I had to google what "closed interval" means exactly.. I even read quite a lot of mathematics. I don't see the term very often, and manage to forget which is "open" and which is "closed". Guess I don't get the job. :-(

That's an interesting approach and question. I think I might use that. Thanks!

Nearly ten years ago I was asked FizzBuzz over the phone. As in: program it by talking. I'm 90% sure I got it correct, but I believe the interviewer didn't understand the logic of negation on a zero modulus result and I didn't pass. It worked well as a filter for me for that company. Coincidentally, they're on the front page right now for layoffs.

So be careful with this kind of stuff. You may not be filtering what you think you are.

Can you explain what you mean by "the logic of negation on a zero modulus result"? That sounds like a mouthful, does it just mean that the interviewer didn't know that "!(x % 2)" is the same as "x % 2 == 0"?

Yeah something like that. I probably misworded it and my memory is fuzzy after such a long time.

I think this question describes pretty well the profile of some of the interviewers I have found in my live. I also find helpful that this appears on the top of HN and as an advice for the newcomers to the space: "you will find people that want to proof you are an idiot, and more specifically that you are and the interviewer is not"

I ask them to ask me their "idiot filter" question. If they just jump into it, I'll learn something about where they draw that "competence" line - almost invariably just a hair below their own level. If they hesitate, we might have a much more enlightening discussion about why that's such a problematic phrase, and how they feel they would fit into a team that spans different skill types or levels.

My "idiot filter" occurs when parsing resume/CV. If they make it to an interview, and I have to ask "idiot filter" questions (ex: FizzBuzz) to decide whether they're a fit, then I am the idiot in need of filtering.

And sometimes I am.

Nah, I had a bunch of people who had great resumes who couldn't write a loop. People lie on their resumes a lot.

That's a mistake. A lot of people lie on their resumes.

Source: I've lied on every resume I've ever sent out.

To me the best filter questions have these features:

1) Obvious: If the question is failed, even a non-technical hiring manager understands how bad this is.

2) Fast: Quick to ask, quick to answer. Everyone agrees in advance that if it's failed, we can shorten the rest of the interview.

3) True negatives: Some bad candidates might pass the test. But no good candidate will fail.

4) Real: Write real code live in any programming language. Emphasize that perfect syntax is not important.

I've helped interview candidates for student positions, programming teacher positions, junior and intermediate programmer positions. It is shocking to some how often people fail filters like this. My current favourite:

In any programming language, write a program that prints the numbers 1 to 100, except if the number is divisible by 3, then print "turtle" instead. Example:

1

2

turtle

4

5

turtle

7

...

100

Well formalized, I fully agree with that list. It's applicable to pretty much every field by just finding a question that fits all those 4 points (with the obvious alteration of #4, depending on the field, e.g. for a mathematician "perfect notation is not important for this interview" for example).

I actually have the candidates do FizzBuzz! And, it's still amazing how many people can't figure it out, or try and BS their way through it by proposing using a crazy data structure like a B-Tree (true story).

I have a serious question: what kind of job is that? Like what is the job description? I‘m currently working in academia in geoinformatics (mostly with image data, json files and data frames in general as well as the occasional Spatialite or Postgres database) and have no idea where I’d end up outside of academia. I don’t know how good my programming skills are, I don’t know what kind of job I could/will get and what life would look like for me outside of academia.

That's both amazing and disturbing. If you ask me to write FizzBuzz, I can do that with my eyes closed. If you asked me to write FizzBuzz using a B-Tree, I wouldn't have the faintest idea how to do it.

By the way, after they write FizzBuzz, ask them to modify it so that it prints "Rawr" or something if it's divisible by 7. If they printed "FizzBuzz" if it was divisible by 15, do they change their approach? If not, keep adding more strings for more prime factors until they do, or until they melt.

For me the question would be what to print: do I print "Rawr" for e.g. 105 or do I print "FizzBuzz" now? What do we prioritize? Am I missing something?

You would print "FizzBuzzRawr".

We've found that asking them to write a function to average a list of integers. That's filtered out a surprising number of "senior level" applicants.

with(arr)eval(`averaaaaaage=(${join`+`})/length`);

mean = liftA2 (/) sum length

I mean that could satisfy the interviewer, but for me if I asked that question, I'd want an answer that protected against overflow and unfortunately the naive solution is prone to overflow.

That could turn in to a very complex question in that case because dividing too many separate sums before adding would introduce rounding error.

Does that not have to be

    mean = liftA2 (/) sum (fromIntegral . length)

?

Maybe you should ask a question of yourself. Why are you wasting your time and someone else if you think they might be an idiot?

I suspect it’s the OP unwillingness to find the good in people or find commonalities interview process.

That's not a positive method to approach an interview or conversation. If I knew that an interview was going to be a "gotcha" type interview, I would politely pass, I don't need this nonsense.

> Why are you wasting your time and someone else if you think they might be an idiot?

Because I need to hire someone competent. And idiots can (and do) still write good-looking resumes (or get someone else to write it for them).

I guess those idiots are either resourcefully enough or have the creative writing skills to fool you into a interview? Hmm...

a = 7 b = 9

Write a program to make

a == 9 && b == 7

No, I don't care how many new variables you use and what language you use.

Yes, I had people not be able to complete this. I would say this is something that is so basic that:

a) It's not testing any knowledge b) It's basic enough that you can figure out under stress, while never seen it before c) It's short, easy to explain (in 5 different ways if need be), and easy to validate d) It's an idiot filter. It doesn't even test if you can program, it's more like "If you know how type out code, are you also capable of reasoning about the basic logic of that code".

I use Fizzbuzz like you said, and it works like a charm. Interviewing at Netflix I cut at least 1/2 the candidates with that one. People who list "Senior Software Engineer" on their resume but can't write a loop using mod in their favorite language. I question how much you've coded if you can't write a simple loop and Google was allowed!

I rotate through various simple function implementations. It’s important to stick to fundamentals and not introduce anything where a specific context is required. Examples of this are

- function to reverse a string - function to sum an array of integers - function to get a deeply nested property value from an object

Since I work a lot with React and also interview people for that, I use the following to determine if people are at least somewhat familiar with react:

- take a static array of objects (first name, last name) and render a list of those objects

If people can’t write the map function, or are confused about the console warning for needing “key” that is usually a great indicator that they don’t actually know react.

What consistently surprises me is that I’ll interview people with 5-10 years of directly related experience, who will see questions like this and laugh or say it’s trivial, and then absolutely bomb. One person complained that they were senior and above these types of questions, and then spent 20 minutes trying to reverse a string.

That’s strange, it’s taken me like 2 minutes to think of three methods of reversing a string, depending on what you want, space efficiency (use two moving pointers and operate in-place), simplicity (use a new array and a loop starting at the origin’s end), functional semantics (use map() and a bit of modulo math)… I’ve written a lot of software but I wouldn’t even consider myself a professional programmer. What happens to these people, do they get really nervous or do they really not know?

I think there probably are people that get nervous and absolutely blank, that is bound to happen. As an interviewer, what can you really do in those situations? Also to note that looking up documentation is perfectly fine, and I explain that as well. As for others, I think some people graduate out of writing code when they become senior, or something similar. But we make it very clear that senior/lead engineers are primarily writing code, so I don’t think it is a mismatch of expectations. Other people are genuinely overstating their skills and are no programmers. The incentive to lie is there, based on how much money a programmer can make.

What I can 100% relate to: Writing Java for on and off 20 years but if you didn't for a year or two fumbling to start with a blank file and getting the psvm and args right.

But I mean, you should totally get back into at least being able to write something like fizzbuzz in the language you're probably using to write some sample code.

Except trim() vs strip() - that will forever trip me up per language.

For a low level programming backend job:

Tell me everything you know about the hash table data structure.

Plenty of Staff level applicants don’t know anything about it.

There are 3 tiers of answer:

1) Don't know what a hash table is, when to use one, etc. Have never had a candidate in this category this do well in the rest of the interview, even for totally unrelated tasks like distributed system design.

2) Know it's a key-value store, know it's "fast". Some candidates whose main experience is in frontend dev get to this point, and then demonstrate other ability in the rest of the interview and get hired.

3) Rattle off that it's O(1) amortized, might be O(N) in the resize case, chaining vs linear vs quadratic probing vs other clever methods like cuckoo hashing, discuss how those methods effect cache behavior, etc. These candidates typically crush the rest of the interview effortlessly, even totally unrelated tasks like distributed system design.

When I was in college, I had recently implemented hash tables in a data structures class and was interviewing for internships. I gave a detailed answer like (3). The interviewer told me that it was the best answer he’d received for that question.

Now I have several years of experience and am a much more effective engineer. I don’t remember many of the implementation details of a hash table anymore, but I still know how roughly how fast the operations are.

I guess I wouldn’t be applying for “low level programming” jobs, so the expectations are different. Still, I think I’d be better at it than younger-me who just learned data structures.

This^. OP is basically just filtering for people who have experience building hash tables.

You can get into bucket 2 if you just use hash tables and know the most basic information about their use. Plenty of candidates were in this bucket and passed the rest of the interview.

I still gave the rest of the non-hash table interview to every candidate. What I'm saying what the hash table question was a tremendous predictor of candidate success in every other aspect of the interview. System design, algorithms, problem solving, etc.

Candidates that didn't know anything about a hash table, even just the most basic idea of "fast insert/lookup/delete key-value datastructure", almost universally failed almost every aspect of the rest of the interview.

Candidates that know the basics could go either way.

Candidates that know all the details almost universally crushed every other aspect, including very unrelated things like distributed system design.

For people with recent experience building hash tables. What sticks over the years is how you work with them and where they are a good solution to a problem. The more experience you have in using them, the less likely you are to remember how to build them, because that information was never used and got pushed out of memory by all of the other things an experienced developer needs to remember.

Not even that.

There are people out there who have built hash tables, who don't even know what they've built is called a hash table by educated folks. I know this, because I formerly happened to have worked with such a guy, after needing to change some of his code and discussing it with him.

That reminds me of an interview where I was asked about something about "a module", to which I responded that I needed some clarification, and rattling off like 4 different uses of the word, only to be meant by a blank stare because supposedly I was to guess whatever specific technical term in $techstack the person was referring to.

They did say "low level programming backend job". At least a large subset of what they mentioned should be common knowledge then.

It sounds like you'd fall into bucket 2, and would probably pass the rest of the interview on other merits.

This low level programming job, we were implementing filesystems from scratch. Very, very data-structure heavy.

I don’t don’t do this kind of questioning. I find it useful to give an open question like:

Design a website with a user login, a password reset feature. And then go on from there.

E.g. talk about how to build your infrastructure. How to protect against CSRF. What is your stance in tokens in the front end. What about sessions. How to do force logout. Which database, why? When to use caching. How would you store Information about a password in a database in a safe manner. Salting hashing.

Synchronous vs asynchronous api. Idempotency. Different database transaction mechanism. How to do monitoring. Why is cardinality important for prometheus. How to do api first design.

This gives the candidate time to shine and I can at least understand where they are. And you can dig deeper.

I asked this a lot, and honestly loved these interviews and the conversations that stemmed from it. It turns out many candidates may work on either side of HTTP and be reasonably ok candidates who just happened to not be familiar with this part of the stack. Great candidates understood all this stuff, but not being good there didn't mean the candidate was bad, sometimes only that their strong suit was somewhere else. I think a good interviewer should be good at identifying that sort of "knowledge perimeter" where the candidate is strong.

A lot of this doesn't work with junior candidates, they just don't have the exposure to this stuff in school. Knowledge is really just one part of the equation too.

But what you can find out is that the candidate is honest and will tell you he/she does not know the answer.

In the end you want to work together on things and you want to know how the person ticks.

So a self reflected, honest candidate is good and at least I have the impression you can assess where you would need to provide support /trainings for the candidate, or how self learning would work

What do you change if it's clear that the candidate is completely incapable of doing any of those things? Do you cut it short? Talk them through it step-by-step? Unfortunately I've found that not all candidates who get through a recruiter can do what they say they can, so I keep a question at the very start that eats up maybe 5-15 minutes (sometimes less) for a good candidate, but some very bad candidates spend a full 45 minutes on it and don't finish.

The interview will be very short once you've gone through your questions, that's all. For your 5-15 minute question, I don't know the nature of it, but why don't you just move on with reference to time? I'm sure you have a lot of other questions you should ask. It is on the interviewer to be the timekeeper of the interview.

I was curious about the parent commenter's approach with the sorts of questions they ask as they are more open-ended, but also somewhat knowledge-gated. I was interested in any potentially unique techniques they employ. However, I was not looking to specifically fix anything with how I conduct my interviews.

My first question is a very specific coding question and it's a weed-out question. So if someone doesn't figure it out, they've been weeded out, simple as that. I ensure that candidates don't waste time figuring out nit-picky edge-cases and give appropriate hints when they're utterly stuck, but the question does its job very well.

What questions do you have for me?

Works for non-software engineers too. Filters out if they've done any research at all into our work and if they're curious.

I don't care for this question.

A lot of time I ask hard questions like what is the company's revenue model or the company's growth strategy, where do you see the company in 5 years? That can scare a senior developer... then they get angry with me because I have turned the tables and made the person think in a non-binary way.

I don't like this question in some cases.

What if they prepared with specific questions but you answered them during the interview?

What if a previous interviewer answered their outstanding questions?

Is curiosity about the company the trait you want to optimize for? In other words, does that curiosity translate to job performance?

I also think this question being so open ended and vague will lead you to get a lot of bad/blank answers. What should I be asking questions about?

I have a standard question I ask (in addition to any other curiosity questions): "what is one thing you like about the company/work environment, and what is one thing that you would change if you could?" After a few people it gives a decent picture of what the down sides are.

I'm 90% sure I was rejected by a github recruiter for not having questions. The problem is I know a decent amount about github, and the product the role related to.

And, as you might expect, people do tend to put the answers to the common questions in the job description.

Do you know how team dynamics work day-to-day? What the relationship between the product team and developers is like? Who drives new features? How is work assigned and scheduled? How big are teams? What are teams structured like? Is there frequent movement between teams?

Ask questions that aren't easy to find out without asking current employees, and that don't put employees on the spot. I can do that for hours.

With execs, questions turn more to product roadmaps, marketplace fit, revenues and budgeting, but again, I bet I can come up with interesting and practical questions longer than any slot any interviewer has in their calendar.

It's possible that the recruiter was expecting questions like the above, and saw your reasonable confidence as either over-confidence, incuriosity, or both.

I was talking to a recruiter. It's very unlikely they'd know any of that.

I think it is important to remember that you are catching a person on their journey of acquiring and internalizing information. The reservoir of available information is almost limitless - so no one is going to come close to knowing it all. No point in testing for that. We all navigate the world on different trajectories through this network of information - so your milestones may not be the same as theirs. No point in confirming that theirs are the same as yours.

What you want to look for is their ability to process information, ability to internalize it, and their ability to bring it to bear in solving the problems they will be confronted with. You may have to do this with markers that don't necessarily match your own.

The richness of the network of information they have acquired so far is a marker. The nuances of the insights into that information they have acquired is a marker. The organization of this information into readily usable tools is a marker. These are what you should be looking for, rather than some preconceived ideas of what the markers need to be.

Not being from the USA this has been an interesting and a bit shocking read. To me this approach to job interviewing seems overly paranoid, suspicious, and akin to harassment. Also asking random general riddles that are not specifically related to the specific job function in question seems so weird that if I was the Interviewee I would seriously reconsider if such a company would be worth working for at all as disrespect like this in the interview process would likely be reflected in overall company culture.

Disclosure: I do not even know if the title "Software Engineer" in the USA requires a formal education as such. I do not hold that title myself, I've just been working in IT for three-plus decades and provided net positive bottom line value to every firm I've worked for along the way.

Most, if not all, of the "idiot-filter questions" (note the tone?) in this thread, I've seen for the first time today.

I ask to live-design a quadratic equation solving function (the basic method is provided for those who forgot it) and to discuss decisions done. It tests for edge/degenerate case awareness, numeric issues, experience with multiple results specific to a language, and for choosing a prototype that fits the bigger task.

I don’t care if it’s buggy, how much time it takes or whether the first scratch is any good, because it shows fundamental things every decent programmer knows or knows how to discuss and reason about imo. Unlike fizzbuzz, if you pre-solve this question at home and remember these details, you’re already good enough for the next question.

> I ask to live-design a quadratic equation solving function

I’ve been programming for a decade, was a Linux/cloud engineer a decade before that, I’ve had code on the front page of google, launched products for Microsoft, and had my code shown on stage at nodeconf and aws re:invent. I am currently top 0.07% on stack overflow. I can answer the other questions in this discussion easily. I would absolutely fail this.

Solving quadratic equations is just plugging numbers into the two versions of the quadratic formula.

I can understand forgetting the quadratic formula, but the idea is taught to every school student who takes algebra.

Serious question: why? If I understand OP correctly, it's a 1 line math equation which is provided if necessary and you just need to turn into some useable interface?

I don’t understand. The simple formula is provided, all they’re expected to do is to

- figure out what parameters should look like

- detect edge cases (e.g. division by zero when a==0 or sqrt of negative value)

- and discuss its usage (how to return 0, 1, 2 roots and how you signal it to the caller so it’s convenient)

And this is not a silent-wait quiz. When they seem confused I ask directly what it would return if `a` is zero. Or tell that a, b and c are parameters to such equation.

Anyway, maybe it’s sort of a TIL moment and I should stick more to fizzbuzz with periods changed or to string reversal.

But I feel confused about it as hell.

I dive into math occasionally when working on animation and (real) crypto, and then forget about it when I go back to whatever I'm working on.

Actually looking up the formula for the first time in 20 years it's readable (i.e. doesn't use symbols I don't already know) so yes I'd be able to solve it. That's not guaranteed with every formula though.

Agreed, you can be absolutely horrible at math and be a fantastic programmer. I always found math easy in school but 5+ years later if someone asked me to write a quadratic function solving function I’d have no idea what that even means. Presumably with a guide I could write the code, but that’s so far removed from the type of work I do day to day

Thank you. A lot of the questions in this thread have me seriously doubting myself.

even with the quadratic equation provided?!

Finding unique values (i.e. Deduplicating) using a Set/HashSet; hell, even just using a HashMap with boolean keys would give a passing grade (esp in languages like Go where that's how it's done).

Go would use the value as the key and boolean or `struct{}{}` for the map value.

Similar in Python

Also know as "FizzBuzz" ... I suggest you do a search for that term:

https://hn.algolia.com/?q=fizzbuzz

Thats the one, thanks

Solving FizzBuzz is not the issue, that's just getting the candidate to write a template for the basis of a subsequent discussion on code structure, trade-offs, requirements analysis, and more.

Besides, in interview a candidate wouldn't use ChatGPT anyway, so I'm not sure how relevant is your comment.

Can ChatGPT replace you in an interview?

It's possible that ChatGPT or a similar language model could be used in an interview, but there are a few reasons why it might not be the best idea. For one, language models like ChatGPT are not able to browse the web or access external information, so they can only provide answers based on the information they have been trained on. This means that they may not be able to provide detailed or up-to-date answers to questions about current events or other topics that require knowledge of information that is not included in their training data. Additionally, language models are not capable of thinking or understanding the world in the same way that humans do, so they may not be able to provide nuanced or complex answers to open-ended questions.

Another issue is that it’s super obvious when a post like yours is authored by ChatGPT.

I already hate the effect ChatGPT is having on the entire internet. I don't want to read a paragraph of machine-generated pablum like this.

sus

What is a semaphore?

I wouldn't say you're an idiot if you don't know the answer, but we need people who can work with concurrency and a surprising number of developers haven't.

Funnily enough, coming from a telecommunications background, a semaphore will always make me think about Claude Chappe and his optical telegraph [1].

[1] https://en.wikipedia.org/wiki/Optical_telegraph

You don't usually use semaphores directly in modern programming languages. Go does everything with channels and Rust covers a lot of cases with static analysis, and has built-in high level concurrent primitives for the rest.

Perhaps so, but the synchronization primitives leak out eventually, e.g. while profiling or debugging. Semaphores also exist in other contexts, like POSIX/IPC, distributed semaphores etc.

Even if you did manage to avoid them entirely, it would suggest a lack of curiosity if you've never looked into how concurrency is implemented beneath the surface.

Even if it's not available (I haven't programmed in Go), I think most of programmers who run parallel code in Go know what is a semaphore or a mutex, don't you think?

I ask for a truth table for AND or OR. You won't believe how many programmers can't answer this question.

Web development: list and discuss HTTP methods.

I even go as far as avoiding writing code in the first place. You can give a very simple imaginary problem to solve and see how they think. I believe good software engineers are essentially problem solvers, the code just happens to be the tool for it.

I have asked to estimate the amounts of skittles in a litre cube box.

If nobody at your company requires a candidate to write code, you won't filter out the candidates who can't code, and they'll be working with you, not with companies that require candidates to write code.

Even the easiest five-minute coding problem is better than nothing.

Yes, but the OP asked for an idiot-filter first.

We end up applying multiple filters throughout the process, but try similarly to keep them as simple as possible not to too strongly bias for one thing.

I find that a horrible question.

I've not had skittles in years, are they as big as smarties? I think a little smaller? Sure, you can start your estimation by laying them down in a 10x10 grid, and stacked 20 high, but that's very far off. Maybe 13x13x20? So that would be the most loosely packed version, if we shift them off so that layer+1 is in the depressions of layer+0, maybe we can stack 30 high. So yeah, that's my best mathematical approach and I guess it's at least 50% off.

Did I pass?

Serious question - what kind of book should one read to get into a mindset of answering such questions? Like fizzbuzz? I understand I can just gptoogle many of the questions, but is there a reading that can help to get to such a mindset from fundamentals?

It's clearly not something like "Code Complete"

When I was in college, cracking the code interview book was decent.

Go to Leetcode and start doing problems.

Speaking as an idiot trying to get hired in the depths of the dot com bust for programming in javascript that I did not yet know two that stumped me were:

Is javascript case sensitive (I got the answer right purely by guessing, but the hesitation gave me away) ?

What is a closure?

Do you work in a particularly mathematical field?

I've been working in tech for 15 years now, and can't remember any time that I've needed to use imaginary numbers. The only reason I still remember anything about them is because my hobby is electronics.

I have to agree. I love imaginary numbers, the complex exponential, both the s-plane and the z-plane. Because, like yours, my hobby is electronics.

Neither as a low level system programmer, nor in any of my high level programming jobs a long long time ago, have I ever needed imaginary numbers. Privately yes, but that's just when writing code for my hobby.

I ise imaginary numbers every day as a developer!

«Yes thats a quick 15 minute fix»

That number 15 turns out to be very imaginary most of the time :(

You might want to phrase it as the square root of negative one in the future.

Why?

Because "minus" is the boolean subtraction operator not the unary negation operator despite a lot of colloquial misuse by native speakers.

The distinction is useful when reading aloud expressions like 3-(-2) as "three minus negative two".

Perhaps, but "negative one" would sound a little odd to lot of people from certain countries, including the UK, where "minus one" is the standard way of referring to a negative number. We would be perfectly okay with hearing "three minus minus two" in mathematical context.

Americans would be OK hearing that too. It's just a more complicated grammar to parse.

Curiosity: How do you call the terminals on a battery?

Positive and negative for battery terminals.

But "minus five degrees" for temperature ;)

"tell me about a project you built recently."

not idiot-proof but enough to inform me on what level we're working with, what their thought process is like, what tech they know, etc.

How many operations per second can a modern CPU perform? thousands, millions, billions, trillions?

If radix sort is O(n) why don't we use it for everything?

Because radix sort is not O(N). It's a common misconception and luckily most modern algorithms books do not make that mistake anymore, although it seems to have been common in the past.

Radix sort is O(k * N) where k is the length of the key, and it's worth noting that there is a fundamental dependency between the length of a key and the size of a data set in that k scales with log(N), so that ultimately radix sort is O(NlogN).

So at this point it just comes down to comparing radix sort against other sorting algorithms in terms of constant factors, and radix sort certain has some use cases, but not many. One area where it excels is sorting enormous data sets that can be parallelized.

You passed!

Common less correct answers:

- Because it only works on integers and you need comparison for general sorting. (Wrong, you can embed basically anything you want to sort into a fixed width int)

- Wide eyes and staring silently

I like this as a filter question because:

- skips directly to, do you know CS fundimentals

- requires them to tell me I'm wrong (if they can't do that thier competency is irrelevant)

- requires that they actually think about the implications of what they were taught and reconciles them against reality.

If you don't have those qualities, you probably won't be useful as an employee or coworker.