How to Ace the Technical Phone Interview
•
2 likes•4,346 views
More info and video at http://eatcodeplay.com/how-to-ace-the-technical-phone-interview/
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to How to Ace the Technical Phone Interview
Similar to How to Ace the Technical Phone Interview (20)
Recently uploaded
Recently uploaded (20)
How to Ace the Technical Phone Interview
- 1. how to ace the technical phone interview
- 5. smart gets things done not a jerk -Joel Spolsky
- 7. before we get started
- 9. i. am. a. full. stack. developer.
- 22. interviewclosing
- 26. following up if things didn’t go so well interview
- 32. typesexamples
- 35. typespolymorphism method lookup left, right, outer joins
- 36. typespolymorphism method lookup left, right, outer joins dependency injection
- 37. typespolymorphism method lookup left, right, outer joins dependency injection quicksort
- 38. typeshow to ace it
- 41. typesexamples
- 42. typesfavorite language - love/hate?
- 43. typesfavorite language - love/hate? tell me about redis at acme inc
- 44. typeshow to ace it
- 47. typesexamples
- 50. typesdeck of cards filesystem tracking page views
- 51. typeshow to ace it
- 54. typesexamples
- 55. typessum a file
- 57. typessum a file regex countdown timer
- 58. typessum a file regex countdown timer algorithms*
- 59. typeshow to ace it
- 62. typesexamples
- 63. typessearch 1 million names
- 64. typessearch 1 million names build a game
- 65. typessearch 1 million names build a game app with tests
- 66. typeshow to ace it
- 70. resourcesfive essential phone screen questions cracking the coding interview interviewcake.com
- 74. the scoop
- 75. he scoopwrite and call method write and instantiate class url vs local file language knowledge naming troubleshooting baby steps talks through everything asks clarifying questions finding things online alternative versions time and space complexity
- 82. thanks!
Editor's Notes
- 10+ years software experience, 5+ as lead Given close to hundred phone tech interviews; dozens of onsite tech interviews As a candidate, I've also successfully (and unsuccessfully) gone through several phone and onsite interviews all slides and video will be posted online with my presenter notes
- I currently head up engineering at realscout.com and I’m super excited to announce that we just launched our engineering blog at ecp.com
- Before we get started with the meat of it, let’s define what we’re talking about. A technical interview is usually the second step in the interview process. These interviews are usually less taxing than onsite interviews, but still can be quite demanding. I’m going to tailor it for full stack developers interviewing with small to medium sized startups. By the end of this talk, my goal if for you to have a very clear understanding of how to prepare for a technical phone interview, what to expect going into it, so you can come out of every interview with a smile on your face. This is a no-holds-barred talk - At the risk of spilling the beans on my own interview process - I’m gonna let you in on everything I’ve learned over the years and at the end, you can ask me anything.
- So, in a nutshell, interviewers (including myself) are looking for these things So during the whole interview process, we’re basically just looking for clues that support those three things - feel free to be proactive in helping make your case. It’s a chance for you to talk with an engineer at the company you’re interviewing with and for the interviewer to get a good decent handle on your capabilities.
- To that end, during this talk we’ll go over the actual interview - how to prepare, how to handle the actual interview and what to do afterwards. After that, we’ll go through a few different types of technical phone interviews with examples of each. Finally, we’ll wrap up with tips and resources to follow up on.
- Before we move on, I’d like to touch on something that a lot of people don’t talk about, but is hugely relevant and important to you guys. And I’d like to introduce it with a personal story. Back in 2006 - a couple years out of college - I wanted to build a web app for my family, so I bought a PHP & MySQL book and went at it. At the time, I was working at a power company putting my electrical engineering degree to good use. (ok, well mediocre use.) I had pretty much mentally left my job and was coding in most of my spare time. I got involved with a local co-working space and started attending meetups. Every time I introduced myself, I couldn’t muster up the courage to say I was a web developer. I’d say, “I work at a power company, but I code on the weekends!”. I felt like a phony hanging around all these smart people that had been doing web dev for years and years. A few months passed, I built an app with a couple friends from the co-working space and it became somewhat popular in the Philadelphia area. That led to a full-time freelancing gig and I was off to the races. I was finally a web developer! Well, err, no - looking back, it irked me that I couldn’t call myself a web developer before it was actually how I earned my salary. I was a web developer the whole time, I just had a serious case of imposter syndrome. Thanks for riding along, but it does have a point. Almost everyone in this room wasn’t doing web development 2 months ago. There are lawyers, teachers, engineers, financial analysts, you name it. But now you’re going through one of the best training programs in the country after making the extremely strict acceptance rates. You’re learning at an incredible rate - doing things you wouldn’t have thought possible a short while ago. In a month or two, you’ll be trying to convince the world that you are indeed a full stack developer. So believe it. You are a full stack developer. You all are going to go on to do amazing things. Interviews are sometimes intimidating and easy to lose sight - but don’t forget it.
- Okay, I promise this whole talk isn’t a motivational speech, so let’s get on to the meat of it.
- We’re going to go over everything about the technical interview - how to prepare, what to expect during the interview, and what to do afterwards. Let’s talk preparation first.
- The first step is to schedule it! After graduation, it’s likely that you’ll be juggling multiple interviews - it can be quite a whirlwind. Be sure to space them out appropriately. Technical interviews can be mentally tiring, so make sure you don’t schedule too many in a day and space them out. Related (and somewhat contrary) to that, schedule every interview you can get. Practice makes perfect as they say! Also, the company should let you know who you’re interviewing with, how long it will be for, what the interview will entail and any specific requirements, like should you be online, what text editor you’ll be using, what language, etc. If they don’t offer this up, just ask!
- Know the company. Some/most of your company-related questions should have been answered in the introductory phone screen. It’s always good to check twitter feeds, recent press releases, crunchbase to get familiar with the founder names and funding rounds. Check out the team page. Know your interviewer. Take a quick look on LI, github, twitter, personal blog/website. Try to get an overall feel for the person and bonus if you find any common interests. Look through their code on github, find an interesting article they read or posted on twitter. It can make for interesting banter in the interview and show the interviewer that you’re prepared.
- As part of research, make sure you have questions for the interviewer. You’re going to be talking to an engineer so this a golden opportunity to ask more detailed and pertinent questions to you. What does a typical day look like? (standup?, sprints?) How do features get prioritized and worked on? (product manager?) Tell me about the most interesting thing technically you’ve worked on. What’s the interaction level between team members? What do you enjoy about working at XYZ the most? (food? technical challenge? impact?, team?)
- I can’t stress this enough. Technical interviews are an unfamiliar setting. Partner up with a peer, go through technical questions online, take every interview. We’ll go into more specifics with this for each interview type later.
- Never take an interview from a coffee shop or huddled in your car hoping to catch wifi drifting out into the parking lot. Seems like common sense, but I’ve made that mistake before. You don’t want any distractions or hiccups, so make sure to be in a quiet place with good phone reception and usually great wifi.
- Often times, there will be some chit chat at the beginning of the call to introduce yourselves. When it’s your turn: Keep it to 5 minutes at the absolute maximum Do your best to not just recite what’s on your LinkedIn or resume - the interviewer should already be familiar with that stuff. Geek out a bit. Talk about what was exciting in your previous experience. Don’t talk about the features you implemented or what the product could do. Talk about what you’re excited about getting into next (and relate it to the company) (“I’m hoping to take my experience so far, join a small but experienced team with strong developers, so that I can continue growing and learning”) Don’t: I implemented AR Lite which supported select, where and join. Do: My favorite part about that project was that we were able to achieve 100% test coverage and I got to dive into some of ruby’s internals like define_method and include/exclude.
- Your knowledge is going to be pushed to the limit (if the interviewer is good). This is not because the interviewer wants to make you feel stupid (hopefully) rather wants to test your boundaries. Don't fret if you don't know everything or flub up here and there. It’s okay, the interviewer usually isn’t looking for perfection. So try to keep that in mind.
- Ask your questions that you prepped. Find out what the next steps are. Get a commitment around who you should be hearing back from and by when.
- Try to send a follow up note within a few hours or by end of day. Thank the interviewer for the discussion and take the opportunity to reiterate your enthusiasm for joining company.
- It happens - don’t beat yourself up too much. But not all is lost. Make it clear to the interviewer that you can do better. If it was a coding exercise and you didn’t finish it - finish it. Ask for another type of technical interview - John O example with code challenge. If you really are that enthusiastic and you just had a bad day, that enthusiasm can go a very long way.
- If for some reason you haven’t heard back with next steps in the amount of time you expected. Definitely send a second followup. Use it as another opportunity to show your enthusiasm.
- Knowledge based questions - coding syntax, language features, design patterns, database apis
- Interviewers use this to get a general handle on your experience. You’re not going to know every answer and interviewers aren’t looking for straight definitions/explanations. Feel free to use your experience as an example to explain something. “In one of my apps, I used a polymorphism to allow photos to be attached to users and posts.” Don’t guess! It’s definitely better to just say, that you’ve heard of it but don’t quite remember what it is. A great answer is, “I don’t think I’ve used that in practice and don’t remember the definition, but I remember reading about it on a blog a ways back - it sounded pretty cool.” There’s no magic bullet to these, but they shouldn’t hold much weight. Especially for folks just jumping out of App Academy. Keep coding and gaining experience. You can also check out smarterer.com
- experience based questions - deeper dive into more interesting technical points on your resume
- Be prepared to talk about items on your resume. Interviewers will usually pick out a couple of the more interesting technical things on your resume to explore more. What was your role? Did you consider other alternatives? What were the performance/business gains? What was the most difficult part?
- design questions - how do you design complicated systems into smaller parts? How do you structure classes? How would pick a database? This is a lot of what we do day to day. You’ve probably heard the saying that the top coders are 10x faster than everyone else. This isn’t because they’re geniuses or because they type really fast. It’s because they know how to design. A simple, easily maintainable system creates that 10x productivity.
- Ask questions. Talk out loud with possible solutions. Weigh pros and cons. Relate your experience. Take baby steps.
- remote, collaborative coding exercises: work on a simple coding problem, can be practical or algorithmic. Now that there are a few good choices for online collaborative code editors, these are becoming more and more popular. It comes closest to what we actually do as coders day to day - code! So it’s a good measure.
- The interviewer is trying to get a gauge on your coding and problem solving chops. Ask questions. Talk out loud (consider all ways of solving it, edge cases). Take baby steps. Prepare for these at interviewcake.com or Gayle’s book. Practice coding in the online editors - get familiar with their interfaces. Practice!
- Take home challenges - Can range from 1-4 hours or more. Sometimes “closed book”. Usually more challenging but a lot of fun! You’ll usually discuss your solution in the phone interview.
- put it on github create a well written, detailed read add tests phone interview: be prepared to explain your solution, talk about alternative solutions you considered, what you think you could still improve
- general resources
- knowledge based question practice
- fun, algorithmic info and practice
- Up until now, we’ve been talking somewhat generically, but now I want to be a little more specific and subjective. how to ace an interview - well at least with chris conley Our technical phone interview is a remote pairing session that usually lasts ~45 minutes using coderpad.io or code bunk.com. We start with summing a file, write some tests for it, and eventually get to an algorithm problem using TDD.
- I’ll be sending a link to the video later tonight or tomorrow morning to the group via Simon/Laura. If you enjoyed this talk and think others might benefit from the content, I’d love for you to share it on twitter/facebook etc. If you hated this talk and think it provides absolutely no benefit to anyone, anywhere, BUT you’d like a practice interview with myself on our actual interview that we use everyday including detailed feedback, I’d also love for you to share it. :) Tomorrow, I’ll randomly select three folks that fit into one of those two buckets to do a practice interview.
- To that end, during this talk we’ll go over the actual interview - how to prepare, how to handle the actual interview and what to do afterwards. After that, we’ll go through a few different types of technical phone interviews with examples of each. Finally, we’ll wrap up with tips and resources to follow up on.