Comment by nybblesio | Hacker News Reader

Comment by nybblesio | Hacker News Reader

Parent Full thread

A regular viewer of my daily Twitch programming stream (link is in my profile) asked me to solve a problem he was asked to whiteboard. He wasn't asked to draw diagrams or write pseudo-code so they could learn how well he communicated. He was asked to write the code and it was heavily implied that it must compile and run -- even though whiteboards don't do that.

Here's my attempt: https://youtu.be/6LHqrxrC6Uo

I solved the problem, with an IDE and a compiler. I communicate during the entire exercise. It takes me over 2 hours. Granted, I debug it, so that takes extra time. (Can't debug on a whiteboard!) I had to take one break. On top of this, I've solved this kind of problem before and it still took me more than the 45 minutes you're likely to get in a whiteboard interview.

And I try to cover all of the "hot topic" points I know the interviewer is thinking about: size .vs. time tradeoffs, iterative .vs. recursive, etc.

If I had to solve this problem on a whiteboard, in 45-60 minutes, with the bar being "it must run"....I would fail.

I guess that makes me a poor programmer. Instead, I'm a grumpy old man who is really tired of all this fraternity hazing bullshit.

I feel like you're vastly overcomplicating the whole thing. Granted, I don't know if there were any parameters specified other than "Find the largest connected segment in a 2D grid".

I had to solve almost the exact same problem very recently. I find the best way to start is to just implement the easiest solution you can think of, such as the array approach you mentioned in the beginning. I did that in 5 - 10 minutes. We spent the rest of the interview optimizing and fleshing out the problem (e.g. let's not use an array, but there is only one "color").

Overthinking the problem straight from the beginning and potentially being unable to provide a working solution at all is probably the worst thing you can do. I actually had that happen in a previous stage of the aforemention interview, and had to "reset" by going back and implementing the simple solution before optimizing it.

Kudos on being able to "reset"! That's probably the hardest part, fighting against the sunk cost of a snowballing probably wrong answer when you have such limited time.

I got an impression that just specifying the input data took almost 1.5 hours, because of C++ and a decision to have it as a graph, not as a matrix. If an interview is in Python, one would write something like ``grid = [[1,0,0], [1,2,0], [0,2,2]]``, and be done with that part.

Probably you got exhausted after doing all these preparations and debugging issues not related directly to the algorithm. I'm not sure the final solution is correct, it is not tested on a graph with multiple connected segments of the same color. It looks more like a convoluted way to count colors globally, discarding standalone colors, if I understood your solution properly.

Thats the fun part 'to me' about mastery of cpp.

Sure you COULD use a graph, but using a different code abstraction to represent the idea of a graph is much more pragmattic and maintainable, of course that varies with application.

Im reentering interviewing phase right now, and its funny revisiting these problems with a new lense. The mind is very plastic and its exciting, so far as things to come.

Total nerd out moment :v

``vector<vector<int>> grid{{1,1,0},{1,2,0},{0,2,2}};`` in C++

I think it's trivial to code an optimal solution (and discuss tradeoffs) in 45 minutes on a whiteboard. It's just BFS or DFS.

Of course most people prefer to interview in a language which is less verbose than C++, which saves time.

Perhaps it is trivial, but what's the point? If you can reason what algo to use and reason how to determine which one will be the most efficient of the two without testing them both (or explain the abstraction which allows you to test them both without significant overhead in code), it should be enough.

In theory there should be no difference between theory and practice, but in practice there is.

That doesnt follow to me. In theory, there is a difderence between theory and practice, because theory simplifies reality into a model with given assumotions, and reality...is reality.

Unless of course you have the infinity gauntlet

Obviously, I didn't mean that. Just from a white boarding perspective, that should be enough. Give the applicant a computer and have her implement it.

I skipped around on the video. You'd literally have 1/4 the code if you just coded a graph correctly.

You also keep a "counted" and "visited" variable separately for no reason. There is no reason to visit a node and not count it, and you can't count a node you didn't visit. Whatever optimization you think you are getting surely isn't worth it.

It makes you someone that can't listen. The most important part of communication is listening. When the interviewer asks you to whiteboard a problem, they aren't asking you to "solve it". Obviously, you only have a whiteboard and you only have 15 minutes max. You might throw out some comment about size vs. time (eg) but make the decision and move on, quickly. The interviewer might decide to latch on but if not, you have to cover this in 15 minutes so you limit the depth so as to do that. Stub out all the deep functionality and then dig into each part of it as time permits and as the interviewer leads you in those directions.

As an experienced and good programmer candidate, the most important part of an interview is for you to evaluate the company. So the whiteboard is a great way to see if they understand what can be accomplished in 15 minutes on the whiteboard.

If they don't get it, you can end the interview short. Time saved today as well as the next several years working for a shite company.

I love the whiteboard interview.

At what point did I ever imply I don't listen?

I explicitly described the conditions of the original interview. The interviewer asked the candidate to "solve it" and it had to run. What part of that wasn't clear?

I also find it interesting that you countered with a completely different kind of whiteboard scenario. I agree that the scenario you describe is fine. I would enjoy those kinds of interviews all day and twice on Sunday. I'm not railing against an honest discussion with a potential employer. But that's not what happens most of the time, in my experience.

Also, the tone of your reply is that you reject the employer if they don't meet your definition of reasonable. That's great, but not everyone has that luxury.

The scenario nybblesio describes ("asked to write the code" with expectation it would be able to run) is not the one you described ("they aren't asking you to "solve it").

Reply on news.ycombinator.com