9 ms·
Not necessarily. The purpose is to show how you reason your way through a problem where you can't simply google "how do I solve x problem." It's intended to see
by latencyloser 7y ago
Not necessarily. The purpose is to show how you reason your way through a problem where you can't simply google "how do I solve x problem." It's intended to see how you communicate, how you handle mistakes, how thorough you are in double-checking yourself, your work style (do you jump right in or ask lots of questions first), etc.
In any case, there's a lot of strategies to show that you understand a concept without relying on exact memorization. For example, a common answer I give if I can't remember something might be something like: "The language has a sort function that can accept a list, I don't remember the exact API or the underlying implementation but let's assume it's n log(n) as that's a common runtime complexity for sorting--I'm going to define that as 'sort(listArg)'." I don't remember the exact function, so I'll just define and explain how it might work myself. If you're expected to be able to compile the code you're writing, simply ask the interviewer and explain the API you're looking for, I've had great success with that as well and prefer when an interviewee asks me over staring at the screen or board.
If it's a problem where you're expected to produce some algorithm, if you can't come up with any solution, explain to your interviewer what you're stuck on. They may provide a hint that will get you rolling. I had this happen during an interview at Microsoft (spoiler, I got the job) where I forgot how to determine the length of the hypotenuse of a triangle haha. The interviewer wrote the formula on the board and we moved on. Interviewer later told me I seemed nervous and he chalked it up to a brain fart--good call, I was really nervous! The point of that problem wasn't to see if I knew the Pythagorean theorem--it was just a small piece of the puzzle I was stumped on. Similarly start from a simple, naive solution, and interatively optimize rather than trying to recall a perfectly optimal solution. If time is running low, explain your intended optimization or ones you think might be meaningful, making note of any uncertainties in that explanation.
I've worked at Microsoft, Amazon, some other notables and interviewed at many others. I am speaking from that experience. Others may have better ideas. Of course, not all places approach this in a reasonable fashion and some are just missing the point entirely with their interview and they do expect you to somehow memorize everything.
- blackflame7000 7y agoI totally understand your philosophy and you make some great suggestions, but overall there's one big flaw with whiteboard interviews: Artificial Pressure and its impact on people's ability to think clearly on the spot. I am a very methodical thinker which is why I tend to prefer work in large scale ore high-performance systems where you consider the implications of thread contention and so forth. I've designed and built multiple large scale production systems and i've also simultaneously forgotten whether it should be += or =+ during a whiteboard interview because of a phenomenon I can't quite describe. Obviously I was laughed at for someone who's actually had 10 years experience with c++ to forget something so basic but it happens when you are on the spot. The biggest problem with whiteboards is that they reward exactly what they say they try to weed out, rote memorization. It's no secret you could spend weeks practicing on leetcode for an interview but those skills simply don't translate to real-world programming. Algorithm design is maybe 2% of software engineering. The vast majority is knowing what pieces of technology are out there in order to avoid reinventing the wheel all the time. Whiteboards don't test that skill. It tests a marathon runner on their 100 meter dash time.
- abalone 7y ago> Obviously I was laughed at for someone who's actually had 10 years experience with c++ to forget something so basic but it happens when you are on the spot. This 100% happened to me (apart from being laughed at) only it was even more of a meltdown. Also 10 years experience and a problem I could do in my sleep. It was my first interview after a long time and it triggered performance anxiety and nervousness. The solution is you need to practice live interviews, not just leetcode solo.
- levythe 7y agoIf the system is so poorly evaluating people that they have to train an irrelevant set of skills to succeed in it, what does that say about the system?
- blackflame7000 7y agoI am a big fan of the take-home problem. For example, Symantec once asked applicants to design a simple virus detector with wildcards (similar to grep) and then they gave interview spots to people with the best performance. During the actual interview, however, there wasn't much whiteboard coding only designing or "how would you do X" sort of questions.
- levythe 7y agoThere's a small list of companies I'd do a, "Take home test," for. In my experience, most companies that ask for it are looking for free labor.
- crummy 7y agoI've never done a take home test that produced anything that could have been vaguely useful for the interviewing company. Usually the problems are pretty artificial.
- 7y ago