Book by Gayle Laakmann McDowell
Code here: click
- Chapter 1: The Interview Process
- Chapter 2: Behind the Scenes
- Chapter 3: Special situations
- Chapter 4: Before the Interview
- Chapter 5: Behavioral Questions
Assessment of a candidate performance:
- Analytical skills: Did you need much help to solve the problem? How optimal was your solution? How long did it take you to arrive at a solution?
- Coding skills: Were you able to successfully translate your algorithm to reasonable code? Was it clean and well-organized? Did you think of potential errors? Did you use good style?
- Technical knowledge: Do you have a strong foundation in computer science and the relevant technologies?
- Experience: Have you made good technical decisions in the past? Have you built interesting, challenging projects? Have you shown drive, initiative, and other important factors?
- Culture fit: Do your personality and values fit with the company and team? Did you communicate well with your interviewer?
False negatives are acceptable. Some good candidates are rejected. The company is out to build a great set of employees. They can accept that they miss out on some good people. Company is far more concerned with false positives: people who do well in an interview but are not in fact very good.
Basic data structure and algorithm knowledge is useful. It is a good proxy. These skills are not hard to learn, but are well-correlated with being a good developer. Also, it is hard to ask problem-solving questions that don't involve algorithms and data structures.
Your interviewer develops a feel for your performance by comparing you to other people. Getting a hard question isn't a bad thing. When it is harder for you, it is harder for everyone.
If you haven't heard back from a company within 3-5 business days after interview, check in with your recruiter.
You can almost always re-apply to a company after getting rejected. Typically, you have to wait between 6-12 months.
"Bar raiser" interviewer is charged with keeping the interview bar high. This person has significant experience with interviews and veto power in the hiring decision.
Experienced candidates. More experienced engineers might see slightly less focus on algorithm questions. Some interviewers might hold experienced candidates to a somewhat lower standard. After all, it has been years since these candidates took an algorithms class. Others though hold experienced candidates to a higher standard. On average, it balances out.
The exception to this rule is system design and architecture questions. Performance in such interview questions would be evaluated with respect to your experience level.
Personality fit: Typically assessed by how you interact with your interviewer. Establishing a friendly, engaging conversation with your interviewers is your ticket to many job offers.
For interviewers.
- Don't actually ask the exact questions in here (this book). You can ask similar questions to these. Some candidates are reading this book. Your goal is to test their problem-solving skills, not their memorization skills.
- Ask Medium and Hard problems. When you ask questions that are too easy, performance gets clustered together.
- Use hard questions, not hard knowledge. If your question expects obscure knowledge, ask yourself: is this truly an important skill? Most won't remember Dijkstra's algorithm or the specifics of how AVL trees work.
- Avoid "scary" questions. Some questions intimidate candidates, because it seems like they involve some specialized knowledge, even if they really don't - math or probability, low-level knowledge, system design or scalability, proprietary systems (e.g. Google Maps). If you are going to ask a question that sounds "scary", make sure you really reassure candidates that it doesn't require the knowledge that they think it does.
- Offer positive reinforcement. You want candidates to feel comfortable. A candidate who is nervous will perform poorly, and it doesn't mean that they aren't good. Moreover, a good candidate who has a negative reaction to you or to the company is less likely to accept an offer - and they may dissuade their friends from interviewing/accepting as well. No matter how poorly a candidate is doing, there is always something they got right. Find a way to infuse some positivity into the interview.
- Coach your candidates.
- Many candidates don't use an example to solve a question. Guide them.
- Some candidates take a long time to find the bug because they use an enormous example. They didn't realize it would be more efficient to analyze their code conceptually first, or that a small example would work nearly as well. Guide them.
- If they dive into code before they have an optimal solution, pull them back and focus them on the algorithm.
- If they get nervous and stuck and aren't sure where to go, suggest to them that they walk through the brute force solution and look for areas to optimize.
- Remind them that they can start off with a brute solution. Their first solution doesn't have to be perfect.
- If they want silence, give them silence. If your candidate needs this, give your candidate time to think.
- Know your mode: sanity check, quality, specialist, and proxy.
- Sanity Check - Easy problem-solving or design questions. They assess a minimum degree of competence. You can use them early in the process.
- Quality Check - More challenging questions. Designed to be more rigorous and make a candidate think.
- Specialist Questions - Test knowledge on specific topics, e.g. Java or machine learning.
- Proxy Knowledge - This is knowledge that is not quite at the specialist level, but that you would expect a candidate at their level to know.
If you are smart, you can code, and you can prove that, you can land your interview.
Resume screeners want to know that you are smart, and you can code. You should prepare your resume to highlight these 2 things. Think twice before cutting more technical lines in order to allow space for your non-technical hobbies.
Keep your resume short, max. 1.5-2 pages. Long resumes are not a reflection of having tons of experience, there are a reflection of not understanding how to prioritize content. A resume should not include a full history of every role you have ever had. Include only the relevant positions - the ones that make you a more impressive candidate.
For each role, try to discuss you accomplishments with the following approach: "Accomplishment X by implementing Y which led to Z". Not everything will fit into this approach, but the principle is the same: what you did, how you did it, and what the results were.
Ensure that you have one to three projects that you can talk about in detail. You should be able to discuss the technical components in depth. These should be projects where you played a central role.
What are your weaknesses? A good answer conveys a real, legitimate weakness but emphasises how you work to overcome it.
What questions should you ask the interviewer?
- Genuine Questions: these are the questions you actually want to know the answer to.
- Insightful Questions: these questions demonstrate your knowledge or understanding of technology. These questions will typically require advance research about the company.
- Passion Questions: these questions are designed to demonstrate your passion for technology. They show that you are interested in learning and will be a strong contributor to the company. E.g.: I am very interested in scalability, and I would love to learn more about it. What opportunities are there at this company to learn about this?
Be specific, not arrogant. How do you make yourself sound good without being arrogant? Be specific. Specificity means giving just the facts and letting the interviewer derive an interpretation.
Stay light on details and just state the key points. Your interviewer can ask for more details.
Focus on yourself, not your team. More "I", less "we".
Give structured answers.
- Nugget first - means starting your response with a "nugget" that succinctly describes what your response will be about.
- S.A.R (Situation, Action, Result) - you start off outlining the situation, then explaining the actions you took, and lastly, describing the result.
Tell me about yourself, suggested structure:
- Current role (headline only)
- College
- Post college & onwards (job, technologies)
- Current role (more details)
- Outside of work (hobbies)
- Wrap up (what are you looking for)