An Interview with a FAANG engineer

Interview Summary

Problem type

Job Scheduler

Interview feedback

Feedback about Hipster Samurai (the interviewee)

• Advance this person to the next round? Yes
• How were their technical skills? 4/4
• How was their problem-solving ability? 4/4
• What about their communication ability? 4/4

Strengths:

1. Gathering requirements
2. Brings up many good bells/whistles
3. Knowledge of specific systems of Kafka vs. RabbitMQ; consumer groups for worker farm
4. Brings up DockerHub/docker image

Areas of improvements:

1. Spend a bit of time on napkin math

Advice for future interviews:

1. Don't spend too much time designing bells/whistles to begin with; ask if it's the right thing to focus on

Feedback about Deliberate Alligator (the interviewer)

• Would you want to work with this person? Yes
• How excited would you be to work with them? 4/4
• How good were the questions? 4/4
• How helpful was your interviewer in guiding you to solution(s)? 4/4

General Comments: I am not sure. He's an incredible interviewer. I'm not sure what feedback I can even provide. This is also a guidance session on systems design so it's harder to provide feedback. I hope to schedule another interview but maybe a mock interview instance of a guidance interview.

Interview Transcript

Hipster Samurai: Hello?

Deliberate Alligator: Hey, can you hear me?

Hipster Samurai: Yes. Can you hear me?

... [truncated for brevity] ...

Deliberate Alligator: So I want us to design a Job Scheduler for our cloud service. And it'll be used by any customer in the world, so it'll be a public-facing service. And what I really want to have customers be able to do is they can specify a job. And a job is kind of any kind of code or algorithm that they want to upload. And I want them to be able to run that job either as a one-off. So kind of like a manual trigger or on a schedule.

Hipster Samurai: Okay, I'm going to write that out on a text file. Job scheduler, public-facing. I'm going to make these kind of like the functional requirements because my understanding of the first section is outline use cases and constraints to the system.

Deliberate Alligator: Yeah, I love that idea. Let's start off really simple and just say that the maximum execution time for a job is 24 hours. And if we have time at the end, we can design more of these bells and whistles.

Proposed System Design

• Components:

  • Load Balancer
  • Stateless API Gateway
  • Worker Farm
    • Database to track jobs
    • Communication Layer (Message Queue or Polling)
  • Scheduler

• Job Types:

  1. Immediate Execution (execute job)
  2. Future Scheduled Job (schedule job)

• Database Structure:

  • Job Table with:
    • Type (Repeating, One-off)
    • Execution Details
    • Status (Pending, Running, Completed)
    • User ID

• Scale:

  • 100,000 customers, each with the capacity to run 10 jobs/second

Considerations

• Performance: Ensuring rapid scheduling and execution while managing system loads effectively.
• Scalability: Implementing sharding based on user ID and potentially horizontal scaling for databases.
• Cost Management: Balancing the load without incurring excessive server costs, potentially optimizing migration strategies for jobs and data.
• Job Isolation: Ensuring that jobs execute independently without interference.

Conclusion

The design can cater to extensive user needs efficiently by combining the flexibility of job scheduling with robust architectural components, ensuring both functionality and performance are prioritized.

Overall feedback: Focus on core components during interviews and clarify the details of distributed systems to effectively manage expectations.