What is your go-to question in interviews that you would expect any competent software engineer to be able to answer. Like, for example, the FizzBuzz test. Though yours doesn't necessarily have to be a code challenge.<p>(edit: fixed fizzbuzz name)
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.<p>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.<p>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.<p>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.
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.<p>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.<p>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.
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 <i>me</i> for that company. Coincidentally, they're on the front page right now for layoffs.<p>So be careful with this kind of stuff. You may not be filtering what you think you are.
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.<p>And sometimes I am.
To me the best filter questions have these features:<p>1) Obvious: If the question is failed, even a non-technical hiring manager understands how bad this is.<p>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.<p>3) True negatives: Some bad candidates might pass the test. But no good candidate will fail.<p>4) Real: Write real code live in any programming language. Emphasize that perfect syntax is not important.<p>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:<p>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:<p>1<p>2<p>turtle<p>4<p>5<p>turtle<p>7<p>...<p>100
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).
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.
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?<p>I suspect it’s the OP unwillingness to find the good in people or find commonalities interview process.<p>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.
a = 7
b = 9<p>Write a program to make<p>a == 9 && b == 7<p>No, I don't care how many new variables you use and what language you use.<p>Yes, I had people not be able to complete this.
I would say this is something that is so basic that:<p>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 <i>and Google was allowed!</i>
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<p>- function to reverse a string
- function to sum an array of integers
- function to get a deeply nested property value from an object<p>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:<p>- take a static array of objects (first name, last name) and render a list of those objects<p>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.<p>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.
For a low level programming backend job:<p>Tell me everything you know about the hash table data structure.<p>Plenty of Staff level applicants don’t know anything about it.<p>There are 3 tiers of answer:<p>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.<p>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.<p>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.
I don’t don’t do this kind of questioning. I find it useful to give an open question like:<p>Design a website with a user login, a password reset feature.
And then go on from there.<p>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.<p>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.<p>This gives the candidate time to shine and I can at least understand where they are. And you can dig deeper.
What questions do you have for me?<p>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 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.<p>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.<p>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.<p>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.<p>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.<p>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.
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).
Also know as "FizzBuzz" ... I suggest you do a search for that term:<p><a href="https://hn.algolia.com/?q=fizzbuzz" rel="nofollow">https://hn.algolia.com/?q=fizzbuzz</a>
What is a semaphore?<p>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.
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.<p>I have asked to estimate the amounts of skittles in a litre cube box.
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?<p>It's clearly not something like "Code Complete"
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:<p>Is javascript case sensitive (I got the answer right purely by guessing, but the hesitation gave me away) ?<p>What is a closure?
I like to know that candidates can recall their study. For engineers, one of the biggest mathematical learnings in their degree is the study and use of imaginary numbers. In Australia this is taught in year 11/12 and is taught to kids who show aptitude towards STEM. Identifying these early adopters has worked well for us.
So the go to question that we use a lot is
"What is the square root of minus one?".<p>This culls a lot of non mathematical people. (And we find that Mathematical people generally make for better STEM employees in a tech setting).<p>If they answer correctly (and many who get through the initial resume culling process do) then we follow up with a second question that is not important to answer but will show a candidates sense of curiousity (super important).<p>What is the answer to the first question to the power of the answer to the first question?<p>Fascinating answer to this second question that can delight the candidates we are after.
"tell me about a project you built recently."<p>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.