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 exercising those skills that will be evaluated.
What you're proposing is unnatural and unnecessary. You're focusing on the details of the process instead of the real issue of knowing your stuff.
Good interviewers won't care if you're fundamentally solid but a little light on the presentation side. And they won't be fooled by a great presenter who is weak under the hood. Sure, you may fool a weak interviewer, but what does that say about the company you may be joining?
We all want to be solid in both fundamentals and presentation, but I prefer to focus my limited resources on getting better than I am, not appearing to be better. Best to just be good, be yourself, and trust that it will show naturally, no matter how you are evaluated.
You can pretend that the world is perfect, or you can take steps to deal with the fact that it is not. Now tell me, which of those behaviors would you want from the programmer you want to hire? ;)
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.
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.
I think the confusion comes from the "How often do you..." which is frequently used sarcastically-although in my case I meant it literally.
Good interview skills only benefit you in one area -- how good you are at interviewing. Once somebody hires me, how good I am at interviewing serves no purpose to my employer. And smart companies recognize this, and adjust their interviewing process to get to what's important.
I specifically say the opposite, don't practice whiteboard interviewing.
Edit: who would down vote this?
Edit edit: thanks for the explanation jader
And I'm not saying you shouldn't prepare for interviews. I'm just saying that companies that evaluate a candidate based on how they "perform" in an interview vs. trying to really get to the root of how they would perform in a job are doing themselves a disservice, and may be losing some good candidates because of it.
And if this is happening, that company should change their interviewing strategy to focus more on what's important, and get rid of anything that may get in the way of evaluating that.
Take your point on writing code on a whiteboard vs. writing on a notepad, just for example. To your point, it may be unnatural to code on a whiteboard. But, to me, it's also unnatural to code on a notepad. Actually, I hate handwriting altogether. I prefer typing a thousand times over. So in order for a company to really see how I code, they would hand me a laptop, or even better, allow me to use my own.
Of course, there are arguments to whether that would even be a truly accurate evaluation. My point is -- and again, this isn't necessarily in direct response to your post -- that good employers know how to get to the root of someones abilities, without letting these interview-specific strategies get in the way.
Edit: Disclaimer, I did not vote you down. :)
It's just like marketing. You can have the best product in the world (in this case, yourself). But, if you can't market it well, other products will be used instead (IE: you won't get hired).
Learning how to market myself is the single best thing I've learned how to do and it's definitely helped me get jobs.
The Project Euler stuff I could go either way on, but I thought this was such a great post.
My takeaway was along the lines of removing the junky presentation layer (whiteboard, etc.), and making sure that you SHOW your fundamentals. Working on Project Euler helps build those fundamentals, writing code comfortably during your interview helps show your fundamentals. In terms of presentation, I didn't feel like he was doing 'window dressing', you definitely want to show your interests, projects and your opinions, these are part of the fundamentals.
No matter what, there is always a base line of presentation that you must meet in an interview to show your fundamentals. I feel like this post is encouraging you to meet that base line, as well as increase your fundamentals.
I give specific advice for what you can actionably do.
(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-wracking ritual which pointlessly damages self-esteem. As a gatekeeper, my job is to help them succeed at my silly little games. Assist them in reaching their limits.)
A lot of the mind is in one's hands, as many emacs users might tell you. That intelligence can disappear in the alien environment of the whiteboard, for those unused to it. Many bright people maybe can't even afford a decent whiteboard, and haven't worked in an environment which uses them.
There's a huge amount of good tips for good people to get past the gatekeepers — and negotiate good terms. If you can not just beat the interview, but kill it, you'll often have a more powerful bargaining position.
The bottom of the page also has links to problem sets from a bunch of other contests.
Both of these sites run a few algorithm competitions every month.
TopCoder, CodeChef, SPOJ may be what you're looking for.
(Having said that, PE is great fun if you're interested in maths per se).
One good thing about it is that there are different levels of success.
The problems usually come with a simplified version to which the result is provided. That way you can confirm your solutions works. Then, the real problem scales it and you have to improve the algorithm to achieve the performance goal of less then 1min cpu time.
It's also o good way to learn a different language. You can compare your solutions in different languages and evaluate their strengths and weaknesses.
> I think the best preparation for any interview is to
> simply get good at what you do
Simplicity is the ultimate sophistication.-- Leonardo Da Vinci
Many technical startups struggle with promotion, naively believing that simply being better is enough. It's not. You need to be able to clearly explain and demonstrate your value. If you can't do this you're leaving money on the table.
If somebody told you that 20% of your lifetime earnings will be based on your effectiveness during interviews and non-technical conversations with your boss, would you ignore that? Because that's true.
My advice to interviewees:- Practice on a whiteboard. It is not that difficult.
As you have put it, the white board is convenient for the interviewer, but that is missing the point of the interview which is to assess the candidate.
If you do not find if that difficult, than consider yourself privileged because most people feel differently. Some people cannot speak to a small audience while some love to give presentations.
An interview is already an anxiety-packed situaton where the candidate is under the spotlight. Putting them on the whiteboard solving problems only puts more pressure on and will often lead to sub-performance. Since the interviewer does not follow through when the candidate leaves, they may think that the candidate did his best.
I for one think that there should be an effort to emulate real working conditions and not performatic settings.
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.
The whole point of the parent argument is that there are conscious steps you can take to make whiteboard writing not stressful for you. Just practice for ten hours solving problems on it and it will be as natural as writing on paper.
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.
All practice is merely experience. The only way to practice any skill is to use that skill and get better at it.
It's not the same experience.
I know that those are all things that I can still do during a whiteboard interview, but having the interviewer look at my intermediate work, assume that I'm making mistakes and try to correct me tends to disrupt the process. I'm confident that the algorithms that I'll ultimately produce will be good, and I'm confident that I'll produce them at a good speed, but it will still look worse to the interviewer if I write down a bunch of noise before outputting a polished algorithm.
On the other hand, on paper, I can quickly churn through some of those early steps and then show the interviewer a solid, finished product without them having to see the crude intermediate steps. Again, it's possible that my anxiety about this isn't really justified, but I can't help but get the feeling that working in this way will leave the interviewer with a worse impression of my abilities than if I have the option to "hide" the rough work and just show them the output.
Interview problems are contrived. I don't care if you stumble a little bit. Heck, I'm always happy when I see someone start off the wrong way, notice that something's wrong, take a step back and go a better path.
If you go off with a paper and pen and just give me an answer, I miss out on a lot of that. And even though the anxiety might not show how you normally interact (and I totally understand that) - I can't possibly get any sense as to how you work in a collaborative environment.
I've never had anyone ask to do problems on paper instead of a whiteboard, and I wouldn't refuse it to them - but I just get a feeling that I'd be less likely to be inclined to hiring them - not because of the paper, but because there's no way to see the things that I most like to see.
If you really do suck at using a whiteboard, here's a really far-out incredibly expensive and time consuming idea: Go to Office World and buy a small one for $10.
Many of his other points are good, although a lot of it boils down to being a top notch developer and letting it show in the interview. Being a top notch developer is the hard part, and good interviewers (at places a top notch dev would want to work at) will typically identify your skills even if you don't follow this specific advice.
+1 for using python--it's great for getting through coding questions quickly and efficiently, allowing exploration of various twists the interviewer may throw at you.
I agree. I think high-level planning and design is a great use of whiteboards in the workplace. Code under time pressure, not as much.
(1) Make yourself as comfortable as you can, so that you can:
(2) Make it clear what you're thinking and how you think (which is the point of the interview).
I'm not signing on for the concept of always doing your interview in Python, however. Do your interview in the language you're most comfortable in, unless it's something so esoteric that it's likely to throw the interviewer off balance. Python is a great language for these sorts of exercises if you know it, but don't force the issue if you don't, because then you're violating (1) above. I know Python well myself, but I'd do an interview in Java because that's "home" to me, and you need all the "home" you can get during an experience as alienating as your standard interview.
* 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 smearing what you wrote. You're also tending to obscure the audience's view of what you just wrote with your hand, arm, and body.
I'm sure all of the above are part of why I prefer to avoid whiteboards, and would be much happier with my laptop on a projector. Although if I'm communicating with trusted peers I have no shame in putting up a smeared, slanted, and mostly illegible scrawl.
When I teach, whiteboards are fantastic.
If you haven't tried it, writing backwards with your left hand is surprisingly easy when you first try it. (easier than writing forwards eith the left hand, or backwards with the right hand, as a rightie) It's just a more natural way to move your hand.
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?
I found your last line quite amusing: "I want to learn how to push the boundaries of knowledge, not just apply what I learned in these books."
When I quit my PhD to do a startup, my thinking was the exact opposite: "I want to apply what I know to solve real problems out there, not just keep learning and write more books which no one will read."!
As others pointed out, there's more to this article than the whiteboard title, and some great points (particularly a fan of the python one) are made. I can't agree with the whiteboard concept, unfortunately. Maybe it's because of my teaching background, but when I interviewed for a startup engineering position a long time ago, they loved my whiteboard usage. It was clear, easy to follow, and effective. In some respects, it's (part of) what got me the job offer.
That said, the main point between whiteboard or pen and paper: make sure you can express yourself clearly to your interviewers. It was crucial in all the essays I graded, and a key skill to attain no matter your profession.
In addition, communicating with peers via whiteboard is a skill that is actually handy in day-to-day work life; it's not just some artificial interview skill.
I've never interviewed a candidate that asked me to use paper, so I can't be sure - it's just my instinct.
It might be completely biased though - I far prefer to use whiteboards - I love the space, I love how easy it is to erase without a trace. I can throw thoughts up there and the manipulate them.
Design and flows get thrown on whiteboards a lot, but those are not code, and their creation is not remotely like coding. You are "testing" exactly the wrong thing.
"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 enjoy running through Project Euler problems but I have no evidence that's making me better at my day job, only better at answering Project Euler problems.
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?
Oh no, I certainly didn't know all the lessons and I haven't done all of them.
"How elegant are your solutions? Have you tried writing them in a different style than you're used to?"
That's a great point, so I suppose it's less about the actual Project Euler problem, and more about optimizing, refactoring and trying them in different languages.
Exactly. Make it better.
Whiteboarding is a very, very valuable skill. The ability to effectively convey your ideas to a group of people, while presenting what amounts to an extemporaneous speech, is a tremendous asset.
That is also essential for the applied position?
The DFA turns out to be basically the same thing as the trie. Indeed, the standard DFA construction factors out common prefixes of the search terms, just like a trie. But this formulation has the advantage that anyone can implement it in a few minutes with their language's regex library. In Python you might do something like this:
pattern = r"(?:^|\s)(%s)(?:$|\s|,|\.|!|\?)"
dfa = re.compile(pattern % ('|'.join(map(re.escape, terms)),))
return lambda string: dfa.findall(string)
As a side note, the problem didn't specify whether matches could overlap. Actualy, it isn't even solvable in O(n) time (plus precomputation) if overlapping matches are allowed. Let's say the search terms are "a", "aa", "aaa", etc, and the search string consists of n copies of "a". Then every substring of the string is a match and so there are O(n^2) matches, which obviously cannot be listed in O(n) time.
You'll want to do better than just "use a trie" - like http://en.wikipedia.org/wiki/Aho%E2%80%93Corasick_string_mat...
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?
Create hashtable where the key is the first word and the value is (rest of sentence, link). In the case of collisions, a list of rest of sentences and links.
Checking the document would still go word by word, if no lookup fine, if one result compare the rest of phrase with the following document words, if a list, do that repeatedly.
Runtime varies a lot with distribution of input phrases - if there are 50,000 beginning "phospholipid" that's not good.
I don't know how to estimate the runtime well, best case is no matches or single word phrases, and then as above. Worst case is every document word matches a long list of phrase endings but none of them complete, but even then the searching is only searching a fraction of the phrases in len(longest-phrase) chars of the document.
O(doc_words * num_of_phrases_by_prefix * avg_phrase_length)
I'm uncomfortable here, wishing I had more algorithm/data knowledge to draw on, and maybe wouldn't have gone down this route had I paid attention to many words from the start. Every problem doesn't need a hashtable. Maybe phrase-trees...
For phrase in keyphrases:
If phrase in document:
For word in document:
Some_phrases = get_keyphrases_starting[word]
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.
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?
The end result is O(n) in the number of characters in the document.
 In later tips, he gets into some things that make Python good, but it needs to be justified more, given that his advice boils down to "use Python even if you've never seen it before".
"Normally people write it in Java and it takes them a while and it takes up a lot more space on the whiteboard. They spend a lot of time manipulating the input string."
If you're more comfortable with Ruby, it would also be a great alternative. Clean, readable code. You get to focus on solving the problem.
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.
Besides, most interviews I've had end up being a phone interview for knowledge and skillset, followed by the lunch interview where they're more concerned with finding out how you'll fit in with the existing team.
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.
Since you will presumably be writing code on a computer when working at the company, why not write code on a computer when interviewing with one?
That said, don't be needy. Just acknowledge your anxiety.
It's never been a big deal.
I /have/ seen candidates fail because they insisted on using a laptop. But these folks were typically very nervous about coding, and had essentially pre-failed the interview in their head. Their laptop was a security blanket, a totem that they hoped would sustain them, and it didn't work.
This strikes me as the fundamentals for what someone should look for in an interview for a startup or research position.
Am I the only one who is not such a fountain of ideas that I can keep it all in my head?
During my last interview I brought along a notebook, the day before the interview and the bus ride over to the office I wrote down any question that I could think of in the notebook, even forcing myself to think of extra questions.
It got people's attention, I talked with 6 pairs of people and each one pointed it out in one way or another.
A legal pad looks "prepared". A smartphone looks "distracted".
At every company I have worked at, from two-person startups all the way to Google, we have used whiteboards extensively. Most meetings and architecture reviews are conducted in front of a whiteboard. The first thing I do when I found a startup is to buy a whiteboard and nail it to the wall. Whiteboards are a necessity for collaborative brainstorming and working together.
I'm not sure I agree with anything the OP says in this article. I think he's trying to sound smart and rationalize the reasons he didn't get hired. I say this not as a troll, but to provide constructive feedback. If you want to get hired by a big company, you have to play by their rules. End of story. There are a few exceptions (like engineers at Google without college degrees), but they are exceptions - most people who work for Google or Facebook or Palantir went to good schools, and did well, and wrote on the whiteboard during their interviews.
The notion that an engineer's ability can be discerned by willingness and comfort at a whiteboard is utterly ridiculous.