Arista Networks interview questions & answers

Model answer

Situation

At a previous company, I was responsible for diagnosing a drop in activation across a product area shared by several teams. The data needed to distinguish a product issue from an instrumentation issue was owned by a partner team, and that team was reluctant to share it because they were handling a production incident and were concerned about exposing incomplete data.

Task

I needed to get enough reliable information to make a sound decision without distracting the partner team or treating their caution as obstruction. The tension was between moving quickly and preserving trust and data quality.

Action

• I first asked what was behind the hesitation rather than escalating or repeating the request. I learned that the team did not have confidence in the event definitions and feared that a partial extract would be misinterpreted.
• I narrowed the request to the smallest useful slice: aggregate counts by funnel step and platform, with no user-level records. I explained the decision we were trying to make and how the data would be used.
• I offered options that reduced their effort and risk: a short readout with their analyst, a query they could review, or a delayed export after the incident. I made the deadline flexible and agreed not to publish conclusions until we validated definitions together.
• I partnered with my product analyst to document assumptions and compare the requested events against an independent source. That let the data owner correct one event mapping before it influenced our recommendation.
• Once we had the evidence, I shared the findings and gave the partner team credit for the validation. I also proposed a lightweight recurring data contract so future requests would not depend on ad hoc negotiation.

Result

We received a trustworthy aggregate view within a few days, identified that the apparent activation drop was concentrated in one platform’s instrumentation, and avoided launching a product change based on misleading data. The teams agreed on event definitions and an escalation path for future investigations. I learned that an unwilling response often signals an unresolved risk; understanding and reducing that risk is usually more effective than applying pressure.

What interviewers listen for

• Curiosity and empathy before escalation.
• A specific, appropriately scoped request and clear business context.
• Respect for data quality, privacy, and the other team’s priorities.
• A measurable outcome and a durable improvement to the working relationship.

Model answer

Situation — I manage one-on-ones as a recurring space for each person’s growth, feedback, and support—not as a status meeting. On a team of [size], people had different levels of experience and different needs, so using an identical agenda for every conversation would have missed important context.

Task — My goal was to make the meetings reliable and useful while ensuring operational updates did not crowd out career conversations or concerns that people might not raise in a group setting.

Action

• I scheduled a consistent [30- or 45-minute] meeting, generally weekly or every other week depending on the person and team context. I protect the time and reschedule rather than cancel when possible; repeated cancellations signal that the meeting is not valued.
• I keep a shared, lightweight agenda. The report can add topics first, and I add follow-ups from previous conversations. A typical meeting starts with, “What would make this time useful for you?”
• I let the employee lead. We cover what is going well, blockers, team dynamics, feedback, and career goals as relevant. I avoid turning the conversation into a project-status review; routine status belongs in the team’s normal planning tools.
• I tailor the cadence and topics. Someone new to the team may need more frequent context and feedback, while a senior engineer may prefer more time on strategy, influence, or longer-term growth.
• I record only useful commitments, not sensitive personal details. I follow up on actions I own and check later whether the support helped. If I hear a concern involving safety, fairness, or serious conduct, I respond through the appropriate process rather than treating it as an ordinary coaching topic.
• I periodically ask for feedback on the meetings themselves: what to keep, change, or stop. That helps me notice when I am talking too much or failing to close the loop.

Result — This structure helped me catch [example: a workload concern, career goal, or team friction] early and follow through with [specific action]. Over time, [relevant pulse, retention, engagement, or development measure] improved or remained healthy, and employees had a consistent place to raise issues before they became surprises. I view effective one-on-ones as a trust-building practice: the strongest evidence is not a perfect agenda, but that people feel heard and see their manager act on what they share.

What interviewers listen for

• A consistent cadence with employee-led discussion.
• Clear separation of status reporting from coaching and support.
• Confidentiality, follow-through, and adaptation to individual needs.

Model answer

Situation — In an ML team, an engineer’s repeated missed commitments and production-quality issues can affect colleagues, product launches, and customer trust. In this example, an engineer had missed several agreed milestones and introduced recurring defects despite earlier feedback; the situation was serious, but I wanted to handle it fairly and without surprises.

Task — My responsibility was to establish whether the performance gap could be corrected, provide a reasonable path and support where appropriate, and make a timely, respectful decision that protected the team and business.

Action

• I first separated observed facts from interpretation. I gathered specific examples—commitments, quality issues, their impact, and prior feedback—and checked for unclear expectations, workload problems, or process failures that I as the manager needed to address.
• I met privately with the employee, described the gap and its impact plainly, and listened. I asked what context I might be missing and checked that expectations had been communicated consistently.
• Where improvement was realistic, I agreed on a time-bound plan with measurable expectations, support, and regular check-ins. For example, that could mean delivery dates agreed in advance, tests and operational documentation required for changes, and a weekly review of progress. I involved HR and followed company policy rather than improvising a process.
• I documented expectations and feedback, gave the employee a genuine opportunity to respond, and kept relevant stakeholders informed only on a need-to-know basis. If the gap persisted—or the situation warranted immediate action—I made the decision with HR and senior leadership, applying the same standards consistently.
• If termination was necessary, I delivered the decision privately and directly, explained the next steps, protected the person’s dignity, and coordinated access, knowledge transfer, and workload coverage with appropriate care.

Result — In a case that ends in termination, success is not making the decision feel easy; it is making it fair, well-supported, timely, and respectful, while maintaining continuity for the team. I would describe the actual outcome—for example, whether the employee improved under a plan or the role was transitioned safely—without disclosing confidential details. I’ve learned to address performance concerns early, because clarity and support are better for both the individual and the organization than a late surprise.

Model answer

Situation — One of the hardest challenges in my career was taking over a critical initiative that had lost stakeholder confidence. Several teams depended on it, the original plan was slipping, and the team was balancing customer commitments against reliability and technical debt. The challenge was not just the technology; it was restoring a shared view of reality without demoralizing the people doing the work.

Task — I was accountable for a credible recovery plan that protected customers, made ownership clear, and rebuilt trust with partner teams. I had to decide what to stop or defer, not simply ask people to work harder.

Action

• I established the facts first: delivery status, unresolved risks, dependencies, operational health, and the assumptions behind the original estimates. I asked the team to surface bad news early and made clear that the review was about the plan, not blame.
• I split the work into customer-critical commitments, reliability prerequisites, and deferrable scope. With product and partner leaders, I agreed on explicit trade-offs and documented what would not ship in the first release.
• I assigned a directly responsible owner to each major dependency and created a short weekly review focused on decisions, risks, and measurable progress—not status theater.
• I reduced uncertainty with a staged release, success criteria, and rollback plan. For example, we first validated the riskiest integration with a small cohort rather than committing the entire customer base to an unproven path.
• I kept communication consistent: one source of truth, early escalation when dates changed, and recognition of the team’s progress as risks were retired.

Result — We [delivered the critical scope / stabilized the service] within [time frame], improved [reliability or delivery metric] from [baseline] to [result], and restored a more predictable relationship with partner teams. The experience taught me to treat transparency and focus as leadership tools: when a plan is in trouble, teams need a smaller set of priorities and honest decision-making, not optimism without evidence. At Arista, I would apply that lesson by protecting customer trust, surfacing risk early, and aligning teams around the outcomes that matter most. What interviewers listen for: real stakes, personal ownership, difficult trade-offs, learning without blame, and measurable recovery. Replace the bracketed outcomes with verified details from your experience.

Model answer

Situation — I led an incident review after a service degradation affected several customer-facing workflows. The technical diagnosis involved a connection-pool limit, retry amplification, and a dependency that was already operating near capacity. The audience included engineers who needed the detailed failure mechanics and business leaders who needed to understand customer impact and the recovery plan.

Task — I owned explaining what happened in a way that supported decisions without overwhelming people with implementation details. I also needed to be clear about what we knew, what was still uncertain, and how we would prevent a repeat.

Action

• I first separated the message into three questions: what customers experienced, why the system behaved that way, and what we were changing. That gave each audience a usable structure.
• I created a simple analogy: retries acted like people repeatedly joining a crowded queue, increasing the load on the service that was already struggling. I used one diagram to show the request path and where the queue formed.
• I kept the technical appendix for engineers: request rates, pool saturation, retry behavior, and the timeline. In the main review, I translated those into outcomes—slower requests, elevated errors, and the duration of customer impact.
• I stated uncertainty explicitly. For example, I distinguished the confirmed trigger from a suspected contributing factor and assigned an owner and deadline to validate the latter.
• I ended with decisions, not just explanation: retry limits, circuit-breaking behavior, capacity alerts, and a follow-up load test. I asked each group to repeat back the actions they owned so there was no ambiguity.

Result — The review produced agreement on immediate mitigations and longer-term work, and the teams completed the follow-ups by the committed dates. Leaders could make the capacity decision without needing to interpret raw metrics, while engineers had enough detail to validate the fix. I learned that simplifying a complex topic is not removing rigor; it is choosing the right level of detail for the decision at hand.

What interviewers listen for

• You tailor the explanation to the audience without distorting facts.
• You use structure, visuals, and plain language to make complexity understandable.
• You separate confirmed evidence from assumptions and end with clear decisions.

Model answer

Situation — In a previous role, my team was asked to take on a business-critical feature with a deadline tied to a customer commitment. The team was already supporting a reliability initiative, and adding the feature without changing scope would have increased operational risk and made the delivery date uncertain. I needed to resolve the disagreement without treating engineering capacity and business urgency as competing priorities.

Task — I owned finding a plan that protected reliability while meeting the underlying customer need. The key was to distinguish the business outcome from the initial solution proposal, then make the constraints and options visible to both groups.

Action

• I met with the product and sales leads to understand the customer problem, the commitment already made, and which capabilities were truly required for the initial launch.
• I worked with engineers to estimate the full proposal and identify the parts that carried the most reliability risk. I asked the team to explain the risks in terms of customer impact, not just technical complexity.
• I brought both groups together with three options: deliver the full scope later, deliver a narrower version by the commitment date, or pause the reliability work. I made the cost and risk of each option explicit.
• I recommended a phased release: a smaller workflow that solved the customer’s primary problem, followed by the remaining capabilities after reliability milestones. We agreed on measurable acceptance criteria and a named owner for each dependency.
• I set up a weekly review of delivery confidence and reliability indicators, with a clear trigger to renegotiate scope rather than silently compress testing.

Result — We delivered the core workflow by the customer date and completed the broader feature afterward, while keeping the reliability work on track. The phased plan helped preserve the customer commitment without making the team absorb an unbounded deadline risk. I learned that common ground usually comes from aligning on the outcome, then being candid about the trade-offs—not from splitting the difference between two positions.

What interviewers listen for

• You understand both business outcomes and engineering constraints.
• You surface options and trade-offs rather than escalating blame.
• You make the agreement measurable and follow through.

Model answer

Situation — Two experienced engineers on a model-serving project disagreed about whether to move inference to a new service or optimize the existing path. The disagreement was slowing a launch and beginning to affect collaboration across the team. Both had valid concerns: one prioritized latency and future scale; the other prioritized operational risk and delivery time.

Task — I needed to resolve the decision without turning a technical disagreement into a personal one, keep the launch moving, and make sure the people involved could work together afterward.

Action

• I spoke with each person individually first to understand the underlying concern, the evidence they trusted, and whether there was an interpersonal issue beneath the technical debate. I listened for impact rather than relying on the loudest voice.
• I brought them together and restated the shared goal: meet the launch’s latency and reliability needs with a safe path to production. I set norms for the discussion—challenge assumptions and proposals, not motives or competence.
• I made the trade-offs explicit. We compared measured p95 latency, error rates, expected traffic, operational burden, migration effort, and rollback complexity. Where evidence was missing, I asked the team to run a small benchmark rather than debate hypotheticals.
• I clarified who owned the decision and how we would make it. We chose the least risky option for the launch, with a documented threshold that would trigger revisiting the architecture after traffic grew. That preserved momentum without dismissing the scalability concern.
• I followed up with each engineer, recognized the useful contribution from both, and checked that the decision and ownership were understood. If the conflict had involved disrespect or repeated behavior, I would address that separately and directly.

Result — In this example, the team made the launch decision within a week, met the agreed reliability target, and had a concrete plan for revisiting the design rather than reopening the argument informally. More importantly, the engineers could continue collaborating because the decision process felt evidence-based and fair. I’ve learned that my job is not to eliminate disagreement; it is to make it productive, resolve it at the right level, and intervene when behavior—not just ideas—becomes harmful.

Model answer

Situation — In a growing ML organization, teams were shipping models and platform work, but success was being described inconsistently: one group cited launches, another cited offline accuracy, and another cited delivery speed. As a manager, I wanted a shared definition that connected engineering work to customer and business outcomes without reducing people to a single metric.

Task — I was responsible for setting clear expectations across my team, making progress visible, and ensuring we measured both delivery and the health of the system and team.

Action

• I started by aligning with product and business partners on a small set of outcomes: for example, improving relevant recommendations, reducing serving latency, and lowering operational incidents. I made explicit which outcomes the team could influence and which were shared dependencies.
• I translated those outcomes into team-level measures and individual goals. For a model launch, that meant tracking an online customer metric alongside guardrails such as latency, error rate, and segment-level quality—not treating offline AUC as success by itself.
• I balanced outcome measures with leading indicators: experiment milestones, data-quality checks, review quality, operational readiness, and whether teams were meeting commitments sustainably.
• I used regular one-on-ones and reviews to ask what was blocked, what the person had learned, and whether their goals still matched the team’s priorities. When a metric moved, I investigated causes rather than rewarding or blaming someone based on a number they might not control.
• I shared progress and trade-offs with stakeholders. For instance, I would recommend delaying a launch if a small average lift hid a significant regression for an important user segment.

Result — In this example, the team could explain how its work connected to customer impact, and reviews surfaced risks earlier; a representative result might be a 15% improvement in a target engagement metric while keeping p95 latency and incident rates within agreed limits. I also learned that workplace success is sustained impact: strong outcomes, reliable execution, team growth, and the ability to improve the system over time. I would replace the example metrics with verified results from my own experience.

Model answer

Situation — In one organization, an initiative was at risk because several teams had different interpretations of a complex technical change. The underlying proposal involved dependencies, reliability risks, and delivery trade-offs; most stakeholders needed to make a decision, not understand every implementation detail.

Task — I owned explaining the options to both engineering and non-engineering leaders, getting agreement on a path, and making the consequences clear without oversimplifying the risks.

Action

• I first asked what each audience needed to decide. Engineers needed architecture and failure-mode detail; executives needed customer impact, cost, timing, and reversibility.
• I organized the material around one central question and presented three options: the status quo, a minimal change, and a staged investment. For each, I compared impact, effort, risk, and time to value.
• I translated technical behavior into a concrete example. Rather than lead with internal component names, I showed what a customer would experience during a failure and how each option changed that outcome.
• I used a one-page summary with a simple diagram, explicit assumptions, and a short appendix for implementation details. I called out what we knew, what we did not know, and how we would reduce uncertainty.
• I invited questions and checked comprehension by asking stakeholders to restate the decision and its trade-offs. When a concern surfaced, I updated the recommendation rather than treating the presentation as a sales pitch.

Result — The stakeholders aligned on a staged approach, with a measurable first milestone and a clear trigger for further investment. The team avoided debating low-level details before agreeing on the customer outcome, and follow-up decisions became faster because the assumptions and risks were documented. I learned that clarity is not just simplifying language; it is choosing the right level of detail for the decision while preserving the important uncertainty. What interviewers listen for: audience awareness, a useful analogy or visual, clear trade-offs, evidence of understanding, and an outcome tied to a decision.

Model answer

Situation — In a cross-team launch, a dependency owner told me they could not deliver their integration work by the date we had planned because a higher-priority commitment had taken over their team’s capacity. The dependency was on the critical path, and the date had already been communicated to partner teams.

Task — I needed to understand the real constraint, protect the program’s outcome, and reset the plan responsibly without treating a teammate’s capacity issue as a commitment problem.

Action

• I met with the contributor and their manager to understand the competing work, the earliest credible delivery date, and whether the full request was actually needed for launch. I avoided negotiating a date before understanding the scope and ownership.
• I decomposed the dependency into must-have and deferrable capabilities with the engineering lead. We identified a smaller interface that could unblock integration while leaving nonessential automation for a later milestone.
• I laid out options with schedule, quality, and resource trade-offs: reduce launch scope, move the date, add qualified capacity, or change sequencing. I did not assume adding people would help if onboarding cost would exceed the time saved.
• I brought the options to the accountable leads with a recommendation and a clear ask—for example, approve a scoped first release or explicitly reprioritize the dependency. I documented the decision, owner, and revised dates.
• I updated the integrated plan and risk log, added a short feedback checkpoint, and monitored the dependency through demonstrable milestones rather than a single end date. I communicated the impact early to downstream teams.

Result — We agreed on a smaller, testable dependency that preserved the launch’s core value, while deferring lower-priority work to a follow-up milestone. If that scope reduction had not met the quality bar, I would have recommended a date change rather than conceal the risk. The key lesson is to make capacity, scope, and schedule trade-offs explicit, while maintaining a respectful relationship with the contributor and a credible plan for stakeholders.

Model answer

Situation — In my current role, I lead teams working on customer-facing systems where reliability, speed of delivery, and technical quality all matter. My leadership approach has developed in environments where teams need autonomy, but where unclear priorities or weak operational discipline can quickly affect customers.

Task — My responsibility is to create the conditions for strong teams to deliver meaningful outcomes: set direction, build trust, and make trade-offs explicit. I would bring the same approach to Arista Networks, where dependable networking products and customer confidence are central.

Action

• I lead with clarity and context. I explain the customer problem, success measures, and constraints, then give teams room to choose implementation details.
• I value ownership with accountability. Teams own services through delivery and operation; we use clear decision rights, runbooks, and blameless reviews to learn from incidents.
• I invest in technical excellence and pragmatic execution. I encourage rigorous design and testing, while distinguishing essential quality and reliability work from unnecessary process.
• I build inclusive, candid teams. I seek dissent early, make space for different perspectives, and address performance or collaboration issues directly and respectfully.
• I connect engineering work to business impact. For example, when a roadmap was overloaded, I worked with product and engineering leads to rank work by customer value and risk, then communicated what we would defer and why.

Result — In that case, the team delivered the highest-priority customer outcomes with fewer competing commitments, and stakeholders had a clearer view of risks and progress. I would adapt this approach at Arista by first learning its customers, products, and engineering culture, then aligning teams around measurable outcomes while preserving the high bar for reliability and quality. What interviewers listen for: specific values in action, respect for the company without flattery, sound trade-offs, and evidence of impact beyond one team.

Model answer

// IPv4 longest-prefix-match routing table.
class TrieNode {
  constructor() {
    this.children = [null, null];
    this.route = null;
  }
}

class RoutingTable {
  constructor() {
    this.root = new TrieNode();
  }

  insert(cidr, nextHop) {
    const { address, prefix } = this._parseCidr(cidr);
    let node = this.root;

    for (let depth = 0; depth < prefix; depth++) {
      const bit = this._bitAt(address, depth);
      if (!node.children[bit]) node.children[bit] = new TrieNode();
      node = node.children[bit];
    }

    // Replacing a route for the same prefix updates its next hop.
    node.route = { nextHop };
  }

  delete(cidr) {
    const { address, prefix } = this._parseCidr(cidr);
    let node = this.root;
    const path = [];

    for (let depth = 0; depth < prefix; depth++) {
      const bit = this._bitAt(address, depth);
      const child = node.children[bit];
      if (!child) return false;
      path.push({ parent: node, bit, child });
      node = child;
    }

    if (!node.route) return false;
    node.route = null;

    // Remove now-empty trie nodes, but never remove the root.
    for (let i = path.length - 1; i >= 0; i--) {
      const { parent, bit, child } = path[i];
      if (child.route || child.children[0] || child.children[1]) break;
      parent.children[bit] = null;
    }
    return true;
  }

  forward(ip) {
    const address = this._parseIPv4(ip);
    let node = this.root;
    let bestRoute = node.route; // Supports the default route, 0.0.0.0/0.

    for (let depth = 0; depth < 32; depth++) {
      const child = node.children[this._bitAt(address, depth)];
      if (!child) break;
      node = child;
      if (node.route) bestRoute = node.route;
    }

    return bestRoute ? bestRoute.nextHop : null;
  }

  _parseCidr(cidr) {
    const parts = cidr.split('/');
    if (parts.length > 2) throw new Error('Invalid CIDR');
    const address = this._parseIPv4(parts[0]);
    const prefix = parts.length === 1 ? 32 : Number(parts[1]);
    if (!Number.isInteger(prefix) || prefix < 0 || prefix > 32) {
      throw new Error('Invalid prefix length');
    }
    return { address, prefix };
  }

  _parseIPv4(ip) {
    const parts = ip.split('.');
    if (parts.length !== 4) throw new Error('Invalid IPv4 address');

    let address = 0;
    for (const part of parts) {
      if (part === '' || part.trim() !== part) throw new Error('Invalid IPv4 address');
      const octet = Number(part);
      if (!Number.isInteger(octet) || octet < 0 || octet > 255) {
        throw new Error('Invalid IPv4 address');
      }
      address = address * 256 + octet;
    }
    return address;
  }

  _bitAt(address, depth) {
    return Math.floor(address / (2 ** (31 - depth))) % 2;
  }
}

const routes = new RoutingTable();
routes.insert('10.0.0.0/8', 'gateway-a');
routes.insert('10.2.0.0/16', 'gateway-b');
// routes.forward('10.2.3.4') returns 'gateway-b' (longest prefix wins).

• Store prefixes in a binary trie; forward remembers the most-specific route encountered.
• insert and delete take O(32) time for IPv4; forward takes O(32) time. Space is O(number of trie nodes).

Model answer

// Reorders a singly linked list in place:
// a -> b -> c -> d -> e -> f -> g
// becomes a -> g -> b -> f -> c -> e -> d.
function reorderList(head) {
  if (!head || !head.next) return head;

  // Find the start of the second half and the end of the first half.
  let slow = head;
  let fast = head;
  let firstHalfTail = null;
  while (fast && fast.next) {
    firstHalfTail = slow;
    slow = slow.next;
    fast = fast.next.next;
  }

  // Split the list, then reverse the second half.
  firstHalfTail.next = null;
  let second = reverseList(slow);

  // Alternately merge nodes from the two halves.
  let first = head;
  while (second) {
    const firstNext = first.next;
    const secondNext = second.next;

    first.next = second;
    second.next = firstNext;

    first = firstNext;
    second = secondNext;
  }

  return head;
}

function reverseList(head) {
  let previous = null;
  let current = head;
  while (current) {
    const next = current.next;
    current.next = previous;
    previous = current;
    current = next;
  }
  return previous;
}

• Find the midpoint with slow/fast pointers, split the list, and reverse the second half.
• Merge the halves by alternating nodes; the first half has the extra middle node when the length is odd.
• The input list is modified in place.

Complexity: O(n) time, O(1) extra space.

Model answer

/**
 * Removes every node whose value is strictly equal to target.
 * Rewires the existing list; it does not copy the retained nodes.
 * @param {{ value: any, next: object | null } | null} head
 * @param {any} target
 * @returns {object | null} The new head of the list.
 */
function removeElements(head, target) {
  // A temporary sentinel makes head removals use the same logic as others.
  const sentinel = { value: undefined, next: head };
  let previous = sentinel;
  let current = head;

  while (current !== null) {
    if (current.value === target) {
      // Skip the matching node; consecutive matches are handled naturally.
      previous.next = current.next;
    } else {
      previous = current;
    }
    current = current.next;
  }

  return sentinel.next;
}

• Walk once with previous and current; bypass each matching node.
• Do not advance previous after a removal, so consecutive matches are removed too. The returned head handles leading matches.

Complexity: Time O(n); extra space O(1).

Model answer

1. Requirements & scale

Functional requirements

• Users publish posts with text and media, follow or unfollow accounts, and view a ranked home feed.
• Support pagination, post deletion, privacy controls, and basic engagement signals such as likes and replies.
• New posts should appear quickly for active followers; feed ranking may personalize ordering.

Non-functional requirements

• Read-heavy, highly available feed reads; tolerate delayed feed updates rather than losing posts.
• Low latency: p95 feed response under 300 ms in-region; typical new-post visibility under 5 seconds.
• Enforce block, privacy, and deletion rules at read time as well as during feed generation.

Estimates

• Assume 100M daily active users and 10 feed opens per user per day: 1B reads/day, about 11.6K average QPS; design for 5x peak, or roughly 60K QPS.
• If 10M posts/day average 2 KB of metadata, that is about 20 GB/day raw, before indexes and replication. Media is stored separately in object storage and served through a CDN.
• With 500 followers per author on average, fan-out creates about 5B feed entries/day in the naive case. This makes selective fan-out essential.

2. High-level architecture

flowchart TD
  subgraph Client
    A[Mobile and Web]
  end
  subgraph EdgeCDN[Edge and CDN]
    B[API Edge]
    C[Media CDN]
  end
  subgraph LoadBalancer[Load Balancer]
    D[Regional Router]
  end
  subgraph APIServices[API and Services]
    E[Feed API]
    F[Post Service]
    G[Social Graph]
    H[Ranking Service]
  end
  subgraph Cache[Cache]
    I[Feed Cache]
    J[Post Cache]
  end
  subgraph Datastores[Datastores]
    K[Feed Store]
    L[Post Store]
    M[Graph Store]
    N[Object Storage]
  end
  subgraph MessageQueue[Message Queue]
    O[Post Events]
  end
  subgraph Workers[Workers]
    P[Fanout Workers]
    Q[Cleanup Workers]
  end
  A -->|feed request| B
  A -->|media request| C
  B -->|API request| D
  D -->|read or write| E
  D -->|create post| F
  E -->|rank candidates| H
  E -->|cache lookup| I
  E -->|post lookup| J
  I -->|cache miss| K
  J -->|cache miss| L
  F -->|write metadata| L
  F -->|upload reference| N
  F -->|publish event| O
  G -->|follow graph| M
  O -->|new post| P
  P -->|fanout entries| K
  Q -->|delete and privacy updates| K

3. API design

• GET /v1/feed?cursor=...&limit=20 — return ranked feed items and an opaque continuation cursor.
• POST /v1/posts — create a post; accept an idempotency key to make retries safe.
• DELETE /v1/posts/{post_id} — delete a post and enqueue feed cleanup.
• PUT /v1/users/{id}/following/{target_id} — follow an account.
• DELETE /v1/users/{id}/following/{target_id} — unfollow an account.
• POST /v1/posts/{id}/likes — record an engagement event.

4. Data model & storage

• Posts: Post(post_id, author_id, created_at, body, media_refs, visibility, version, deleted_at). Store metadata in a horizontally partitioned NoSQL or wide-column store, partitioned by post_id; maintain an author-and-time index for author timelines.
• Feed entries: FeedEntry(user_id, score_time, post_id, reason, source_version), partitioned by user_id and ordered by score/time. Use a wide-column store for predictable per-user range reads.
• Social graph: adjacency lists keyed by user_id, with separate follower and following access patterns. A graph-capable or sharded key-value store is suitable; avoid a single global join on feed reads.
• Media: object storage for original and transformed media; CDN for delivery. Cache hot post metadata and recent feed pages, but apply privacy checks before returning cached content.
• Events: durable queue with post-created, follow-changed, and post-deleted events. Consumers must be idempotent.

5. Deep dive

Use a hybrid fan-out strategy. For ordinary authors, publish a post event and asynchronously append the post ID to followers’ feed inboxes. For celebrity or high-follower accounts, do not synchronously write millions of inboxes; store their posts in an author timeline and merge those candidates at read time. Choose the threshold using measured write amplification, read cost, and freshness targets rather than a fixed universal number.

On a feed request, fetch a bounded set of recent inbox candidates plus recent posts from followed high-fan-out authors, deduplicate, filter, rank, and return a cursor. The cursor should encode the last ordering key and a stable snapshot boundary, not an offset. Ranking can begin with freshness and relationship signals, then incorporate engagement and personalization. Bound candidate counts so a user following many accounts cannot trigger unbounded work.

sequenceDiagram
  participant U as User
  participant F as Feed API
  participant C as Feed Cache
  participant S as Feed Store
  participant R as Ranker
  U->>F: GET feed with cursor
  F->>C: Read first page
  alt Cache hit
    C-->>F: Candidate post IDs
  else Cache miss
    F->>S: Read inbox candidates
    S-->>F: Candidate post IDs
  end
  F->>R: Merge, filter, and rank
  R-->>F: Ordered visible posts
  F-->>U: Items and next cursor

For correctness, deletion and privacy changes must invalidate or filter stale feed entries. Feed entries are denormalized pointers, not authorization grants. The read path checks current post visibility, blocks, and account state; asynchronous cleanup reduces storage and improves efficiency. Track queue lag and provide a repair/backfill path for missed events.

6. Scale, bottlenecks & trade-offs

• Replicate post and graph data across regions; route writes to a home region or use explicit conflict handling. Prefer eventual consistency for feed assembly, but strong consistency for privacy changes and post ownership checks.
• Shard feed storage by user ID. Hot users and celebrity authors need special handling; partitioning only by author can create hot partitions.
• Cache recent pages and post metadata, with short TTLs and version-b

Model answer

1. Requirements & scale

Functional requirements

• Users follow accounts and topics, publish posts, and retrieve a personalized, paginated home feed.
• Support text, media references, likes, replies, and reposts; enforce blocks, privacy, and moderation rules.
• Rank eligible posts using recency and relevance. Support deletion and eventual feed updates after social graph changes.

Non-functional requirements

• Feed reads should be fast and highly available; target p95 under 200 ms for feed assembly, excluding media download.
• A new post should appear for most followers within seconds. Strong consistency is needed for writes and permissions; feed materialization can be eventual.
• Protect against abuse, hot accounts, duplicate delivery, and regional failures.

Illustrative scale

• 100 million daily active users, 10 feed opens per user per day = 1 billion reads/day, or about 11.6k average QPS. At a 5x peak, plan for roughly 58k QPS.
• 5 million posts/day at 2 KB metadata each is about 10 GB/day raw, or 3.65 TB/year before indexes and replication. Media is stored separately in object storage.
• If each post is delivered to an average of 200 followers, fanout creates 1 billion feed-entry writes/day. This motivates batching, hybrid fanout, and controlling celebrity-account expansion.

2. High-level architecture

flowchart TD
  subgraph Client
    C[Mobile and web clients]
  end
  subgraph EdgeCDN[Edge and CDN]
    E[API edge and media CDN]
  end
  subgraph LoadBalancer[Load Balancer]
    LB[Regional load balancer]
  end
  subgraph APIServices[API and Services]
    API[Feed API]
    Post[Post service]
    Graph[Social graph service]
    Rank[Feed ranking service]
    Mod[Moderation service]
  end
  subgraph Cache[Cache]
    FC[Feed cache]
    PC[Post cache]
    GC[Graph cache]
  end
  subgraph Datastores[Datastores]
    FeedDB[(Feed entries store)]
    PostDB[(Post and user SQL store)]
    GraphDB[(Follower graph store)]
    Blob["Object Storage (media)"]
  end
  subgraph MessageQueue[Message Queue]
    Q[Post event stream]
  end
  subgraph Workers[Workers]
    Fanout[Fanout workers]
    Safety[Safety and indexing workers]
  end
  C -->|feed and post requests| E
  E -->|API traffic| LB
  E -->|media fetch| Blob
  LB -->|authenticated request| API
  API -->|candidate entries| FC
  API -->|post hydration| PC
  API -->|candidate scoring| Rank
  API -->|follow lookup| GC
  API -->|read and write| FeedDB
  Post -->|create post| PostDB
  Post -->|publish event| Q
  Graph -->|relationship reads and writes| GraphDB
  Rank -->|eligibility and features| PostDB
  API -->|publish and retrieve| Post
  API -->|follow operations| Graph
  Q -->|post created event| Fanout
  Q -->|moderation and search event| Safety
  Fanout -->|followers| GraphDB
  Fanout -->|feed entries| FeedDB
  Safety -->|moderation decision| PostDB
  Fanout -->|refresh feed cache| FC

3. API design

• GET /v1/feed?cursor=...&limit=20 — return ranked feed items and an opaque next cursor.
• POST /v1/posts — create a post; require an idempotency key and return the post ID.
• DELETE /v1/posts/{postId} — delete a post and enqueue cleanup.
• POST /v1/users/{userId}/follows and DELETE /v1/users/{userId}/follows/{followedId} — update the graph.
• POST /v1/posts/{postId}/reactions — add or remove a reaction.

4. Data model & storage

• Posts: post_id, author_id, created_at, text, media_refs, visibility, moderation_state. Store durable post metadata in a sharded SQL or distributed relational store; shard by post_id, with indexes for author timelines.
• Feed entries: (user_id, created_at, post_id, score). Use a wide-column or key-value store partitioned by user_id, ordered by time or score. Keep a bounded recent window per user; older pages can fall back to timeline retrieval.
• Follow graph: adjacency lists keyed by follower for feed reads, with a reverse index keyed by followed account for fanout. Use a graph-optimized or wide-column store; cache hot relationships.
• Media: object storage plus CDN. Cache post and feed data in a distributed cache; treat it as disposable.

5. Deep dive

Use hybrid fanout. For ordinary accounts, a post-created event triggers asynchronous fanout: workers read the author's followers in batches and append the post ID to each follower's feed. For very high-follower accounts, do not write to millions of feeds on every post. Store those posts in an author timeline and merge them into a user's feed at read time.

The Feed API fetches a bounded set of precomputed candidates, adds recent posts from followed high-follower accounts, filters deleted, blocked, private, or moderated content, then ranks and hydrates the top page. Ranking can start with a transparent score such as score = w_recency recency + w_affinity affinity + w_quality * quality; keep ranking latency bounded and degrade to chronological order if the ranker is unavailable. Use opaque cursors containing the last score/time and tie-breaker ID, rather than offset pagination, to avoid duplicates and skipped items as the feed changes.

sequenceDiagram
  participant U as User
  participant API as Feed API
  participant Cache as Feed cache
  participant DB as Feed store
  participant Rank as Ranker
  participant Q as Event stream
  participant W as Fanout worker
  U->>API: GET feed with cursor
  API->>Cache: Read candidates
  Cache-->>API: Cache hit or miss
  API->>DB: Load bounded candidates on miss
  DB-->>API: Candidate post IDs
  API->>Rank: Rank and filter candidates
  Rank-->>API: Ordered eligible IDs
  API-->>U: Feed page and next cursor
  Q->>W: Post created event
  W->>DB: Append entries for regular followers

Make fanout idempotent with a unique (user_id, post_id) key and retry-safe event processing. Deletions and privacy changes emit events that invalidate caches and suppress entries at read time; asynchronous physical cleanup can follow.

Model answer

I’d answer with the actual numbers and context rather than a generic description. A clear version is:

• Size and shape: “I currently lead [N] engineers across [N] teams, with [managers / tech leads / senior ICs]. The team spans [locations or time zones] and owns [product or platform scope].”
• Important characteristics: “We have a mix of [specialties, such as backend, infrastructure, networking, SRE, or frontend] and experience levels. Our strengths are [two specific strengths]; our current development areas are [one or two honest gaps].”
• How the team operates: “We partner closely with [product, design, security, operations, sales, or customer teams]. We use [planning and operational practices] to balance roadmap delivery, reliability, and technical investment.”
• Your leadership impact: “My role is to set direction, clarify ownership, develop leaders, and ensure the team has the skills and operating mechanisms to deliver. For example, I [specific action], which improved [measurable result].”

A strong answer is concise but helps the interviewer understand scope, complexity, and your leadership span. Include direct and indirect reports accurately, distinguish team size from the broader organization, and explain any meaningful recent change in composition. Avoid listing job titles without showing how the team’s mix supports its mission. If relevant to Arista, connect experience in areas such as distributed systems, networking, reliability, or customer-facing engineering to the role—but do not claim expertise the team does not have.