Years ago, when I was in college and decently good at competitive programming, I applied for a Google internship and was confident of decimating the interviews — given how well I knew the basic as well as advanced algorithms and data structures — and my cracking coding speed which produced bug free code (mostly). I remember the interviewer asking me a question about substring matching, which turned out to be a piece of cake with a custom string hashing function and a hashmap. I was done within half an hour and went to sleep imagining if Google internship would be as fun as they say — team outings, free food, schwag etc.
A few days later, I got a rejection email. And then I went and talked to my college seniors about what had really happened. I had totally misunderstood the objective of the interview. I had displayed skills that are relevant to ACM ICPC and CF online judges, but not to human beings. I had displayed only a subset of skills that are required to be a good software engineer (debatable, but at least that's how the interview process goes).
I've interviewed hundreds of candidates at my time at Google — many of them rated highly on various coding platforms — but lacking the basic style of a conversation that could convince me to work with them. It's disappointing to see the lack of some basic guidance, given how much these folks can achieve.
For the same reasons, I've started with an initiative which this community may find useful. It's a #WeeklyCodingInterview series, where I post a typical, but unique, interview question, along with follow ups, that folks can try for a week. At the end of the week, on my Youtube channel I provide the fundamental approaches to not only the problem, but also the whole topic, along with interviewer insights such as — how to approach, what are the common mistakes, how to communicate, what is the hiring bar at Google, etc.
Hope the community would find it useful.
Inverting the question: do you think it is a good practice to reject candidates that you explicitly recognized to be good, because they lacked guidance in interview speech?
It's a hard call, for sure — but there's always some ambiguity wrt what candidate could or couldn't achieve with guidance. Hiring decisions need to be objective in that moment; and there's no easy way to align ten people based on my personal intuition — it needs to be backed by evidence.
Don't you think that such a problem isn't a good way to align candidates by evidence? How many times have you used dynamic programming or the knapsack problem in your SE experience? You wrote about showing skills that are required to be a good software engineer, but later it looks more like skills of passing specific interviews and knowledge of some specific CP topics.
And the issue is not only that highly rated coder can fail your interview, but even some good candidate, which is a real skillful software engineer with huge background, will fail it without additional preparation and not knowing exactly what you want from him.
You raise a good point indeed — and I agree with you, to an extent.
In my opinion, there's no denying that algorithms, data structures and programming constructs are indeed the fundamentals of computer science; and even though there's no direct correlation between software engineering work that you end up doing after being hired, this is the state of fresh graduates software engineering interviews as of today. In some sense, it serves a proxy for aptitude, communication and comprehension skills, and basic understanding of abstractions. Also, the experienced engineers are not just evaluated on fundamentals, but other skills such as design, interpersonal skills etc.
There are innovative ways of hiring engineers, and the industry may be ripe for that kind of disruption — but it'll take a long time. I'm sure it's on the top of mind of many problem solvers.
Thanks a ton for this content! Loved the "Baker" analogy XD, Definitely looking forward to your future videos!
How many interviews per week do you usually conduct? This "hundreds" sounds like a surprisingly large number based on how long you've been working at Google.
Out of curiosity — where do you take them from? Are you coming up with the problems by yourself, or do you take some already leaked&banned questions from real Google interviews, or do you use some other source?
At the peak I was doing 2-3 per week, but stopped after a while. Maybe I'll resume after we can conduct onsite interviews again. Phone/call interviews is really not what I enjoy. I can't say the exact number here, but I meant O(100) (call it a marketing gimmick :)), including other mocks interviews I've done for interns at Google (not official ones).
These are my own questions, but there can always be coincidences, as we often see across many contests. CPers may find some of them standard, to be honest — but I err on the side of covering the fundamental technique, even if it ends being a standard/easier problem.