Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Don't write on the whiteboard

jperla.com

Post reply on HN
Print view View original

61–70 of 118 posts

Re: Don't write on the whiteboard

#61

Post by bdg »

> Then take your solution and do it in half the lines. Now, read more of the Python docs (maybe read about generators and list comprehensions and decorators) and make it even shorter.

I don't agree with this. Shorter lines of code don't really express anything beyond how cuthulu-inspired your code will read, and performance is very likely to take a hit. Euler problem 2 solutions that are simply a for-loop rather than take advantage of geometric progression are slow and don't indicate higher-level abstraction of problems or the tools to solve them. Almost any programmer should be able to do the first 50 programs with random brute-force methods that are only a few lines long, but that doesn't do anything other than demonstrate you can have a computer add together numbers based on an if-statement.

It especially doesn't show you know how to bring together technologies that are useful for doing things such as building a website.

Re: Don't write on the whiteboard

#62

Post by InclinedPlane »

calibraxis wrote: post #48
edw519 wrote: post #9

Sorry OP, I realize that you're just trying to be helpful sharing what's worked for you and I appreciate that, but frankly, I hate posts like this... I think the best preparation for any interview is to simply get good at what you do. All the rest is window dressing that distracts from that goal. Every minute spent practicing interviewing would be better spent building stuff. The natural byproduct of this will be exe…

This is the first article I've seen which mentions something that should be fairly obvious to interviewers — expecting people to code on whiteboards is a common mistake. As an interviewer, I totally cringe when I imagine filtering out good people this way. (I say that as someone who enjoys interview puzzles, and have always succeeded at them. But that pleasure's probably pathological. For many people, it's a nerve-wr…

I'm ok with coding on a whiteboard in an interview but I prefer it to be at a casual-ish level. I want to get high level data out of the process, not running code. I want to see how someone thinks through the process of transitioning from problem solving to coding. I want to see how they firm up requirements for the solution. I want to see people's code habits, I want to see their abilities to analyze and critique their own code. I tend to use pretty easy problems for such things (like factorial) so I can focus on those other bits. I find it works pretty well.

Re: Don't write on the whiteboard

#65

Post by SatvikBeri »

lmkg wrote: post #47
edw519 wrote: post #9

Sorry OP, I realize that you're just trying to be helpful sharing what's worked for you and I appreciate that, but frankly, I hate posts like this... I think the best preparation for any interview is to simply get good at what you do. All the rest is window dressing that distracts from that goal. Every minute spent practicing interviewing would be better spent building stuff. The natural byproduct of this will be exe…

What you're saying is how interviews should work: a pure talent evaluation, unaffected by any non-job-related skills. However, in practice, interviews don't necessarily work that way. Spending a couple of minutes training on presentation skills can make you much more effective at communicating just how awesome your actual abilities are, far more than the equivalent time expenditure in getting marginally more awesome.…

How often do you hear of a programmer saving a company millions of dollars/thousands of man-hours and receiving no reward for it? All the time!

Excellent performance (saving the company ~$3MM) at my last job merited me a 15% raise. Learning and applying negotiation skills made that an 80% raise. Presentation matters.

Re: Don't write on the whiteboard

#66

Post by larelli »

Herring wrote: 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 size.

Also: I only checked the HN comment section to see if someone got the solution and I am amazed that others stuck to that part as well.

Re: Don't write on the whiteboard

#67

Post by Daniel_Newby »

joeyh wrote: 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…

> writing left-handed on a whiteboard means you're either manipulating the pen uncomfortably from the far end, or you're smearing what you wrote

I'm left handed, and I hold the dry-erase marker comfortably and write without my hand touching the board. Certainly it takes a degree of coordination, but is this uncommon?

Re: Don't write on the whiteboard

#68

Post by 286c8cb04bda »

SatvikBeri wrote: post #65
lmkg wrote: post #47

Earlier quoted context omitted.

What you're saying is how interviews should work: a pure talent evaluation, unaffected by any non-job-related skills. However, in practice, interviews don't necessarily work that way. Spending a couple of minutes training on presentation skills can make you much more effective at communicating just how awesome your actual abilities are, far more than the equivalent time expenditure in getting marginally more awesome.…

How often do you hear of a programmer saving a company millions of dollars/thousands of man-hours and receiving no reward for it? All the time! Excellent performance (saving the company ~$3MM) at my last job merited me a 15% raise. Learning and applying negotiation skills made that an 80% raise. Presentation matters.

The first time I read your comment I thought it was disagreeing with the parent post. Upon thinking about it, I now believe that you are agreeing with him. Right?

I'm not trying to criticize your post, but I hope someone could point out why I read it so wrongly -- if there are attributes why make it more likely to be read that way, or if there's something flawed in my perception.

Re: Don't write on the whiteboard

#69

Post by 286c8cb04bda »

gldalmaso wrote: post #31
vl wrote: post #28

Earlier quoted context omitted.

>There is no practice that simulates anxiety. Ah, but there is. Once you go through few interviews you get less anxious about the next one. Which means, that if this is a serious problem for you, and you expect some important interview in the future, then you have to go and interview with some other companies before to gain practice, and may be even get some job offer you'll like more than the one you are hoping for.…

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

Re: Don't write on the whiteboard

#70

Post by jodrellblank »

Herring wrote: 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 every word up in any data structure or searching every dictionary word in the document keywords and links have to be stored somehow.

My biggest hesitation is it can't be that easy or all you and the interviewer would be saying it, so I must be glossing over some big cost somewhere, right?

Post reply on HN