Live data from Hacker News

Don't write on the whiteboard

jperla.com

71–80 of 118 posts

Re: Don't write on the whiteboard

#71

Earlier quoted context omitted.

>> Once you go through few interviews you get less anxious about the next one. That's not really practice, it's actual experience. It's also not guaranteed to improve your skills, it might make it worse if you have a bad experience. When that happens it's easy to make generalisations about the next ones. That's actually somewhat descriptive of where anxiety really comes from, antecipating the unknown.

That's not really practice, it's actual experience. All practice is merely experience. The only way to practice any skill is to use that skill and get better at it.

But there's a great deal of difference between shooting targets and real combat, punchbags and live oponents, ball throwing machine and live adversary just as much as doing whiteboard problems by yourself and during an interview.

It's not the same experience.

Re: Don't write on the whiteboard

#72
post #39
post #5

From an interviewer's perspective, the whiteboard gives me a chance to intervene to correct, explain, or provide hints, to the interviewee sooner/at the right time, which is not possible in pen-paper solutions, as I cannot see what the interviewee is doing till she shows me her work, unless I sit at the same side of the table as herself, which is odd for general discussion/talking. My advice to interviewees:- Practic…

Perhaps I'm just neurotic, but I do find it uncomfortable to write code with someone scrutinizing my work. When figuring out how to implement an efficient algorithm, I find that it's often helpful to perform exploratory steps before actually writing the algorithm. For instance, when I attempt a projecteuler puzzle that I don't immediately know the solution to, I'll usually try to compute the desired result for a few…

I love it when someone starts attacking my whiteboard problem by writing down something other than code, such as sample input/output pairs to test their algorithm against.

Re: Don't write on the whiteboard

#73
post #34

Seems to be a divide between those who like using whiteboards and not. I can think of several contributing factors: * academics vs non-academics * those who enjoy thinking on their feet vs those who enjoy thinking in a text editor * good handwriting vs not * right vs left handed Regarding the last, writing left-handed on a whiteboard means you're either manipulating the pen uncomfortably from the far end, or you're s…

It's funny, I think every interviewee who has apologized for their bad handwriting has been at least 50th percentile in handwriting legibility.

Re: Don't write on the whiteboard

#74
post #66
post #57

Did anyone get the O(document size) solution? I can't see how it would work without checking each word against the list.

At first glance I don't think you can achieve O(document size) without some form of preprocessing. Each word in the vocabulary has to be looked at, so a natural lower boundary seems to be O(document size + vocabulary size). Also it is unclear what will count as an atomic operation. Although the description reads as if word comparisons were counted, this makes for another simplification, as words could be of arbitrary…

Yes, you use pre-processing.

I framed the problem in a very real-world scenario. Use that. It's not a trick question. How would you solve my real-world problem efficiently?

Re: Don't write on the whiteboard

#75
post #57

Did anyone get the O(document size) solution? I can't see how it would work without checking each word against the list.

Setup a hashtable of keyword -> wikipedia link. Check every word in the document against it. One check per word should be O(word count) ish, shouldn't it? Hashing every word will have a cost, but will be roughly the same for each word so I'll brush it aside as a constant, setting up the hash will have a cost, but shared over the number of documents to check. Checking every word sounds expensive but so does looking ev…

[deleted]

Re: Don't write on the whiteboard

#76
post #57

Did anyone get the O(document size) solution? I can't see how it would work without checking each word against the list.

Setup a hashtable of keyword -> wikipedia link. Check every word in the document against it. One check per word should be O(word count) ish, shouldn't it? Hashing every word will have a cost, but will be roughly the same for each word so I'll brush it aside as a constant, setting up the hash will have a cost, but shared over the number of documents to check. Checking every word sounds expensive but so does looking ev…

That works if each phrase is one word. Many (most?) of the terms in the vocabulary are multi-word phrases. How would your algorithm work for multiple word phrases? What is its running time?

Re: Don't write on the whiteboard

#77

Great article with lots of valuable info in there. The part about the actual whiteboard is almost irrelevant. Most of the comments here are getting too worked up about that. "Learn Python and use it during your interview." Python is expressive, a high level and kind of writes like pseudo code. Just write pseudo code. The point isn't syntax anyways. "The highest value problems I know of are on Project Euler." I do enj…

Many companies (including the one in question) want to see actual code in a language that they use at the company. The fact that Python happens to look like pseudo-code is a bonus.

Maybe you already knew all the lessons in Project Euler, but for me, I became a much better programmer. How elegant are your solutions? Have you tried writing them in a different style than you're used to? Say, in a functional style? With Haskell?

Re: Don't write on the whiteboard

#78
post #35

Earlier quoted context omitted.

So sit next to the person while they write...

The natural posture, position, and size of writing on paper discourages that. It's also essentially impossible for me to step in and point to/mark up their code (and then erase it). The paper takes away any of the collaboration that can occur during an interview. Your code might be better, but I have trouble seeing that you'd be able to project as a positive impression as if you used the whiteboard.

Parents of children and teachers don't seem to have a problem with paper.

Re: Don't write on the whiteboard

#79
post #39

Earlier quoted context omitted.

Perhaps I'm just neurotic, but I do find it uncomfortable to write code with someone scrutinizing my work. When figuring out how to implement an efficient algorithm, I find that it's often helpful to perform exploratory steps before actually writing the algorithm. For instance, when I attempt a projecteuler puzzle that I don't immediately know the solution to, I'll usually try to compute the desired result for a few…

As an interviewer, I'd much rather see your intermediate steps - the messy parts, etc. I feel like I can get a better idea about how you work and think. Interview questions (for me) aren't about "can you solve this" they're more about trying to see how you work. I ask questions about decisions you made, and I like it if you can talk about what you're thinking. Interview problems are contrived. I don't care if you stu…

That sounds more like a visit with Froyd than a programmer interview.

Re: Don't write on the whiteboard

#80
The interviewers don't care. Use paper.

Uh, yeah, we do care. Part of what we're judging is your ability to present and explain your work. How you do your work is your business, but how you share it affects the people you work with. If you think it's all about you, then you're off on the wrong foot already.

Post reply on HN