13 ms·

To reiterate: Ignore all study materials. Go to leetcode.com and literally memorize the most common questions for the company you are interviewing at. This is

• neilv 3y ago
  Is it too much to hope that those companies will all go out of business, and every person who was a part of creating this ridiculous theatre will be bankrupted?
• CalRobert 3y ago
  This is true. And it's a bit frustrating because I have to take care of two young children when I'm off work, not grind leetcode. But maybe that's the point.
  • ldjkfkdsjnv 3y ago
    Its not as bad once you accept its memorization, and treat it like that.
    • airstrike 3y ago
      Sadly not everyone is equally adept at memorization, so if you're solving for that as a hiring manager, you will only (mostly) appeal to this subset of people
      • otteromkram 3y ago
        Then they're probably not a good candidate for a high-paying, high-expectations job. Thank you for pointing that out.
        • airstrike 3y ago
          > Then they're probably not a good candidate for a high-paying, high-expectations job. [Citation needed] Memorization isn't the one variable we should be solving for. God forbid people take notes in meetings as opposed to remembering every word that was said
        • spike021 3y ago
          By your logic every software engineer job across the entire org at a company like Google/Amazon/Meta have the same requirements, exact same problems, etc.
  • khzw8yyy 3y ago
    This is absolutely the point. All these interviews are checking is "does this person spend all of their free time on a task we assign to them, no matter how boring". Or, "do they go above and beyond".
  • deleted 3y ago
    [deleted]
• Palmik 3y ago
  For many, it's much easier to understand than it is to memorize.
  • deleted 3y ago
    [deleted]
• deleted 3y ago
  [deleted]
• deleted 3y ago
  [deleted]
• paulddraper 3y ago
  Someone is going to take you seriously. Don't memorize it, learn it, become good at it. No matter how much you memorize, there's going to be something you don't. But I think you know that.
  • ldjkfkdsjnv 3y ago
    People need to know the truth that these "genius" engineers at Meta/FAANG are mostly getting in by memorizing. They try interviewing at five top companies. One of those interviews they will absolutely crush, and then will get an offer at 400k+.
    • paulddraper 3y ago
      When you say "memorize" what do you mean? You mean that they remember common patterns to solve problems? Or they memorize questions verbatim?
      • deleted 3y ago
        [deleted]
      • ldjkfkdsjnv 3y ago
        People are going on leetcode.com, they find the company they are interviewing for, they remove all questions more than a year or two old, then they sort by frequency. They start memorizing the most frequent questions first. Then they pass the interview. There are other forums with question banks, but I wont get into that
      • michaelt 3y ago
        For example, if asked "how would you detect a cycle in a linked list?" you might memorise "Tortoise and hare algorithm, two pointers one slow and one fast, fast overtaking slow indicates the presence of a cycle" A person with a deep passion for algorithms might be tempted to try to solve it themselves before checking the answer - which can be a time consuming business. Time your competitors have used to memorised the answers to 25 more questions. ldjkfkdsjnv has exaggerated a bit, to be provocative - but I've certainly had interviewers ask me questions that stumped the greatest minds in computer science for 25+ years; I don't know what they were expecting if not memorisation.
• guessmyname 3y ago
  The interviews I had at Apple were surprisingly straightforward compared to those at many other tech companies. I didn’t find the need to memorize anything, in part because I knew the concepts they were questioning me about after putting them in practice during the last decade of work, but also because the questions were quite straightforward, almost akin to general knowledge, for example: • What is an SSL certificate? Follow up question: What is inside them? • How would you go about designing a modern NTP to sync a fleet of local-first systems? • Do you see a security problem with this code? If yes, what is it and how would you fix it? • Same question as above but with twelve different pieces of code, each one more complicated than the previous one. • What would you consider Personal Identifying Information (PII) in a food delivery app? • Explain XSS, SQL, XSRF… • Hashing vs. Encryption • How to protect customers from phishing attacks? • Say you discover a data leak, for example, a backup in a public S3 bucket. Communicate leak or not? If yes, who will you communicate with? How will you communicate? • Improve event processing logic and performance of the following Java application. Our company revolves around processing events, quickly. Implement the alarm system to monitor incoming events for any delays in processing events by other event processors. (If you find it surprising that Apple uses Java, I share that sentiment. Interestingly, I opted for Go instead of Java to solve the problem during the interview, and the interviewers were pleased to explore a new programming language. I believe this aspect earned me some additional points.) • Design a table booking system for a restaurant (database, API endpoints, etc.) • A continuous integration (CI) build step fails (in tests), what do you do? • What is your ideal Developer→Customer feedback loop? Realistically, what would a bad one look like? • How would you design macOS Photos.app? (The best part of the interview was a discussion about what to do with content that is out of view and the performance implications of different solutions.) • Third-party company wants Apple’s data to show ads. What do you do? (The obvious answer is you don’t give the raw data to them, but if you have to, how do you anonymize it?) • so on and so forth. There was this interviewer who appeared to be commited to ask me one hundred questions in the span of an hour, and while I didn’t count, I think we got pretty close to a hundred. The questions started at an easy level, for example, what is HTML, and increased in complexity every five minutes or so. Fortunately, I realize what type of interview this was and proceeded to give very one-sentence answers, sometimes just 2-3 words before jumping to the next question. One of the funniest, craziest, most exhausting, but somehow rewarding interviews I have ever had in my whole career. At times I thought the interviewer was some sort of artificial intelligence and the webcam was fake. Later, I met the interviewer in person and we became friends. Now, having become an insider, I can attest that it’s acceptable to some extent to memorize responses for coding exercises and rehearse answers for behavioral questions. As you rightly point out, many other candidates engage in these practices as well. However, if a candidate’s proficiency is limited to merely regurgitating code without a genuine understanding and, consequently, an ability to articulate the underlying concepts in both the programming and behavioral interviews, that candidate is likely to face failure. Before landing the job at Apple, I was also in the interview process for a position at Microsoft. The nature of the work appeared to be significantly more fulfilling than what I currently have. The level of technical expertise required during the interviews was remarkable, with the two medium and hard level LeetCode-style questions being the relatively easier segment. Memorizing answers was technically impossible based on the interviewing style. I would have unquestionably accepted that job if it weren’t for the fact that I needed additional income to continue providing for my extended family and covering my mortgage. In conclusion, if you decide to memorize LeetCode problems, ensure that you also grasp the underlying concepts. Unless all your interviewers are gullible, it will become quite apparent if you're just mechanically writing code without a genuine understanding of the problem or the interview's objectives.
• krooj 3y ago
  If you do this and I am the one interviewing you, I will fail you. I will figure out what you actually do/don't know and if you are incapable of performing at the applied level, I will fail you.
  • ldjkfkdsjnv 3y ago
    Thats fine, but the majority of engineers at Meta/Google will be impressed
    • davely 3y ago
      This needs a [citation needed] sort of flag.
  • bee_rider 3y ago
    I think the strategy they are describing is to just memorize a bunch of stuff, and then interview until an interviewer happens to not catch on. Either they’ll get someone less prudent than you, or, I mean, you can’t possibly test everything, right? I have no idea if this really works though, it seems insanely tedious and also there aren’t that many companies to roll the dice at.
• vjerancrnjak 3y ago
  I recently stumbled upon an interviewer that asks "what will happen to this algorithm if I delete these 2 lines of code?" (the interviewee is the author) and deletes happen on simple if-else condition that maintains useful invariants and the interviewer said it eliminates most candidates. I guess that's how memorization works.
  • ldjkfkdsjnv 3y ago
    I'm telling you, most candidates at Meta that got in and are making 400k+ sat in a room and memorized question by question. People need to know how they are getting hired. They are MEMORIZING the question bank.
    • deleted 3y ago
      [deleted]
    • _dark_matter_ 3y ago
      This happened to me for meta. Saw the qs on Glassdoor, memorized, and passed with flying colors. Did not take the job. I was astounded that they asked the same question, word for word.
      • ldjkfkdsjnv 3y ago
        Yeah its appalling the general software engineering population doesnt know this yet
    • Der_Einzige 3y ago
      Most of them cheated, they didn’t actually memorize all that leetcode. Ive personally witnessed candidates at my own university successfully cheat on FAANg interviews which later landed them successful jobs/internehips
      • jdthedisciple 3y ago
        How can you chat in an (in person, I assume) interview??
• Denzel 3y ago
  While this advice may work for some FAANG companies, I can assure you this won’t work for Google, especially at higher levels. You won’t find their questions in any public test bank online (trust me, I searched after my interviews). Also, a good system design interview isn’t about designing a “perfect” system (hint: there isn’t one), it’s about defending a reasonably considered design. Google’s system design interview very closely approximates my day-to-day experience designing solutions with my teammates.
  • rendaw 3y ago
    To be clear, GP didn't mention designing a perfect system but providing perfect answers, which probably includes mentioning tradeoffs or being prepared to answer questions about them.
  • ldjkfkdsjnv 3y ago
    Google I have heard is a bit tougher. No worries, theres ten other companies that just want memorization that pay better than google.
  • robbyt 3y ago
    At most of the companies I’ve interviewed at (except Google as you note), the hiring manager and principal engineer didn’t understand system design themselves. They only understood how to pattern match against a regurgitated answer. Case in point, when asked how I’d build Slack, I spent most of the time on data persistence because slack stores all data forever even on the free plan. I got rejected because, “we don’t care how they store data.” Ok, but that’s still a key part of the system design…
    • nostrebored 3y ago
      Very open ended question that requires clarification. Interviewing is about asking questions too.
      • robbyt 3y ago
        Of course, it was a conversation and the engineer was happy to let me go in depth on storage after we discussed and dismissed other areas, like the front end, integrations, native apps which were not related to infrastructure. We also covered other areas like messaging, authentication, authorization, read / write paths, etc… so it was very strange to get the response from the senior manager I got.
• deleted 3y ago
  [deleted]
• deleted 3y ago
  [deleted]
• oooyay 3y ago
  I don't think this is very good advice. Enough of the companies that believe in testing by algorithms are smart enough to change their questions slightly for each candidate. I'm not sure, however, what if anything testing by algorithms proves. Sure, you should know how and when to use them like I know how and when to use different blades of a saw. Nobody has ever asked me to tell them how the saw gets made though. The things that matter to me as a Senior+ engineer these days are: - Do you know how and when to use various algorithms - Are you going to conform to a given code bases styling and standards - Do you know how to properly test a given piece of functionality - Do you know how to interrogate the debugger to find answers to your own questions - Do you know commonly accepted standards and where to find them - Are you going to over engineer and completely pollute the code base with unmaintainable code or infrastructure Algorithms and systems design test for only one of the above. If we ever get a tech union algorithm interviews are on a top five of things I'd like them to do away with.
• synaesthesisx 3y ago
  A former colleague of mine is at Meta thanks to this exact strategy. There are also apparently leaked question banks available to facilitate the process!
• haskellandchill 3y ago
  I've been compiling lists from interview experiences and there aren't many repeated problems. I don't think this advice scales. However, I haven't seen any material that will teach you how to come up with the trick to cracking a problem you've never seen before. The best approach seems to be learn patterns and if you're stuck ask for hints. Doing mock interviews to get used to the format is also very helpful.
• eclectic29 3y ago
  I mean you still need to learn the material but you cannot pass these interviews without memorizing.
• nisowa 3y ago
  It is unfortunate that the situation has come to this for hiring in the tech industry but it is the reality. Success in interviews often stems from a combination of preparation methods and understanding deeply what you're being interviewed for. With Onsites.fyi, our goal is to provide those insights and data points so you can prioritize those high-impact topics and focus on deeply learning the material rather than an aimless review of everything. This is the key to standing out in today's competitive job market.