Hacker News Reader

Comment by monocasa | Hacker News Reader

I'm amused at the idea that because I pass on senior devs who literally can't do FizzBuzz, that I must have a terrible interview process.

View on HN

Sure. But, of course there is a difference between having a conversation about the overall trends of a practice versus a small subset of personal experiences. It's also important to define what you mean by "can't do FizzBuzz". Like they can't even do a basic loop or they don't get it perfect, in the exact way you think it should be? Because those are very different as well. I think it's fair to say that if you get a senior Dev in that can't even write out an if-else statement checking for 3 and 5 you have a problem.

> It's also important to define what you mean by "can't do FizzBuzz". Like they can't even do a basic loop or they don't get it perfect, in the exact way you think it should be?

Like literally can't do a basic loop. I'm not looking for 'my solution', I'm looking for any solution.

> I think it's fair to say that if you get a senior Dev in that can't even write out an if-else statement checking for 3 and 5 you have a problem.

And yet, I can tell you from experience that there's someone out there who (at least was on the team that) wrote firmware for the space shuttle that literally can't if-else with modulus despite having a great looking resume. And they are far from alone.

Why didn't you check references? I mean wouldn't you consider it a failure that you got a candidate to the interview table that was so bad? Assuming you aren't making it up, the guy was obviously lying on his resume, that could have easily been solved by checking his references.

Most places that firmware devs come from around here have a policy of only verifying dates of employment. That doesn't tell you much.

References would be personal references - someone with a cell number and call the college he attended; they should also verify enrollment and completion. You don't want to be calling the HR department. Also, a secret is if the reference (not HR) only verifies employment, that's a negative review. They are concerned about liability. If it was a good employee, the references have no qualms about saying so; it's the negative aspects that carry legal liability.

You need to ask for those, not just prior companies. My resume has a "References available upon request" at the bottom and I'd happily give them. Is that no longer practiced? It used to be a requirement.

> References would be personal references - someone with a cell number and call the college he attended; they should also verify enrollment and completion.

Yeah, right. Personal references aren't worth squat because nobody gives references that are going to badmouth them.

The worst hire I've ever seen had a highly positive reference from a previous job.

It certainly isn't perfect. You have to interview the reference a little too, not just "how was he?"

Most companies, period, will have a policy of only verifying dates of employment. They don't want to get sued from telling the truth about the candidate and costing him the job offer.

FWIW my FizzBuzz solution involves no 'for' loops, and in fact involves no control-flow keywords at all.

Haha, I'd love to see it if that's true. I love cool approaches to computation. FWIW as long as you can back it up with knowledge of what the relevant tradeoffs are (and don't scoff at a more KISS attitude for doing actual work), you're pretty much guaranteed to get a thumbs up from me if you give an answer off the beaten path.

I dislike traditional phone screens enough that I hone unusual solutions for them. And when they get evil enough, I put them in a public repository.

Here's my FizzBuzz:

https://github.com/ubernostrum/interviewer-hell/blob/master/...

That's awesome! I'd probably follow up that, since I generally interview for real time, firmware jobs, we try to clearly bound execution time, and therefore frown against more functional techniques like that. But you clearly know how to program well and would most likely get a thumbs up. : )

Admittedly most of my phone-screen solutions aren't tuned for performance; they're tuned to make people scratch their heads.

My code for "detect if a number is a perfect square", though, is O(sqrt(n)) time and O(1) space and uses no floating point operations. Which isn't quite Newton's method, but also saves me having to memorize an implementation of Newton's method and appropriately causes confusion. Here it is in Python, with obfuscation help from itertools:

https://github.com/ubernostrum/interviewer-hell/blob/master/...

And slightly less obfuscated C:

https://github.com/ubernostrum/interviewer-hell/blob/master/...

How is that not iterating (admittedly within the stdlib methods)? They are not literally for loops, but the same concept of iteration.

Reply on news.ycombinator.com