Hacker News Reader

I believe the hate comes from unprecedented and hard CS questions asked on the whiteboard.

I recently went to an interview that asked me to balance a binary tree on a whiteboard. It can be done, and I can do it. Thing is when you go to interview for that company that has 2 developers(small team, small company) and ask you that kind of question it puts you off thinking that those guys won't be great to work with (arrogance etc comes in mind).

I am fond of simpler questions, like you said fizzbuz etc. Obviously if you are interviewing a guy that has 2+ years of experience, he has to be able to pass the fizzbuzz test. When you are interviewing someone with 5+ years of experience for a higher up position I guess you do have to ask some harder question, but I personally think just speaking to the guy and asking him stuff about his past projects etc will give you a hint on if he has the skills he is talking about or not. Asking him to outline a hard task he took part and how he solved it is an amazing start. As a 5+ years guy personally would rumble about a few things and it would take me days talking about them. (That will give you an understanding if I've worked before or not on the things outlined on my CV).

Last year our lead tech interviewed a guy that couldn't even conceptually get FizzBuzz...

This can also be an education problem. There can be big mismatches in what is easy and hard

If you're coming from a more FP background things like flipping a binary tree are silly obvious. If you spend a lot of time with C++, of course you know how to write a linked list with memory management. Python devs are probably way better at slicing and dicing data

There's a certain expectation of what's easy and hard, but it's really easy to have a mismatch given the diversity of education out there.

It's also that coders tend to... err... "offload" memory for the stuff they aren't immediately using on a daily basis, and only remember the general terms and names that would be enough to find and remember the details shall they be required.

Last time I've had to do something with the trees implementation details (IIRC, that was AVL trees) was, like, 5 years ago. Right now, I don't exactly remember anything about AVL trees except for they have that nice O(log n) for lookups, insertions and deletions. Would I need to code them from scratch (or remember their internal workings for any other reason, like debugging some core dump), I'd go find the algorithm description (or particular implementation's source) and do so.

At the same time, last time I've worked with balanced trees was just a few days ago, but that was Erlang's `gb_trees` module that did all the stuff and I just had to freshen my memory on the syntax details.

All I would be able to do on a whiteboard is stare for a minute, trying to remember stuff, then probably say "uh, sorry, I don't remember this stuff - haven't did that in a long while". Yes, that makes me a worse programmer, I guess, but are interviewers actually looking for those who remember everything in their head and write code on whiteboard? Looks like a weird case to me that doesn't have to do anything with reality.

I've been coding for about 25 years. The last time I had to write any code related to binary trees was in school, 15-16 years ago.

Given enough time and debugging I'm sure I could do it. I'm not going to be successful on a whiteboard though. If I actually had to do it I'd look it up instead of wasting my time figuring it out.

Unless you're interviewing for a position where they'll have to implement binary trees you shouldn't be wasting time asking about code for them. Questions should be relevant to the position.

Additionally: Nine times out of ten, you shouldn't be implementing the binary tree in the first place. There are already tons of tested, robust libraries out there that will do it a lot better than you can, handling all conceivable edge cases, available in a variety of license flavors. Many languages' standard libraries include support for binary trees.

You want candidates who can work through the buy-vs-build tradeoffs.

Reminds me of when I was asked to implement a filesystem API in C or C++ with file manipulation and path parsing and whatnot. The best answer I can think of is usually "With no weird constraints given (is this an embedded system, for example?) just use boost::filesystem and move on with your life." Not impressed with this answer, the interviewer would continue with "assume you can't use Boost!" Next answer is: "There are a variety of filesystem abstractions already written, far better than I could whiteboard. I'd go through each one and pick the one most suitable to the project." I thought it was a trick question at first. You really DO NOT want candidates who hear that question and launch into writing code!!

It's obvious that they're not going to use the code you wrote at an interview in production. So "just use a library" is not a relevant answer. The question was probably posed to give you an interesting engineering challenge to work through with the interviewer so that they could see your problem solving process. Instead you just argued with the interviewer.

The GP's point (which I supported) is that it's a waste of time to take a candidate through scenarios that are not at least similar to what they'd actually encounter doing the actual job.

But the point is that if you cant do something so simple, like traverse a tree, then you probably don't understand how trees work to begin with.

Similarly, I've never had to implement fizz buzz for real, actual, work. But I wouldn't trust a programmer who was incapable of doing fizz buzz without importing a fizz buzz library.

But the earlier comment wasn't talking about _traversing_ a tree, it was talking about _balancing_ it, which is a much harder problem and one I wouldn't want to do without google either.

It took me 5 minutes on my laptop at home to code out a problem that I danced around for an hour on a whiteboard being stared down at by 2 engineers in silence. Yes, I had the benefit of hindsight, but unless you've actually done a whiteboard interview yourself where your livelihood is on the line for an hour, don't act like a trivialising nonce.

> I do use the whiteboard for trivial CS questions limited to 5-10 minutes. Think fizzbuzz and string reversal.

Why do people keep saying string reversal is easy? Text is one of the hardest things out there. Unless you expect your programmers to support ASCII only?

Why not reverse a list or an array? That does sound like something that is doable in 5-10 minutes.

Thank you. A great response to "reverse a string" is "What's the encoding?" If it's anything but ASCII, you're in for a long white boarding session. If the interviewer doesn't know what you're talking about, back away slowly......

what makes other encodings hard ? The two things that come to my mind are byte length and comparison function. If the encoding had a fixed-length byte length, then it should be just swapping n-bytes at a time instead of 1-byte. What else is difficult about non-ascii encodings ?

Some examples: If you're dealing with UTF-8, which is very common, you need to handle variable-length characters. If you're working with UTF-16 you need to handle surrogate pairs. Neither are the end of the world, but the basic "array walking" string reversal methods you'd expect from a white boarding session wouldn't work.

e.g. in UTF-8 a codepoint is encoded in varying byte lengths (so you have to split into codepoints and then reverse), and, a lot more difficult, a sequence of multiple codepoints can be combined to form a symbol. Simplest case would be something like "ö" encoded as "o" (U+006F) followed by a combining diaeresis (U+0308).

Other fun special cases: 🇺🇸 is U+1F1FA REGIONAL INDICATOR SYMBOL LETTER U, followed by U+1F1F8 REGIONAL INDICATOR SYMBOL LETTER S and should if possible be displayed as a US flag (otherwise falls back to text "US"), should reversing it create 🇸🇺 (replacing the flag with the characters "SU"), or still show the flag? (I'm not even sure if there isn't a case where both are valid country codes and it would change to a different flag?)

Similarly, Emoji can be formed from a sequence with combining characters inbetween, which don't display correctly if reversed codepoint by codepoint.

Even in ASCII you have multibyte sequences to worry about: what's the reverse of CRLF?

This is why I like the question. As an interviewer, I will leave that matter open and see if the candidate asks for clarification. If so, bonus! But I will tell them to just solve for ASCII.

The worst-case scenario is a "self-hazing" where someone sees the encoding difficulties and freezes up instead of asking for clarification. I've never seen that happen though, in my experience though, everyone -- even the good ones -- just assume ASCII.

And I am happy enough if they do it correctly.

Well, OK, if you are using C or something, and traversing through binary it is hard.

But if you are in python, and given a string object, and told to reverse it without using the reverse method.... Yeah, that's easy. You should be able to do that.

People are usually expecting the latter.

What is the field you hire coders for? Because for the mine (iOS) your ability to code fizzbuzz have little relevance. The knowledge of APIs, common patterns, ObjC vs. Swift, common means to handle dependencies, etc. etc. is impossible(?) to fake if you do not have relevant experience you claim you do.

As an iOS developer, I would still get whiteboard questions ranging from "reverse this string" to "find all the anagrams in this array and print them in this specific fashion", usually with iOS specific trivia about view controller lifecycle, UIKit (whats the diff between frame and bound?), etc. sometime before or after the whiteboarding

Sure but if you cant program fizz buzz, that means you don't know what an if statement is.

Fizz buzz tests for "does this person know what a function is, what an if statement is, and the modulo operator". And frankly, I'd give the modulo answer away for free if the candidate asked.

All programmers should know what a function and an if statement is.

Interesting! I actually love using the whiteboard to sketch solutions and architectural decisions. I believe the hate comes from having to code on a whiteboard - which is justified, since no one ever coded on a whiteboard except in an interview.