#1 | Practicing on a Computer
If you were training for a serious bike race in the mountains, would you practice only by biking on the streets? I hope not. The air is different. The terrain is different. Yeah, I bet you’d practice in the mountains.
Using a compiler to practice interview questions is like this - and you’ve basically been biking on the streets your entire life. Put away the compiler and get out the old pen and paper. Use a compiler only to verify your solutions.
#2 | Not Rehearsing Behavioral Questions
Many candidates spend all their time prepping for technical questions and overlook the behavioral questions. Guess what? Your interviewer is judging those too! And, not only that - your performance on behavioral questions might bias your interviewer’s perception of your technical performance. Behavioral prep is relatively easy and well-worth your time. Looking over your projects and positions and think of the key stories. Rehearse the stories. See pg 29 for more details.
#3 | Not Doing a Mock Interview
Imagine you’re preparing for a big speech. Your whole school, or company, or whatever will be there. Your future depends on this. And all you do to prepare is read the speech to yourself. Silently. In your head. Crazy, right?
Not doing a mock interview to prepare for your real interview is just like this. If you’re an engineer, you must know other engineers. Grab a buddy and ask him/her to do a mock interview for you. You can even return the favor!
#4 | Trying to Memorize Solutions
Quality beats quantity. Try to struggle through and solve questions yourself; don’t flip directly to the solutions when you get stuck. Memorizing how to solve specific problem isn’t going to help you much in an interview. Real preparation is about learning how to approach new problems.
#5 | Talking Too Much
I can’t tell you how many times I’ve asked candidates a simple question like “what was the hardest bug on Project Pod?”, only to have them ramble on and on about things I don’t understand. Five minutes later, when they finally come up for air, I’ve learned nothing - except that they’re a poor communicator. When asked a question, break your answer into three parts (Situation / Action / Response, Issue 1 / Issue 2 / Issue 3, etc) and speak for just a couple sentences about each. If I want more details, I’ll ask!
If you were training for a serious bike race in the mountains, would you practice only by biking on the streets? I hope not. The air is different. The terrain is different. Yeah, I bet you’d practice in the mountains.
Using a compiler to practice interview questions is like this - and you’ve basically been biking on the streets your entire life. Put away the compiler and get out the old pen and paper. Use a compiler only to verify your solutions.
#2 | Not Rehearsing Behavioral Questions
Many candidates spend all their time prepping for technical questions and overlook the behavioral questions. Guess what? Your interviewer is judging those too! And, not only that - your performance on behavioral questions might bias your interviewer’s perception of your technical performance. Behavioral prep is relatively easy and well-worth your time. Looking over your projects and positions and think of the key stories. Rehearse the stories. See pg 29 for more details.
#3 | Not Doing a Mock Interview
Imagine you’re preparing for a big speech. Your whole school, or company, or whatever will be there. Your future depends on this. And all you do to prepare is read the speech to yourself. Silently. In your head. Crazy, right?
Not doing a mock interview to prepare for your real interview is just like this. If you’re an engineer, you must know other engineers. Grab a buddy and ask him/her to do a mock interview for you. You can even return the favor!
#4 | Trying to Memorize Solutions
Quality beats quantity. Try to struggle through and solve questions yourself; don’t flip directly to the solutions when you get stuck. Memorizing how to solve specific problem isn’t going to help you much in an interview. Real preparation is about learning how to approach new problems.
#5 | Talking Too Much
I can’t tell you how many times I’ve asked candidates a simple question like “what was the hardest bug on Project Pod?”, only to have them ramble on and on about things I don’t understand. Five minutes later, when they finally come up for air, I’ve learned nothing - except that they’re a poor communicator. When asked a question, break your answer into three parts (Situation / Action / Response, Issue 1 / Issue 2 / Issue 3, etc) and speak for just a couple sentences about each. If I want more details, I’ll ask!
No comments:
Post a Comment