There are questions that, as an interviewer, I am not allowed to ask. Some are straight up illegal, because it could cause bias or discrimination. A few examples are:
I can, however, ask indirect questions that answer these questions. I might ask something which sounds innocent like “Do you have any plans for the weekend?” if I interview someone on a Friday. Or I might ask if you have plans for an upcoming holiday. Your answers could help me find information that I’m not allowed to ask directly.
The problem area here is answering vaguely. You want to sound friendly, like a coworker would share anyway, but like Miranda rights in America, “everything you say can be used against you”. It will take some practice to find a balance between being friendly and not over-sharing.
Be respectful of everyone’s time and show up early. If you’re joining a conference call, join the call 2-3 minutes early. If you’re on-site for an interview, be 5-10 minutes early.
Bring printed copies of your resume; some interviewers may not have seen it yet, and providing a copy gives them talking point opportunities.
Bring paper, and sketch the problem. Sometimes drawing a block diagram can help when breaking down a problem. Be sure to let the interviewer know why you’re drawing on paper when they expect you to write code, and take 15 to 20 seconds to sketch what you need to do. This tells me several things about you as a developer:
Treat every problem as though you’re trying to tutor another student. This not only forces you to think out loud in complete thoughts, it will cause you to explain why you’re solving it the way you are, which will project far more confidence in your answers.
Don’t assume you can look up documentation or use a debugger. You generally get one chance to ask to look something up, but don’t feel discouraged if they say no. Remember, they want to see you succeed, so either they want to see how you’ll handle buggy code, or they’re willing to offer hints while you work.
Don’t ask them to reiterate the problem more than one time. Take notes and use your design sketch to help you recall what’s needed.
It’s possible that you’ll freeze up getting started, but don’t stay frozen. You HAVE to start somewhere, even if you have to reverse the problem like a math puzzle and take it from the solution back to your starting point.
Don’t give up, but if you absolutely can’t find an answer, offer a complete idea of how you would finish solving the problem with online help. Don’t just tell me “I’d look on Google or Stack Overflow”. Tell me what you’d search for. Tell me how you’d evaluate blog posts, Stack Overflow answers, etc to determine which one best fits your use case. This does feel like a cop-out, but if you’re lucky the interviewer will give you partial credit for working out most of the code and getting stuck on the last piece.
TODO:
Finish strong and follow up. Always close with a final statement that makes it crystal clear that you are genuinely excited and interested in the opportunity, including why you’d be a great hire and fit for the job and organization. Clarify next steps and the timeline. Email a thank you note less than 24 hours after the interview while it is still fresh on your mind. Articulate your fit and why they should hire you specific to the interview conversations. Every interviewer expects a thank you note from each candidate, so no note is a sign of no interest and no professionalism. To really stand out, also send a neatly hand-written thank you note soon after the interview.