Does anyone have tips on the type of questions (and rough analogues to Leetcode difficulties) I might expect to see in the first phone interview? Each day, my approach is to quickly solve a few easy Leetcodes first (to prepare for answering the initial easy softball question quickly), before tackling 1-2 medium difficulty questions. This is in addition to normal algorithm and data structure prep. Any advice is welcome!
I feel like I had the same interviewer as Neo. I had one interview of the 5 where I just got stuck on a dumb question. I had said I was going to start with the simple solution but the interviewer pushed me to think about it and try for a better one. Later I became convinced in that case the simplest solution was on average time pretty much the best. Anyway never got to the second question but he did ask me if I had questions in a completely nonchalant manner after that one. Oh well.
Completely agree with what jneo said. I had similar experience.. two attempts at Google. First time.. didn't do leetcode .. mainly prepared for design interview.. was over confident. In telephonic, they asked.. 1. Imagine you have a on screen keyboard. Where alphabets are arranged sequentially in a m X n matrix. Your TV remote has keys to traverse the matrix left right up down, and ok. Write program that prints the seq of l,r,u,d,ok to type a given input string. I spent more time taking about a parallel solution using divide and conquer and parallel function application to immutable substrings in original string. Talked about how you would do this in oop in java vs functional in Scala . Interviewer was only interested in working code. I was rejected. Tried again after one year, this time with leetcode practice I could write a solution simple quickly and then talk about improving it. Got on-site invite and eventually an offer. The thing about leetcode is that it looks very challenging at first when you browse through it and directly look at medium or hard problems. That's like looking at the general theory of relatively or Schrodinger's wave equation without learning calculus first. You need to first get very good at the basic algos.. Bfs, dfs, hash maps, trees, heaps, priority queues.. , sliding window, max , min , mean of lists, quick sort and merge sort, min and Max heaps, djkistragy, topological sort, clustering, adjacency list vs adjacency matrix representation, .. maybe kmeans if u want to practice more. Implement all of them even if you think you know them. Doing one algo will make it much easier to understand the other .. many of these ideas build upon themselves. If you have time then maybe dynamic programming sample problems and backtracking basics. Once you cover these basics and refresh your memory about the basics.. then approach leetcode easy and medium. You will then realize that those questions are just a variation on using these basic algos. You just need to look at those 100 or so variations and just familiarize yourself with the specific question category. Once you cover the basics, the leetcode medium will feel like easy. The problem is, that this is not new information. I felt that there are a lot of kids in college who gave figured that doing great at leetcode gives you good advantage at first stage of interview. So all they do is leetcode. They do great at first time but mess up in design rounds later. But their wonderful performance at screening makes it difficult for a experienced dev who might go great at design.. but hasn't prepared and memorized the basic algos recently.
This is the new Cracking the Google Interview. For my T5 SWE phone screen: 1) Compare and contrast hash sets and trees. Okay, sounds great. 2) Now, write a function to find the most common character in a string. (You can guess this builds from what I said about hash sets in #1, which I point out.) 3) Let’s now imagine that this feature is needed for huge strings and you have a quad core. Talk about a solution. 4) Imagine that this feature needs to work on a massive file available on a shared drive. Talk about a solution. In summary, don’t waste your time on Leetcode hards. A better use of your time is to get faster at the easy and mediums. This is also how my on-site worked out: my three coding problems were pretty easy but I had to get through them quickly to reach the scaling follow ups. So speed and clean coding of easier problems is more important than putting you on the spot to crack a puzzle.
Excellent, thanks for the advice! Did you get an offer?
No, I likely failed by not following my own advice. If you spend too much time on the coding, the interviewer will be really nice and chill and ask you if you have any questions — rather than proceeding to the follow ups. This means you’ve failed. As for the design rounds, I think I did well on each of the 2, but it took me iterations to refine. Google would rather you get it mostly right the first time. I eventually do, but I take too long. Slowness is no longer acceptable with engineers, which is why it’s now so hard to get the better jobs. But at least I can say that everything asked of me at the Google on-site was fair. I cannot say that they jerked me around at all. If being a bit slow, overthinking things, and being iterative is problematic, then this format makes that easy to assess. It’s also the reason why it’s getting harder to stay in the game as I age: I tend to overthink and assume something is harder than it appears. It’s not that my skills aren’t current, I just think too damn much. So at the end of the day I did not deserve the offer, although I’m smart, productive, and way more well-rounded than your typical geek engineer. If I had the same interview content with 90 minutes each rather than 60, I could be awesome. But attention spans are shorter and more efficiency is needed. That’s why I say that SDEs at Amazon are not that much different from FC associates.