Find the largest palindrome substring of a string

Shortest path solver (Djikstra's)

Compute a power if the base is any double and the exponent is an integer

Take an unsorted list and put all the odd numbers on one side, all the evens on the other

Given an array/list of numbers that first increases then decreases and a number, determine if that number is in the array/list.

Out of those five, only one requires you to have something somewhat memorized (path-finding), but even that is pretty basic, and I think they would have accepted non-optimal solutions that worked anyway, so really all you needed to know how to do was write a BFS that maintains the cost of the shortest-yet found path to each expanded vertex. The rest I think anybody - given enough time - could solve if they were a good programmer. Of course sometimes there are problems where you don't figure it out in time, and definitely (a minority of) problems that are too hard for a whiteboard interview, but you're not going to get every technical question right anyway.

It increases the stochasticity of interviewing when you can fail the technical challenges of interviews for jobs you, on another interviewing day/with another set of question, would otherwise qualify for, but this is logical from a hiring perspective. It costs less to interview 20 people and accept one qualified candidate than to interview 5 people and accept an unqualified candidate. It's not that you need to know how to solve these problems to be a good programmer, or even that being able to solve these problems is indicative of a good programmer, it's that a bullshitter/unqualified candidate will fail these every time, while at least a few qualified candidates won't fail.

Implementing a binary search algorithm is anything but trivial, you've got overflows, off-by-one errors, passing arguments by value, etc. Sure, the idea of finding the point in the array that starts decreasing with a binary search is simple, but the subtle ways you can write it wrong are practically infinite.

However, it really stings to get the algorithm right and know what the implementation concerns (overflow/OBOB) are, but simply not have enough time to get them written in a correct/compilable manner. I've failed a few online interviews where I knew the solution to a problem but simply didn't have the time to write it. For example, I got a question that required building a heap, but at some points you needed to remove items from the middle of the heap. This would require being able to call sift-down/sift-up on the underlying data structure. I didn't know how/if I could call sift-down/sift-up on the priority queue implementation of the language they made me use. So I essentially ran out of time because I couldn't look up an algorithm I knew how/why to use.

I have to disagree about the palindrome question only because I got it in the last ~15 minutes of a 30 minute first round interview. With 10 minutes passed and 5 remaining, I still only had the naive solution on the board with less than five minutes to go. After a few more minutes of thinking I eventually realized that I had only been thinking of palindromes from outside-in. With about 1-2 minutes left I hurriedly explained to my interviewer that you should check each character and find the largest palindrome that character is the center (or half of a paired center) of, by expanding outwardly. He asked a few questions, then assured me that it was ok to not write it on the board and that he could tell I understood it. It really gave me a good impression of the company that their hiring practices were so rational, and I now work there.

I really think anybody would have figured out the problem if they looked at it long enough, it's just that sometimes things like this take 4 minutes and sometimes they take 4 hours. It depends on the person but not strictly an "intelligence" way, I just think there's a lot of variance in how long it takes people, even pretty smart people, to solve sufficiently hard problems.

I agree with most of your points, the thing is, that palindrome question worked out because

1) You had a "realization", which still feels a little "there's a trick to it" to me, which can be a sign of a bad whiteboard Q, I think. Obviously, this is fungible.

2) More importantly, your interviewer didn't suck. They understood the process is what matters, and not the code on the whiteboard.

That #2 is the reason I think whiteboard coding is bad. Most interviewers simply aren't trained well enough to evaluate based on process rather than results. That's why I advocate for only doing very simple ones, or not at all, simply because it's less dependent on how good the interviewer is.

Cynically, I wonder if it's sometimes because it's a crutch for the interviewers. Like anything else, interviewing is a skill that you learn through interest, study and practice. I've been carrying out technical interviews for years, and still wouldn't say that I get it right every time. If the interviewers have not made an effort to learn how to do interviews, or don't really want to do them, or don't actually know what the job will involve, then they can just fall back on asking algorithm questions.

Apparently, the correct answer was Romanesco broccoli.

I failed the interview and briefly sank into a depression questioning everything I knew about raising young children, self-similarity and recursion.

I hope you got another job that you enjoy.

Or something like in the article where you start with a little code, and build on it to solve some problem that isn't a totally arbitrary tree traversal like most of the whiteboarding stuff seems to be.

For the coding part, I try to pick things that don't depend on someone hearing about it previously. I try to solve the problem myself in 1/3 the time I allot to the candidate since they are under pressure. Most candidates seem to struggle with simple problem though.

A simple one I have asked in C is to reverse the order of numbers in an array in place.

Hm...

    int a[] = {1,2,3,4,5};

    for (x = 0, y = 4; x < 5; x++, y--) {
      a[x] ^= a[y]; a[y] ^= a[x]; a[x] ^= a[y];
    }

But then the last question I got was 'find all word substrings in a string'. I struggled, giving a brute force answer (for each position in the string, check against dictionary and expand by one character until the end of the string), but struggled to improve on it. I didn't know about tries at the time, but even still it would be difficult for me to even try to code this on a whiteboard. Turns out it was "Google" question that was for optimizing runtime, and I cannot analyze like that on a whiteboard, unless it's obvious (nested for loops, etc.).

Anyway, after struggling and giving up with that question the next guy came in and berated me and my current employer (defense contractor). Not sure if it was because they thought I wasted their time or what. I left after that--not someone I would want to work for.

Also if you changed this to a int *a (and a count), some people will get confused how to do this all with pointers. Asking how this would be tested is also a good question.

That assumes an odd number of elements (true in this case but not in general); I would recommend terminating when x >= y.

> The XOR-swap trick is an example of coders being too clever for their own good. Here, it gradually poisons the RC4 permutation with zeroes, until eventually the plaintext is just passed along in the clear.

But apparently some people can just write it all out on a whiteboard in one go.

There are good balances. The question I ask is a real problem for a real product but quickly reduces to something small and manageable rather than getting bogged down in incredibly specific requirements.