7 ms·

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

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 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.

jiveturkey 8y ago
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.
- scott_s 8y ago
  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").
- nybblesio 8y ago
  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.
deleted 8y ago
[deleted]
vultour 8y ago
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.
- redisman 8y ago
  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.
ggggtez 8y ago
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.
- tluyben2 8y ago
  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.
  - ggggtez 8y ago
    In theory there should be no difference between theory and practice, but in practice there is.
    - tluyben2 8y ago
      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.
    - drharby 8y ago
      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
kmike84 8y ago
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.
- QuackingJimbo 8y ago
  ``vector<vector<int>> grid{{1,1,0},{1,2,0},{0,2,2}};`` in C++
- drharby 8y ago
  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
ggggtez 8y ago
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.

jiveturkey 8y ago

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.

scott_s 8y ago
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").
nybblesio 8y ago
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.

deleted 8y ago

[deleted]

vultour 8y ago

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.

redisman 8y ago
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.

ggggtez 8y ago

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.

tluyben2 8y ago
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.
- ggggtez 8y ago
  In theory there should be no difference between theory and practice, but in practice there is.
  - tluyben2 8y ago
    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.
  - drharby 8y ago
    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

kmike84 8y ago

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.

QuackingJimbo 8y ago
``vector<vector<int>> grid{{1,1,0},{1,2,0},{0,2,2}};`` in C++
drharby 8y ago
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

ggggtez 8y ago

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.