This was originally posted here as a LinkedIn article, in response to a request from a former student for advice on going back into job hunting after working for a year.
Interview mode is definitely different than school or development mode, so it makes sense that transitioning between modes will have its challenges.
The books I use to prepare for interviewing are "The Perfect Interview" by John Drake, (really helpful for behavioral interviews, 2011), and "Programming Interviews Exposed: Secrets to Landing your Next Job" by John Mongan and Noah Suojanen, (looks like there's a few versions: 2000, 2007, 2012). Paired together, I like the focus on behavioral interviews and programming interviews.
As I tell students in the Senior Projects class, interviewers are aiming to answer two basic questions: a) can you do the job they're hiring for, and b) will you fit into the team's culture? Programming interviews are a tool to explore whether your skills from your resume are genuine, and whether you're a good match to the job posting. Behavioral questions allow some digging into experiences you've had in the past (again, resume-prompted or driven by job posting), and looking for culture. Generally, both types of interviews can inform both of the questions they're looking to answer.
I like that these concepts are raised in "The Perfect Interview", with encouragement to think like you were going to be interviewing someone for the job you're applying for. What skills would you prioritize? How would you go about assessing whether the candidate has them or not? How would you figure out whether you might not want to work with a candidate, before you hire them (because then if you can't work with them, you have to fire them, which is hard).
I like the approach of trying to get into the interviewer's mindset, because it has me giving more weight to technical communication, high-level task planning, showing me that the candidate is capable of thinking through all the phases of software engineering. For me, when I interview, this translates into making sure I have the question understood and captured well (requirements), sketching out test cases, and then running the test cases through the code (testing), pitching high-level approaches to thinking about the project (design) before digging into any code, possibly to include pseudo-code, possibly including sketching the class or structure to be used (data structures) and pitching high level ways to solve the problem (algorithms). I also like to start with the very bad approaches, and indicate why I'd reject that approach outright. So brute-force is pretty often the first spot I throw out for consideration, before saying there has to be a better way. This lets me iterate on solutions in the interview, and throw in run-time analysis at the same time. Along the way, I try my hardest to remember to talk about what I'm thinking and where I'm going, and to make meaningful notations on my workspace (whether on paper, a terminal, or whiteboard). This supports the technical communication piece. I also try to keep an eye on time, and after getting a decent amount of depth on the problem, then I offer the interviewer an opportunity to direct where I spend my time next (go into implementation details and code on best solution so far, keep looking for another solution, or keep looking for a glaring flaw in the solution already pitched). This shows I'm willing to think about my impact on those around me (teamwork), and lets them steer where they want to see based on how they think they want the interview to run. Sometimes, they want me to get a major breakthrough moment or find the O(n) solution to the problem. Other times, they really have wanted to get down into seeing me write code in a particular language, or are hoping to find out whether I know a specific data structure of a language (often, I don't, but I put out enough info to give the impression that if I had that specific construct, I could integrate it and move forward developing algorithms for it fairly smoothly).
One suggestion for how to prepare for interviewing mode is to pull up a search for interview questions. I like projecteuler.net as a place with a bunch of problems which can be coded up in any language. Don't try to solve all the problems, but rather try to pick out a handful, and then practice using it as an opportunity to demonstrate your software engineering skills (or whatever skills the job posting is highlighting as being critical). I'd suggest trying a few on your own, and then stop periodically to think about how you would explain to someone else what your technical solution is so far, and where you are planning to go next. If you're concerned about whether you're being too focused and not talking enough, then move to having someone sit in with you, and prompt you to explain yourself every 20 seconds or so (if you haven't spoken up yet).
Once you are focused on what the interviewer is trying to get out of the interview, I think you'll find it easier to ignore some of the details that might otherwise cause you to get hung up, and instead focus on those skills like communication, teamwork, listening, etc., which are critical to the larger picture than just "can you work with an inverse binary tree?"
Interview mode is definitely different than school or development mode, so it makes sense that transitioning between modes will have its challenges.
The books I use to prepare for interviewing are "The Perfect Interview" by John Drake, (really helpful for behavioral interviews, 2011), and "Programming Interviews Exposed: Secrets to Landing your Next Job" by John Mongan and Noah Suojanen, (looks like there's a few versions: 2000, 2007, 2012). Paired together, I like the focus on behavioral interviews and programming interviews.
As I tell students in the Senior Projects class, interviewers are aiming to answer two basic questions: a) can you do the job they're hiring for, and b) will you fit into the team's culture? Programming interviews are a tool to explore whether your skills from your resume are genuine, and whether you're a good match to the job posting. Behavioral questions allow some digging into experiences you've had in the past (again, resume-prompted or driven by job posting), and looking for culture. Generally, both types of interviews can inform both of the questions they're looking to answer.
I like that these concepts are raised in "The Perfect Interview", with encouragement to think like you were going to be interviewing someone for the job you're applying for. What skills would you prioritize? How would you go about assessing whether the candidate has them or not? How would you figure out whether you might not want to work with a candidate, before you hire them (because then if you can't work with them, you have to fire them, which is hard).
I like the approach of trying to get into the interviewer's mindset, because it has me giving more weight to technical communication, high-level task planning, showing me that the candidate is capable of thinking through all the phases of software engineering. For me, when I interview, this translates into making sure I have the question understood and captured well (requirements), sketching out test cases, and then running the test cases through the code (testing), pitching high-level approaches to thinking about the project (design) before digging into any code, possibly to include pseudo-code, possibly including sketching the class or structure to be used (data structures) and pitching high level ways to solve the problem (algorithms). I also like to start with the very bad approaches, and indicate why I'd reject that approach outright. So brute-force is pretty often the first spot I throw out for consideration, before saying there has to be a better way. This lets me iterate on solutions in the interview, and throw in run-time analysis at the same time. Along the way, I try my hardest to remember to talk about what I'm thinking and where I'm going, and to make meaningful notations on my workspace (whether on paper, a terminal, or whiteboard). This supports the technical communication piece. I also try to keep an eye on time, and after getting a decent amount of depth on the problem, then I offer the interviewer an opportunity to direct where I spend my time next (go into implementation details and code on best solution so far, keep looking for another solution, or keep looking for a glaring flaw in the solution already pitched). This shows I'm willing to think about my impact on those around me (teamwork), and lets them steer where they want to see based on how they think they want the interview to run. Sometimes, they want me to get a major breakthrough moment or find the O(n) solution to the problem. Other times, they really have wanted to get down into seeing me write code in a particular language, or are hoping to find out whether I know a specific data structure of a language (often, I don't, but I put out enough info to give the impression that if I had that specific construct, I could integrate it and move forward developing algorithms for it fairly smoothly).
One suggestion for how to prepare for interviewing mode is to pull up a search for interview questions. I like projecteuler.net as a place with a bunch of problems which can be coded up in any language. Don't try to solve all the problems, but rather try to pick out a handful, and then practice using it as an opportunity to demonstrate your software engineering skills (or whatever skills the job posting is highlighting as being critical). I'd suggest trying a few on your own, and then stop periodically to think about how you would explain to someone else what your technical solution is so far, and where you are planning to go next. If you're concerned about whether you're being too focused and not talking enough, then move to having someone sit in with you, and prompt you to explain yourself every 20 seconds or so (if you haven't spoken up yet).
Once you are focused on what the interviewer is trying to get out of the interview, I think you'll find it easier to ignore some of the details that might otherwise cause you to get hung up, and instead focus on those skills like communication, teamwork, listening, etc., which are critical to the larger picture than just "can you work with an inverse binary tree?"