- Why Technical Interviews Work (And Why They Don't)
- The Technical Interview Is Dead (And No One Should Mourn)
- Why we don't have technical interviews for technical roles at Buffer
- Programmers are confessing their coding sins to protest a broken job interview process
- The Rise And Looming Fall Of The Engineering Whiteboard Interview
- Is It Time to Kill the Whiteboard Interview?
You might notice that a fair number of these links are to articles about how the whiteboard interview is ineffective or failing. This isn't because of my bias; it's because there are a lot of articles out there questioning the efficacy of whiteboard coding interviews. Yet, in spite of the number of articles predicting the downfall of such interviews, they are still very much in the mainstream. It is very difficult to find a tech company that doesn't expect whiteboard coding (or, if over the phone, coding in a shared web environment where the interviewer can watch the interviewee's every keystroke) from each of its software developer candidates.
The lesson here is that if you are going to get a software development job then it is very likely that you'll need to pass at least one coding interview. Some companies will even do one or two coding interviews over the phone, then have you come on site and do three or four more on the whiteboard. This makes the ability to get through these interviews an important skill for landing a job, if not for actually doing the job. What follows are some tips (in no particular order) for how to get through a coding interview.
- Talk to the interviewer. The theory behind a coding interview is that the interviewer gets to see not only if you can write code or not, but also how you go about solving a problem. If you do all of your thinking inside your head then not only is the room (or phone line) filled with awkward silence, but the interviewer has no idea whatsoever what you're thinking or how you're working through the problem.
- Ask questions. Some interviewers will deliberately leave important information out of the question they ask you in order to determine whether you can identify the missing information and know to ask for it. Do not make assumptions about what they must have meant! This is a major tripping point for a lot of people, as the tendency is to dive into coding using assumptions that they don't even realize they've made. Instead, treat the interviewer as a collaborator and work with them in coming up with a solution.
- Write a few examples on the board before beginning to code. This not only helps clear up any misunderstandings that there may be about what the problem is asking for, but it also gives you something to test your code against as you go along.
- Practice a LOT before the interview. There are a lot of ways for you to get practice in, some free, some not. https://codefights.com/ allows you to test your skills against other people. https://www.meetup.com/ probably has meetups in your area in which people get together to practice coding interviews. There are also classes or coaching sessions, such as Technical Interview Mastery Workshop, put on by Blossom Career. (Full disclosure: Blossom Career is my wife's company and I help teach the workshop. There is a fee for this workshop that helps cover the cost of renting space for it.) The point here is to get a lot of practice, whether via one on one coaching, group coaching, practicing with others, or simply practicing on your own. (If you don't have a whiteboard, you can practice by writing your code on paper.) Make sure that you practice explaining what you're doing as well as solving the problems/writing the code.
One final note on this topic for you: there are lots of books out there that offer sample interview questions for you to practice with. By far the best book I have seen is Cracking the Coding Interview by Gayle Laakmann McDowell. This book not only contains sample questions and solutions, but it also contains chapters with excellent advice on getting through the interviewing process. I highly recommend this book. (I have no affiliation with the author or publisher of this book, I just think it is an excellent resource for you.)
No comments:
Post a Comment