Skip to content
This repository was archived by the owner on Sep 3, 2024. It is now read-only.

Latest commit

 

History

History
107 lines (87 loc) · 5.62 KB

interviews-giving.md

File metadata and controls

107 lines (87 loc) · 5.62 KB

Giving an Interview

Welcome:

Introduce yourself (Leading Mentor = Lead Developer for [Company]; Backup Mentor = Sr. Developer) and thank them for coming in for the interview.

Outline the interview briefly. “Just so you know we are going to be asking you several questions to better understand you and your skills after which we’ll have you do some whiteboarding for us. Have you ever whiteboarded?” “Just a reminder for the whiteboarding portion, remember to talk out your entire thought process. The more you explain and talk out the better insight we get as to how you approach and solve problems which is what we want.”

Questions – 15 Minutes:

Always start with => “So, to start out please tell us a little bit about yourself.” Take notes of what they say in the “Interview Notes” section so you can give specific feedback on certain responses they give.

Listen to responses and ask follow up questions. If they mention something that you want to dig a little deeper into then ask a follow up question about it. “You mentioned you really like [tech or process]. Tell me about a time you used that on a recent project and why you chose that.” Or “Could you tell me a little bit more about what [something they mentioned]?”

I like to play off what they say. They need to understand that whatever they bring up will dictate the direction of the interview. Often times if they come in unprepared they will throw in filler stuff that isn’t accurate or just trying to make themselves sound better than they are. If you follow up on some of those things and they get stuck it will be a good learning experience for them to come more prepared to an interview. Don’t overdo this but follow up questions are good for them.

Use a combination of technical questions and situational questions.

Situational examples:

Tell me about a recent project you’ve worked on. Have you worked on a team of developers? What was the biggest challenge you faced working with others? Tell me about a time when you had to do something really hard in code. How did you solve it? Show me the code. What is your favorite piece of code that you have written? What would you say is your favorite part of development?

Technical examples:

What API’s have you used and how did you use them in your project? What other technologies/languages or features are you looking forward to learning/implementing in the future? Why did you choose Swift over Objective C/ Angular over REACT? Do you have any hosted projects/ projects in app store? Can you show me?

Remember to be taking notes and writing down things to give feedback on; both POSITIVE and things they can work on.

Whiteboarding – 10 Minutes:

Transition to the whiteboarding portion => “Thank you for all your answers, we’d like to transition to a whiteboarding question now. Remember that the goal of this is to help us understand how you think and approach a problem so please talk out all your thoughts and ideas.”

Use a simple toy problem/ basic stretch problem to have them code on the whiteboard. Start simple and if they solve it too quickly then have them add a level of difficulty into their solution.

Often they will be really quiet while deep in thought. In this case, ask them what they are thinking or remind them to talk out all their thoughts.

Let them struggle through the question. Sometimes it is obvious they don’t know how to solve the problem. Encourage them to keep trying. If they are really stuck remind them that we realize most developers use the internet when they get stuck and tell them they can use you as their internet. It’s ok for them to ask you questions – don’t give away the answers but help them enough to get onto the next part of the problem.

If, even after you give them some hints, they can’t code the answer then stop them and do the following. Say, “Let’s try something different. I’m going to teach you how I would solve this problem and please ask me any questions you have.” Then whiteboard the solution and explain what your process. After you finish ask, “Does that make sense? Any questions?” If they say they get it, then erase your work and ask them to code it again and explain the process.

Thank them and ask them to sit down. Finish the interview with this last question, “What questions do you have for us?” and answer as you can. Once they say no then say something like, “Great, we’ll give you our decision by the end of the week.”

Things to pay attention to:

Behavioral:

How was their eye contact? Did they use their hands well or not at all? Was their posture engaging or closed off? Did they speak in monotone or were they interesting to listen to? Did they strike a balance of “humble confidence” or did they come off too cocky or too insecure?

Answers:

How was the length of their answers? Should be no longer than 20 – 30 seconds.

Whiteboarding:

A good method for doing whiteboarding is this: Repeat the question and ask follow up questions On the left side of the board write down what they are looking for so you can reference it. Talk through and write out the steps you are going to take to solve the problem, using words not code. Ask the interviewer questions if they can’t think through the logic involved to answer the question. Begin coding and talk through each step. The more they talk the better, even if it’s explaining basic concepts. After finishing the problem run a couple of example tests and explain how it will work at each step (this also allows them to catch errors they may have made). Finish by being confident in your answer or by asking for feedback as to how they would have solved the problem.