C++ Interview with a Google Engineer

Watch someone solve the alien dictionary 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.

Interview Summary

Problem type
Alien Dictionary
Interview question
Given a list of lists in a lexicongraphic ordering, return the ordering of the characters in the language.

Interview Feedback

Feedback about Teflon Artichoke (the interviewee)
Advance this person to the next round?
Yes
How were their technical skills?
3/4
How was their problem solving ability?
4/4
What about their communication ability?
2/4

I will write interview feedback here as if I were interviewing a real candidate. (The rubric is generally: <2.6- strong no 2.6-2.7 - no 2.8-2.9 - weak no 3.0-3.1 - weak yes 3.2 - 3.4 - yes 3.5+ - strong yes) A candidate will usually receive a passing score (3.0+) if they get a working solution by the end of the time period (excluding any extensions)

Overall: [3.2/4.0]
Problem solving: [0.8/1.0] - Candidate has seen the question before, but I asked candidate to solve anyways. He had a solid foundation on the DFS variant of topological sort, and had good explanations for me when I had prodding/followup questions to his code. He clearly understands the problem as well as the code he writes. (I suggest looking into Khan's algorithm for topological sort as well, I personally find it easier to reason about). Unfortunately, we did not have time to get into extension questions, which would have been helpful for me to better evaluate his problem solving skills for questions he had NOT seen before.
Coding: [1.5/2.0] - Candidate wrote correct code, and was able to translate his thoughts to code fairly easily. His code was nearly bug-free, which I found to be impressive. I also really liked how the candidate broke up the code into easily digestible (and testable!) functions, which helps keep things organized. The points I took off were for code speed and execution - I would expect that a candidate who is familiar with the problem can code it up very quickly, but getting a working solution took the full hour. However, I will note that I think the candidate has a lot of potential to code much faster - it seemed that the majority of the time spent was on explanations and talking through the code. I think if this part can be cut down (via more succinct summaries before and after coding), then there is a lot of room to gain points back here. Misc: [0.9/1.0] - Candidate was friendly and personable, as well was easy to talk to. Communication during the coding portion could have been more focused, however, which would have both saved time as well as offered more clarity in the candidate's thought process. I liked how the candidate brought up edge cases in advance and had a test-oriented mindset. In general, I would be happy to work alongside this candidate!

Summary of feedback/things to work on:

1. I would say the candidate's coding correctness is very good, the main area of focus is communication.

• Good to explain thought process, check in with interviewer, then code, then check in with interviewer.
• No need to spend lots of time on brute force solution/time complexity unless interviewer specifically asks you for more elaboration. Can be good to check in with interviewer whether they want you to go into this before you jump into your explanations.

2. Coding speed

• Again, probably related to 1., but writing code faster would be helpful.
• You can do with fewer comments/pseudocode. (feel free to keep it if it helps you stay organized however!)
• In exchange, you can talk out your plans with your interviewer if it is faster, and once the interviewer agrees with your thought process you are good to go!
• Python could also be another way to help this as well

Overall good job! And good luck with your upcoming interviews - you got this!