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 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.
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.
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? ;)
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.
Sorry Ed, but the best preparation for any interview is not simply getting good at what you do. Being good at what you do is a given. But there is an art to interviewing. I have bombed interviews not because of a lack of ability, but because of my failure to understand interview dynamics.
This may be true, to an extent, but to me, the best interviews do a good job at honing in on how good you are at what you do.
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.
My post wasn't a direct response to your article, but rather thebandrews' point about preparing for interviews.
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.
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.
Wow, couldn't disagree more. "Ask for paper" may be the single most pragmatic and useful interview tip I've ever gotten on this site. I grinned ear-to-ear when I realized that was the point he was making.
The Project Euler stuff I could go either way on, but I thought this was such a great post.
Would you argue that students should not study for standardized tests (e.g., SAT, GRE, ACT) as well, because they should have learned the (restricted set of) material on the test in their classes?
I'm sorry, but where does the OP reference anything about practising interviewing? In fact, his point seems to focus more on fundamentals than anything.
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.
Exactly. A lot of these replies try to summarize my points into one sentence like "show off your skills." That short phrase is insufficiently descriptive to be useful.
I give specific advice for what you can actionably do.
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-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.
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.
I disagree. Experts are known to perform quite badly when they are distracted by stress. In the case of job interview, doing anything out of the ordinary (such as writing on a white board) can cause stress. This diminishes the capacity of your working memory due to increased attention focused on stressors.
I'm glad the author mentioned Project Euler... I've never heard of it. Anyone else have experience with these problems? Is it a good way to improve your development skills?
Whenever I recommend Project Euler to people wishing to practise coding I always caveat it by saying "the first 50 problems are useful". After that Project Euler quickly becomes more mathematical, which is great if you wish to practise your maths skills, but may not be what you're looking for. There are exceptions, of course, and some questions may require implementing an important algorithm, but it is difficult to tell at first glance if you will be learning some esoteric area of number theory or something useful to your coding skills.
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).
If your someone who isn't very experienced in mathematics, it's better to do them in order (easiest to harder) that's how your suppose to progress. If you're starting with the last one, it's normal you feel lost, it's like starting mountain climbing with the Mount Everest.
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.
It's been useful for me. Back in high school, I raced to 50 problems against a friend and learned a lot along the way. Sure, you can get problems elsewhere, but the site has a nice way of continuously upping the complexity to enable self-learning.
> I think the best preparation for any interview is to
> simply get good at what you do
Isn't that exactly the problem? How often are you asked to do the stuff you do best in the interview?
Coding algorithms on the whiteboard is not what I do best.
I actually agree with Ed here. You should worry about things in your control rather than thinking about things beyond your control. I understand that interviews aren't fair etc. but I still believe keeping it simple is the best way to success.
Simplicity is the ultimate sophistication.-- Leonardo Da Vinci
The ideal candidate is not just competent, they're able to demonstrate and communicate that competence.
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.
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.