Technicalsymposium

Before the Interview

Get a Book

As early as possible before your interview (though I only managed a meager two weeks), start preparing. Working through a prep book will not only refresh your algorithms and data structures knowledge, but it’ll also put you in the right problem-solving mindset.

Most importantly, pick the right prep book for your level and interests. Cracking the Coding Interview is a great resource, but if you’re not already a reasonably experienced programmer, it won’t make up for experience. If you’re just starting out, there are other books you’ll get more mileage out of, such as Programming Interviews Exposed: Secrets to Landing Your Next Job. And there are plenty of more specialized and advanced books for those with more experience.

Practice Makes Perfect

Few things beat panic like practice does, so start whiteboarding whenever you can, even really small problems. Coding interview books offer nearly endless sample problems, but you can use problems you’re already working on, too. Pose the problem to yourself (or ask a technically inclined friend to pose it to you, for a more realistic setup), map out your strategy, and put marker to dry erase board. The more comfortable you are with marking up that blank board at home, the less hesitant you’ll be at the interview.

If you’re short on time and want to get over the shakes quickly, you can add pressure that won’t be there in the actual interview. If you give yourself a time limit or have someone you respect playing the role of your interviewer, the real deal will feel like a piece of cake.

Don’t Overload Yourself

When you’re scheduling interviews, be sure to leave at least a couple of hours in between each one. This sounds like a first-world problem, but any time I had multiple interviews in a day, I didn’t perform as well as I could have. I either worried about getting to the next one on time or I had already maxed out my logic hours before.

Oh, and get some sleep. This sounds like something your mom would tell you, but there are few things that will throw you off your game like sleep deprivation. It’s comparable to showing up drunk.

In the Interview

Be Ready for Anything

Once you’ve made it to your interview, you should be prepared for a few different kinds of problem solving. Your interviewers may ask you to talk through how you would solve a problem, they may open a computer and ask you to guide them through creating code, or they may have you write the code yourself on a whiteboard. Be prepared for variation, and don’t get tripped up on the details! No matter what method your interviewers are using, it’s your problem solving skills that they're really testing.

Ask Questions

When you’re presented with a problem, think it through and make sure you fully understand what you’re being asked to return. Don’t be afraid to ask questions early if anything is unclear. If there are edge cases, for example, ask how your interviewers want them to be handled. Should you throw an exception? Break?

Also make sure to ask procedural questions to understand what the interviewers are looking for and what your constraints are—e.g., “Is there a specific language you’d like me to give you my solution in?” or “Can I assume I have access to any Python library?”

And don’t make assumptions. Even if you’re pretty sure it’s safe, mention out loud what it is you’re thinking so the interviewers can let you know if you’re missing something.

Take Your Time

Once you understand the question you’re being asked, don’t be afraid to take a minute to think and process before you start solving the problem. As long as you aren’t being barraged with quick, knowledge-based questions, pausing after being asked the question is a good thing. Of course—make sure you’re not taking 10 minutes to solve it in your head without saying a word! The point is to use your time up front to structure your approach, not to try to write all the code in your head before you touch marker to whiteboard.

Think Big Picture

Think about the big picture of the problem first. It’s fine to pseudo-code the overall structure, as long as you tell the interviewers that’s what you’re doing and that you intend to go back and actually code it later. It’s a good way to off-load the organizing of the problem so your brain has more room for processing. This will also help if you run out of time in the end; the interviewers will at least know how you’d planned to finish out the task even if you didn’t get to the details.

Also, don’t worry at first about finding the most efficient way to solve the problem, unless it naturally pops into your head. Nail a less-efficient solution, and then discuss why it’s less than ideal. Then, if you have time or see a better way to solve it, move on to a more time- or space-friendly algorithm. Even if all you have time to do is finish your less-efficient version and then explain how you would do it better, that’s not a bad answer.

Talk it Out

Most importantly: Talk. Bring your interviewers along with you in your problem solving. This can be as simple as outlining what you’re about to do when you’re doing it (“So, I’ll need a for-loop to iterate through all the items in this list”) or posing problems to yourself as you go (“This means I’ll need a better way to access the information; hmm, I’ll get back to that later”).

Talking through your thought process gives your interviewers a window into how you think, and that’s ultimately the point of the interview. Even if you think your solution is amazing, it’s better for them to know how you approached the problem and got to your answer than to see the full-fledged answer and not have a clue about what led you there. It also gives the interviewers a chance to help you along if you’re stuck or going down a path that’s a dead end.

Bring Your People Skills, Too

Just because you’re going for an engineering job doesn’t mean you can slack on being personable and responsible. I’ve heard horror stories of fantastic programmers who weren’t hired because they weren’t a culture fit or had a bad attitude. I’m sure you have, too. Don’t be that person.

Curiosity and enthusiasm are prized in any employee—and developers are no different. Ask about the company’s engineering team, its stack, and the toughest problems it’s tackling for the product. Of course, there’s a fine line between being enthusiastic and being a sycophant, so keep it genuine, but everyone loves a candidate who is interested in the product he or she will be working on.

Learn Something New

Finally, one thing that interviewees most often miss is the learning opportunity. Hopefully, you will learn something new in each interview—you’ll acquire a new idea or new tool, or get some insight into interesting products and technology. The more you think about your interviews in this way, the more valuable that time will be to you in the long run.

Source: Contents are provided by Technicalsymposium Google Group Members. Disclaimer: All the above contents are provided by technicalsymposium.com Google Group members. Further, this content is not intended to be used for commercial purpose. Technicalsymposium.com is not liable/responsible for any copyright issues.