This wiki has been closed because there have been no edits or logs made within the last 60 days. This wiki is now eligible for being adopted. To adopt this wiki please go to Requests for reopening wikis and make a request. If this wiki is not adopted within 6 months it may be deleted. Note: If you are a bureaucrat on this wiki you can go to Special:ManageWiki and uncheck the "closed" box to reopen it.

Interview Coach

From Ada Developers Academy Wiki
Jump to navigation Jump to search

As an interview coach, your job is to help students practice their interview skills. You will come to Ada for an afternoon, sit in a room with a whiteboard, and conduct a series of interviews with our students. It's a lot of fun!

To become an Interview Coach, please email

What should I expect?

  • Our mock interviews are generally in the afternoons around 1-5pm.
  • You give us your availability and we will send a calendar invite for a time slot
  • When you get to the location, we will place you in a small room with a whiteboard
  • Students will not bring their laptops with them unless you ask us to request that ahead of time
  • Students will be nervous (who isn't in an interview?!)
  • Students are looking for constructive, helpful feedback to improve their interviewing skills. This is a learning activity for them!
  • You choose your own questions to ask and provide feedback at the end

What is the format?

Mock Interviews for Internships Mock Interviews for Full Time positions
These practice interviews will be 30 minute blocks consisting of:
  • 5 mins - get to know you
  • 15 mins - technical/whiteboarding problem
  • 10 mins - feedback including what went well and what could be improved
  • (followed by break between students)
These practice interviews will be 1 hour blocks consisting of:
  • 5 mins - get to know you
  • 35 mins - technical/whiteboarding problem
  • 10 mins - feedback including what went well and what could be improved
  • (followed by break between students)

What questions should I ask?

In general, getting comfortable with the format and practicing solving problems and communicating ideas using a whiteboard is more important than solving a challenging problem.

You may ask any questions that you like, especially if you have some particular questions that you like to ask; but please consider the following information when picking your questions to make sure that you have an understanding of where our students are and what they have learned.

Example Questions to Ask Example Questions NOT to Ask
  • Write a function to determine if a string is a palindrome
  • Write a function that counts the number of unique words in a string
  • Write a function that validates a phone number given some validation rules
  • Given coordinates of two rectangles determine if they overlap
  • Given two lists return the intersection of the lists
  • Write a function that takes an array of unique sorted integers (eg. [1,2,3,5,7,9,10,11]) and outputs a string of the ranges (eg. "1-3,5,7,9-11")
  • Express the relationship of a set of objects with an ERD or similar diagram
  • Describe software that could improve the efficiencies in one of your previous jobs
  • Questions that require detailed knowledge of specific data structures.
  • Questions about topics they haven't covered yet in the course. This will be different for students in the classroom vs in internship.

What else do I need to know?

  • Check out our syllabus for more info about what the students are learning in class!
  • Our students are women and gender diverse people. Please introduce yourself with pronouns ("Hi, my name is Ada Lovelace and my pronouns are she/her") and try to avoid gendered vocabulary ("women", "ladies", "you guys", etc.). This isn't always easy and we don't expect perfection, but we do expect a sincere effort.
  • Our students are new to coding! Your job is to help them skill up at something hard. Specifically, try to avoid referring to concepts as something that "programmers should already know", as something that "you can't get a job if you don't understand", or as “easy”. We have found that this is discouraging, not helpful. Things that are easy to you may be difficult to someone else, and trivializing them trivializes a person who struggles with them.
  • Do not "well, actually" your interviewee, instead let them complete their thoughts and hold your feedback until the feedback phase of the interview.
  • Do not look at your phone instead of your interviewee.
  • Stay on schedule! Make sure that all students feel like they got the same energy and time as their peers.
  • Remember that our students all quit their jobs and found means to dedicate a year of their life to this program. Programming is not a hobby to them.