Ask HN: How to prepare for technical interviews?
I'm good at my day to day job but I suck at whiteboard style interviews. I'd like to hear form any HN'ers who have gone from Level Zero to pro at acing tech interviews. How you prepared , what resources you used and how long it took.
34 comments
[ 2.9 ms ] story [ 81.0 ms ] threadSlightly more related to your question: once you get to a certain point, you shouldn't still be doing whiteboard interviews. Your resume and completed projects should tell the interviewers that you can code, or you should be moving to management (if that's your thing). I never even ask technical questions of someone who has good references from a few companies.
And the answer I got always left me speechless: "Well, I don't really know what code you used or if you actually wrote it. So we're just going to fizzbuzz you to make sure you're good. We do this with everybody".
This didn't happen just once. It was actually the vast majority. The no-whiteboard approach seems to work only with early-stage startups. Once a company starts settling, say hello to mindless bureaucracy.
I think white boards are great if you use the information you gather from them in the proper way. Engineers solve problems, teams create global companies and change the world. I look at white board sessions to see how you can approach a problem, are you big picture or in the weed detail oriented. When I ask the question what do you focus on? Whether you solve the entire problem or not is not the deciding factor in my opinion.
Also, I think with the volume or applicants companies are looking for ways for people to prove they as contributed to their resume achievements and were not a back seat passenger the rest of the team carried along.
I'm used to getting these alpha dog; VP-of-whatever from big investment banks (I work in finance), with a laundry list of stuff they have done. Sure ok, good for you, now write up a skeleton class for a linked list in any language of your choice... what's that, you're stuck? You can't remember the keywords for defining a new class in the language you've labeled yourself as an EXPERT in? really?
Engineers solve problems. That's it. They use tools, they try things and they provide solutions. Asking an engineer to solve an imaginary problem on the spot is idiotic. You may have glided through school memorizing stuff and barfing them during exams. But engineers didn't. They understood how things work and why.
So when you ask an engineer to write a skeleton class for a linked list, his answer will always be "Why? What problem are you trying to solve?". They don't have it memorized. They build it as they go along, based on the specified requirements.
Unlike you, most engineers are friendly people. And not as aggressive. All they want to do is build something or help you do it. You on the other hand seem to have some envy problems. The "AHA! Not so smart now, mr VP of whatever..." attitude is exactly what's wrong with the tech industry.
Leave it to a bureaucrat to fuck things up.
2. I don't believe in memorizing stuff, I believe in understanding stuff... which is why I'm an engineer.
You say: "his answer will always be "Why? What problem are you trying to solve?"
Indeed, I WANT people to ask this question. Then I'd like them to suggest why a linked list is or isn't a good candidate for that problem. I will ask them to suggest an alternative method of solving my problem. A good interview is a conversation, but if the candidate has literally no questions to ask, and nothing to provide, and can't even solve the most basic problems that could be memorized, then why would I want him? If a candidate can't come up with a half-decent approach to a problem as simple as FizzBuzz or making a simple data structure container like a linked list; a problem which dwarfs in comparison with what I do on a daily basis at my job, he has no business sitting next to me.
You also say: "Asking an engineer to solve an imaginary problem on the spot is idiotic. "
Well, that just happens to be my job! My boss comes down, asks me "could you solve this problem for me?" and my answer is "I don't know, but I'll try!" and off you go. so my entire job is about solving unknown problems. Isn't yours? I'm not setting up WordPress sites or chaining together SAP modules (not that there's anything wrong with that, I used to do something like that for several years...), we actually solve problems that don't have known solutions, and the amount of data we work with also poses some unique problems. So our interview process is a miniature, and yes, imaginary, version of what you might be tasked with on any given day.
Finally, to clarify, this it the stance I take with people who claim to be "experienced experts". If I'm interviewing an intern or a junior developer, my approach will obviously be very different.
Why aren't you replicating this in your interviews? Why do you insist on code tests? Why aren't you insisting on the result? That's what your boss wants. I'm pretty sure he doesn't care about your ability to solve stupid trivia and academic tests.
This is why I'm saying you're a bureaucrat. You read somewhere about fizzbuzz and code tests and you stopped there. Didn't think for yourself. Just gobbled up what some other guys decided was good.
Want great conversations and to be amazed by experts? Give them real life problems to solve. You will look incompetent too if I start interviewing you with stupid "How do you do X?" questions.
But I'm going to level with you: if my expert can't handle a simple problem with training wheels, like FizzBuzz, it is a very strong indicator that attempting to give him a bigger problem to solve (but not code) is a waste of time.
To be a practicing lawyer, you are already tested extensively on hypothetical -- imaginary -- legal problems. If programmers had similar professional requirements, then general competency testing as part of an interview process would probably be less popular because that would be essentially outsourced to the credentialing association.
The only unbiased answer is you, showing me, right here, right now what you can and cannot do.
And remember, you do your best when you don't care about the job. If you do care, your nervousness and desire to impress will be perceived as incompetence. And at that point, you're just sabotaging yourself.
Additionally, site likes Top Coder and Hacker Rank are great for brushing up on your algorithms and problem solving.
- write using their hands
- face one direction and talk in another
- talk while coding
- estimate insertion space
- write in horizontally straight lines
- avoid getting ink on their sleeves
The best places I've interviewed at game me a machine, a problem, and some quiet time to solve it.
However for others, I bring pencil and grid paper, and ask to sit beside people and solve the problem with them looking over my shoulder.
With regards to timeline, I think I started preparing for my first phone interview a week early. The first couple of days were definitely slow, but with 3 days left, I studied for a couple hours each day before. For my first onsite, I found out about oj.leetcode.com about two weeks before and just did those problems almost non-stop for the two weeks leading up. Five days before the onsite, I rounded up some friends and we started doing whiteboard problems for a couple hours each day.
I guess preparation time varies by person. I did a little bit of competitive programming before this, so I would say I had a little bit of a head start. However, before this, I probably couldn't program a binary search off the top of my head, or approach dynamic programming problems, but now, I can probably handle a decent amount of algorithmimc interview problems. I can't say I'm pro, but I'm apparently good enough.
Firstly you need to learn to code small 10-20 line programs in your head (everything including proper syntax etc, if you printed a copy of your mental image it would compile), without that you get crippled just from being unable to properly reason about your code.
Secondly you need to build up an intuition for data structures and algorithms so that you can easily come up with solutions on the fly. Very few do this, some even thinks that it is impossible and assumes that the questions only test memorization.
As an alternative to the second step you can memorize a ton of algorithms and continue going to interviews till you get a question you have memorized. This is what people usually do which isn't strange since this is how most pass their CS exams.
The first step is easy, just stop using your favorite IDE and use something simple like notepad. When you are comfortable with writing code in notepad then you are ready for interview programming.
The second step is harder and will take years. The easiest way to get better at this is to try to solve problems without help. You can start by reading up on different data structures/algorithms on wikipedia and then try to implement them in your favorite language. You can do competitive programming in parallel to practice speed and try out your implementations on tests which are much better at finding bugs than any interviewer.
The alternative second step can take any amount of time depending on how lucky you are. Minimum is to memorize FizzBuzz by writing it over and over in notepad till you get it right 20 times in a row. This can be done in a day even if you are an idiot. From there you can continue adding solutions to problems till you get the job you want. Then just forget everything and come back complaining once you want another job. This already happened once for fresh CS graduates since they forgot what they crammed for their tests so now they need to cram again and again for every interview.