Nathan Wailes - Blog - GitHub - LinkedIn - Patreon - Reddit - Stack Overflow - Twitter - YouTube

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 56 Next »

Related pages

Non-algorithm-specific interview advice

Algorithms

A step-by-step process for solving algorithm questions

  1. Draw out a simple visual example.

    1. Do it in something like Balsamiq.

    2. Copy-paste it to visually show what the step-by-step process should look like.

    3. Think about what variables you want at each step to answer the relevant question you have to be able to calculate the desired answer.

  2. Ask yourself: What features of the state of each ‘step’ through the input can you think of to assign names to? Write the code needed to calculate/update these values with each iteration (or just have them as stub functions to be filled in later) and it could give you enough of a step in the right direction for the rest of the solution to make itself clear.

How I study

  1. I have Neetcode questions in Anki.

  2. I track which questions I’ve actually studied by checking them off on the Neetcode website.

  3. I’m aiming to go through all questions of a type before moving onto the next type.

  4. Creating Replit versions:

    1. If I can’t access the question on Leetcode (it’s a premium question) or the Lintcode version (or if the Lintcode version is too different from the Leetcode question), I can create a Replit version in here.

    2. Make the ‘template’ version of the question, then when you actually want to do the question, use that same Replit and you can just use the git feature to discard all of the changes you made to the code when you’re done.

Data structures

Questions

  • What is the threshold at which point it's a good idea to create a class for a data structure?

Algorithms-Specific Informational Websites (not programming challenge websites)

Books

Articles

  • http://haseebq.com/how-to-break-into-tech-job-hunting-and-interviews/

    • First, a high-level roadmap.

      Watch the Princeton Coursera course on algorithms (by Robert Sedgewick), mostly up until Dijkstra’s algorithm and not much more than that. Try to follow along and code as you go. You don’t need to implement things in Java unless you already know Java.

      Read The Algorithm Design Manual for general algorithms and data structures background. Go through most of it. (You can skip the giant appendix about specific algorithmic topics).

      Buy Cracking the Coding Interview. We’ll be using this as a repository of coding problems and solutions.

      (...)

      If you’re working on an algorithms problem (such as out of CTCI) and can’t figure it out, spend no more than 20-30 minutes without making progress. Just go look up the answer. Contrary to popular belief, most struggling past 30 minutes is pointless.

      Some people will disagree with this. [NW: Like Tom and Chris Uga.]

      Screw those people.

      That said, if you find up having to look up the answer to more than 2/3rds of problems, your problem set is too hard and you need to downgrade.

      But banging your head against a wall or staring blankly at code is a waste of time. For code/algorithms problems, you very much want to maximize the density of learning per hour.

      Any time you look up the answer to a coding problem, try to understand the solution. Walk through it with a debugger if it’s particularly mysterious. Read multiple explanations of why it works.

      Then—and this is extremely important—if you didn’t solve the problem completely on your own, treat the problem as though you never solved it at all. Put it back into your rotation of problems. Mark it as something you need to try again from scratch. Wait at least a day, and try to solve it fresh. If you fail, rinse and repeat ad infinitum.

      And finally, structure the hell out of your learning. Make a schedule. Know exactly when you’re going to be working on this stuff, when you’re going to take breaks, when you’re going to go to lunch, etc. Build flexibility into your schedule, but have clear goals for how many hours a day you’ll spend studying.

Interview Challenge sites

Front-end interview challenge / prep sites

Interview Prep sites

Non-Interview-Prep Challenge sites

Topics

Linked Lists

Databases

Dynamic Programming (DP)

Heaps

Recursion

Trees

Binary Trees

The interview process

Flashcards


  • The stages of understanding: (think about it as high-level vs. low-level understanding, or broad vs. deep understanding)

    1. Broad / High-level: Recognition of terms / basic understanding of definitions

    2. High / Mid-level Knowing when to use a particular tool

    3. Mid/Low-level: Knowing how to do something

    4. Deep / Low-level: Knowing about tricky things / edge cases / less-common problems


  • Algorithms

    • Testing recognition / basic understanding

      • What does "BFS" stand for?

        • Acronym used in IK

    • Give an example of an O(X) algorithm.  ← See 'The Pragmatic Programmer' for examples.

      • Give an example of an O(1) algorithm.

      • Give an example of an O(lg(n)) algorithm.

        • "Binary search of a sorted list, traversing a binary tree, and finding the first set bit in a machine word(?)."

      • Give an example of an O(n) algorithm.

        • Exhaustive searches, finding the maximum value in an array, and generating checksums.

      • Give an example of an O(m * n) algorithm.

        • "This commonly occurs in simple sorting algorithms, such as bubble sort, where the outer loop scans each element in the array in turn, and the inner loop works out where to place that element in the sorted result."

      • Give an example of an O(n*lg(n)) algorithm.

        • Quicksort

      • Give an example of an O(n^2) algorithm.

      • Give an example of an O(n^3) algorithm.

      • Give an example of an O(2^n) algorithm.

      • Give an example of an O(n!) algorithm.

        • "Whenever algorithms start looking at the permutations of things, their running times may get out of hand. (...) Examples include algorithms for many of the acknowledged 'hard' problems–the traveling salesman problem, optimally packing things into a container, partitioning a set of numbers so that each set has the same total, and so on. Often, heuristics are used to reduce the running times of these types of algorithms in particular problem domains."

  • Arrays and other Ad-hoc problems

  • Concurrency

  • Dynamic Programming

  • Graphs and other Data Structures

  • Group coding mocks

  • Group mocks on Concurrency

  • Group mocks on Object Modeling

  • Group mocks on Scalable Systems

  • Linked Lists, Stacks, and Queues

  • Object Modeling

  • Orientation + Behavioral

  • Recursion

  • Scalable Systems

  • Sorting

  • Strings

  • Trees

    • Done - K-ary tree

      • Used in IK

    • BST

      • Used in IK

System Design

Step-by-step process

  1. Clarify the task.

    1. Share what you know about the system with the interviewer.

    2. If you’re not familiar with the system, tell the interviewer so they can explain how it should work.

    3. Constrain the problem to make it solvable within the hour.

  2. Clarify the scale of usage, the amount of data involved, the rate of requests.

    1. Specify some key metrics to help your high-level decision-making.

      1. Example: the number of users, the amount of data.

    2. You don’t necessarily have to go into the details of scaling at this point.

  3. Design the system at a high level.

    1. At an early stage, it’s OK to have a few simple components; later on you can get more complex.

    2. Example:

      1. If asked to design Spotify, you could draw a mobile app connected to a load balancer which connects to a group of webservers, which connect to the database.

  4. Outline your database design.

    1. After laying out your components, design your database.

    2. Split out databases appropriate for different types of data.

    3. In general, try to explain why you’re doing something upfront rather than waiting for your interviewer to ask you.

  5. Go through particular use-cases and explain how it will work.

    1. Consider how the webservers will retrieve data from the db and how they’ll send it to the end-user; will they use websockets?

Learning resources

Designing Data-Intensive Applications

IGotAnOffer

  • System Design Interviews: 10 Key Principles (with ex-Google EM)

    • Communicate efficiently.

      • The interview is definitely an artificially time-constrained environment.

      • So you need to be efficient. You don’t want the interviewer wondering what you’re thinking. You want the interviewer to be able to follow your thinking.

      • They work with a lot of engineers who understand the technical part but struggle to clearly communicate what they’re thinking.

    • Scope the problem.

      • Real systems (like YouTube) are too complicated to fully design in a one-hour interview.

      • So you need to ask, “Which part of the app/feature-set should I focus on?”

      • You need to go along with what the interviewer wants to focus on.

    • Start drawing ~15 minutes in

      • This isn’t a hard number, it’s just a guideline.

      • If you start drawing too soon, you may not fully understand what the interviewer wants you to focus on, and start going down a wrong path.

      • If you wait too long, you may not have enough time to come up with a working solution.

      • The interviewer says that in one mock the Google EM didn’t start until 20 minutes in and would’ve been struggling to finish.

    • Start with a simple design

      • Don’t add requirements that don’t exist.

        • Example: Adding tiering storage could prevent you from having a complete solution by the end of the interviewer.

      • You can tell the interviewer that a particular optimization is available and how you’d use it, but don’t let it stop you.

      • If the interviewer asks you to go deeper on a subject, follow their lead.

    • Use prep resources

      • GitHub has a system design study guide, for example

      • You might see some differences across guides

    • Properly understand the problem

      • Talk through specific use cases.

      • Imagine actually calling the API.

      • Try to catch assumptions you may have made.

      • Check in with the interviewer to see if you’re on the right path.

      • He mentions the name of the doc used for a full spec is “PRD” - Product Requirements Document

    • Practice, practice, practice!

System Design Primer

Articles / Forum posts

Topics

  • No labels

Follow me on Twitter