# 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.