We helped write the sequel to "Cracking the Coding Interview". [Read 9 chapters for free →](https://bctci.co/free-chapters) Please read our [definitive guide on Google's hiring process and questions](/content/guides/hiring-process/google/index.html) # JavaScript Interview with a Google engineer #### Watch someone solve the simplified blackjack problem in an interview with a Google engineer and see the feedback their interviewer left them. Explore this problem and others in our library of interview replays. Simplified Blackjack: JavaScript Interview with a Google Engineer - YouTube [Simplified Blackjack: JavaScript Interview with a Google Engineer](https://www.youtube.com/watch?v=oJNWwNfOvXE) ### Interview Summary #### Problem type Simplified Blackjack #### Interview question Consider a simplified game of blackjack, with an infinite deck of cards labeled 1-10. That means there is always a 10% chance to draw any card value regardless of what's been drawn before. Duplicates allowed. The dealer always plays deterministically, according to the following rules: - If the dealer's total is less than 17, the dealer draws another card. - If the dealer's total is at least 17, but not more than 21, the dealer stands. - If the dealer's total is over 21 the dealer "busts" and therefore loses. Determine the number of ways the dealer can bust. ### Interview Feedback #### Feedback about Blue Panda (the interviewee) Advance this person to the next round? **Yes** How were their technical skills? **4/4** How was their problem solving ability? **3/4** What about their communication ability? **4/4** > Hey Blue Panda (great name, btw) aka Shazim, hoping the interview was insightful for you. It was nice to meet with you! You did well in this interview and would have cleared the hiring bar for this interview assuming this was for an onsite interview. You started around the 5 minute mark, and finished the question around the 23 minute mark, which means it barely took you 18 minutes to solve the problem. You optimized the algorithm by realizing we could memoize answers. That took you another 10 minutes or so as well. I’m happy to say that your time management skills in this section were optimal. > Good time/space complexity analysis. I think you could have come to some of the conclusions a little faster, but you were very clear in your thought process and ultimately correct. Saying time/space is constant is absolutely right even though it makes me chuckle. It’s true, but not particularly useful in our analysis phase of the problem. Still, your complexity analysis was spot on, and the only complaint I have is that you needed to be prompted to give it. Keep in mind that time/space complexity is basically the point of the interviews since the point revolves around optimal code. While your analysis was good, you shouldn’t have to be prompted to talk about something so fundamental – be sure to bring it up next time on your own! This is arguably one of the most important pieces of feedback to remember from this interview. > Besides interview pacing, it’s important to talk about the general structure of the interview. The general flow and process of the interview was correct and I think this is partially what helped with your pacing. > Since you coded the interview in JavaScript, it’s worthwhile to spend a second talking about your knowledge of the language. Thankfully your grasp on this language appears to be strong and more than adequate for interviews. You showed strong general software engineering abilities and great overall code hygiene. > Some minor comments and/or nits: > - Loved the template you pasted in! Great clarifying questions. > - You can have edge cases even without inputs. Edge cases might be a bad word. Assumptions is a better one. > - Hard to hear you a bit. Is it your mic? You talk fast. Are you mumbling? Hard to tell > - Don’t have to do it randomly. Great clarification. > - ES5 function not ES6, why? ES6 came out in 2015 > Next Steps: > ============== > Follow this process: > 1. Read question > 2. Ask clarifying questions and test your assumptions about the problem inputs/expected outputs > 3. Discuss logic & mention complexities > 4. Get buy-in from your interviewer to confirm they like your approach (or re-think optimal solution) > 5. Write code > 6. Do a quick dry run > 7. Show confidence in your code and don’t agonize once you’re pretty sure you’re done > 8. Just as a heads up, the platform asks if you’d like to connect with your interviewer, but for every interview I say “No.” This isn’t a reflection on you specifically. I’ve just had too many candidates stalk me on LinkedIn and reach out asking for private tutoring and/or referrals later after knowing my name. > 9. If you get a rejection, don’t stress about it too much. Remember that even if your interview was flawless, the acceptance rate is only 0.2% of candidates and you’re more likely to get into Harvard than pass. That isn’t necessarily on you either, so many other factors go into an interview that are outside of your control. If you don’t get into Google this time, try again! This isn’t your “one chance” and the average Googler tries 3x before getting in! > That’s the gist. You clearly are a good engineer that has written quality code before so you’re coming into these Google interviews with great momentum. DP algorithms are tricky! Hopefully, this feedback helps you. All the very best for your prep! Good luck on your onsite interview at Google! #### Feedback about The Mighty Anomaly (the interviewer) Would you want to work with this person? **Yes** How excited would you be to work with them? **4/4** How good were the questions? **4/4** How helpful was your interviewer in guiding you to the solution(s)? **4/4**