Fizzbuzz would be completely fine. Companies out there ask devs to solve highly niche cryptic tasks like the knapsack problem for no reason.
Fizzbuzz would be completely fine. Companies out there ask devs to solve highly niche cryptic tasks like the knapsack problem for no reason.
Yeah I think the fundamental reason this gets debated so much is that "whiteboard interviewing" encompasses both fizzbuzz, and leetcode dynamic programming nonsense. Some people are saying "fizzbuzz is great!" and others are saying "no you're totally wrong, leetcode is terrible".
Even this article falls into this trap. The first thing he quotes is fizzbuzz-level, but then the research paper he uses to argue against fizzbuzz actually used a much harder leetcode style problem.
IMO fizzbuzz-level problems are totally fine. You can't really argue against them. They filter out tons of people who I wouldn't want to hire, and nobody who should be hired can fail them, even under ridiculous pressure.
It's more debatable when you get to actually difficult algorithm problems but that's another argument.
(Also fizzbuzz itself is a pretty terrible "simple" problem because it feels like there should be an elegant "trick" solution but there actually isn't. Don't actually use fizzbuzz. The example in this article - filter out odd numbers from a list - is totally fine though.)
Meta phone screens currently involve 2 medium/hard leetcode problems AND 20 minutes of behavioral questions. The inmates (i.e. we programmers) are running the asylum.
who can pass this except recent college grads?
I wouldn't have any time to prepare for this unless I was laid off unexpectedly, then grinding leetcode would be a full time job for a while.
> who can pass this except recent college grads?
I can. So can a lot of the better candidates I interviewed. Most googlers and fb engineers can pass this stuff too.
Theres a much better way to test for senior engineers though, and it’s this: prepare a small program (200 lines or so) with some bugs in it. Write a few test cases which highlight the bugs. Then give the candidate the code and the tests and ask them to fix the buggy code.
Good senior engineers - in my experience - aren’t better than smart young grads at programming. But they’re soooo much better at reading code and debugging it.
I interviewed this insanely good Ruby engineer once. He had the body of a bear, and a bushy, greying beard to match. During the interview he gave me a masterclass at debugging. Before he even looked at our tests, he read the code and named out loud assumptions he was making about it. Then he started writing his own test suite to validate those assumptions during the interview. He fixed a few of our bugs before he even looked at our tests, in the first 10 minutes of the assessment. And he fixed another bug we didn’t know about. I can’t remember how he did at the programming section of our interview. But I’d hire him in a heartbeat from watching him debug.
The one thing to keep in mind if you do this is that most people will overestimate how much debugging you can do in half an hour or an hour and overcomplicate the program you give candidates. If you make a test like this, make the code simpler than you think and actually calibrate its difficulty with your coworkers.
Me. Because, for about 2 weeks during lay-off gardening leave, I did study it.
On one hand this demonstrates that it isn't useful for testing innate skill.
On the other hand, it was the best paid work I've ever done. It was an essential part in me getting a job (not at Meta) that paid multiples better than previous roles.
This work allowed me to place myself in a group of people who can pass the test. Some of the people who are outside this group would make fine employees but don't want to or think to put in this work, for understandable reasons. But all of the lackadaisical applicants will fall outside this group. I get to signal that I'm not one of them.
I spent 4 years in higher education for a non-essential positive signal to employers: 2 weeks is nothing.
In the past I hated Leetcode, now I've begun to think of it as an opportunity. While as an individual my opportunity to shift the consensus on this form of interview is low, my opportunity to benefit from the arbitrage is high. Don't hate the player, etc.
Hah totally. When I was interviewing professionally, we emailed candidates a document describing our interview process. We told them in that document what we’d ask and told them how they could prepare.
Almost nobody bothered to read that document before the interview. And the people who did were usually the better candidates. We joked internally about skipping the entire interview process, and just passing everyone who read our study notes.
I once got asked to write a Levenshtein edit distance calculator for a “15 minute” SRE phone screen
I'm not sure I could write that even with a full day.
Even if I did, the solution would probably end up running in O(n!) time.