Comment by sumtechguy | Hacker News Reader

Comment by sumtechguy | Hacker News Reader

Parent Full thread

This is really why I use the 'easy' type questions (some variation of fizbuzz or something simple). A senior guy will crank it out in 5-10 mins. I then ask a question or two on how to improve it and a mini walk through of what they did and why. I also make it clear I sometimes get people who just can not do it but have the resume chops for it. I then usually spend the rest of the time digging on previous techs they have used, problems solved, etc.

The annoying ones are dudes who want you to somehow do a big O proof of some NP complete problem, with tests, proper code, and in front of 3 people in 45 mins (with 5 left for you to ask any questions). For something you may have not touched in 20+ years. I do not want a guy who can create the proof. I want a guy who can explain it in plain English to the 3 other guys in the group and maybe take a few days to get it right and make the code easy enough to understand so when we have to change it in 8 months they can pick it back up.

This is true. I interviewed someone for a senior eng role the other day and when asked a couple basic CS questions that were not simply trivia, the candidate fell apart totally. Like asking basic DB questions to a DBA candidate, or asking basic web/css/html questions to a frontend developer. They immediately went to the back of the line.

Please share the questions. I always find it amusing that tech types seem to believe their idea of “basic X knowledge” translates across the board. I think it’s this attitude of “oh you don’t know what I think you should know” that proliferates the industry that is a major part of the problem. How do you handle folks that don’t have even the most basic form of formal “CS knowledge” but can still ship product? Do you just dismiss them completely over being able to have a water cooler talk about O(...) and some algorithm someone would never have to implement in that specific context? Seems like a premature optimization to me.

+1 Very well said. I've actually experience this first hand while interviewing for one of the FAANGs. I have a background with embedded software engineering, working with C/C++, and working with low level I/O and bare-metal + using RTOS, and also Unix/Linux, and the position I was being interviewed for was for an "Embedded Developer." The job description described the role working on their RTOS. During the phone interview, the interviewer asked a question that (later I found out) can only be solved optimally using splay trees or red-black trees.

I have worked in the embedded industry for 6 years, and have worked on a wide variety of projects (from WiFi to drones/airplanes to medical devices), and have never needed to use this, yet the interviewer expected me to know this.

Anecdotally speaking, when recruiters throw this kind of curve balls, it's because they already have someone in mind for that position and are interviewing candidates just to fill paperwork.

Yes, please share the questions.

+1 for fizzbuzz. It still amazes me how this simple little test can often weed out a largish portion of candidates early on.

I do not use fizzbuzz but variations that are simple like it. I do not like fizzbuzz for 2 reasons. It relies on a math trick. Modulus math is something everyone can grasp but it is not something everyone knows about. Plus it is easily looked up and gamed. I try to pick something that has a few if conditions and a loop, which is what most people do. Bonus if it can be a 'refactor' style problem for the small walkthrough afterwards. But it is not necessary for that. If I were to make one up right now I would say something like 'given a string reverse the first half and move the second half to the front of the string and return the result'. There are enough little gotchas there to see if they have a feel for what can go wrong and loops and ifs. It also has an advantage that it is not easily looked up on the internet and pre-studied as fizzbuzz has been codegolfed on some discussions. The downside is it would probably burn a lot of time. So you need to budget your time with them accordingly. If I can talk someone into it I try the test out on them beforehand to see how long it would take. I want it to be quick. I just want someone who is competent and can explain what they did and has some relatable experience and can explain what they did there.

One of my goto fizzbuzz-like variations is windowed mean - how would you implement a class with a method accepting and returning a number, such that the number returned is the mean of the last 100 numbers the method was called with.

Some people ask more clarifying questions than others, but in any case a few minutes gets spent on this, we have a laugh and move on with our lives.

Of the failing candidates, around one in three or so spend nearly the entire interview on this or fail to answer entirely because they can't get the maths right.

Is that a "math trick"? It doesn't feel too different to fizzbuzz. It's not complex. It relies on high school maths, and except for very junior positions, for a job where you are expected to solve much more complex problems every day without handholding, even if you can't remember how averages work so I have to hand you the math, not being able to reason through the problem from first principles seems like a pretty big red flag for your problem solving skills to me.

What do people think?

That kind of math is fine. The mod operator is not one that everyone uses but add/sub/mul/div is something most people use all the time. It is why I avoid mod in that situation.

Once I show someone the 'mod' trick they instantly get it (if they have any sort of math background) but I want to avoid as much as possible anything tricky in a interview. I want them relaxed and not tense. As that is a different kind of test. Throwing in a trivia trick can hurt the interview. I have run across many programmers that are decent at it and have never used it.

Also for your problem it would depend on the level you are interviewing for and how much time you want to allocate for it. As it is also a balance of filter and getting to know them which is mostly time management on your part. Remember you probably are going to be working with them. So a bit of chit chat goes a long way too. You can also use 'fizzbuzz' as a question 'do you know the trick of fizzbuzz'. If I show them the mod trick and they get it right away they show aptitude to learn. If they already know it then see if they can explain it. etc etc... Get them to talk. Also talk back to them like a peer as they very well could be! They should be interviewing you too.

I just try to avoid tricky bits in interviews and expecting tricky results from them. It would be like asking the to write a swap two values function and expecting the triple xor solution. Tricky is for something you have been working on for 3 weeks and need a better solution, plus two spike stories. It is not for interviews. :) Just ask yourself would you be massively annoyed if someone asked you this in an interview with no context as to why and expected a particular answer. If the answer is you would be annoyed then do not do it. If you feel it is OK and you would expect it then go for it. Just remember your time management.

I mean, "is x divisible by y?" is only one aspect of fizzbuzz, and something that can be solved in many ways - you don't have to use the mod trick. You could write a function that uses a loop and subtraction to do that bit, if it comes down to it. If I just want to see you can code I'll take it and move on, and if I'm at a point in the interview where I am looking for something else then that's a conversation starter.

But if you are applying for a programming position and claim a decade of programming experience - and literally can't come up with any path towards a solution - I smell a rat.

thats fair

Reply on news.ycombinator.com