Network Engineer Interview Preparation Guide - Junior Level (FAANG Standards)

Direct answer

A cascading failure is when one component's failure increases load or latency on the components that depend on it, and that increased load causes those components to fail too, propagating outward until a large part of the system is affected, even though only one component actually broke in the first place. The mechanism is almost always resource exhaustion: threads, connections, or memory tied up waiting on the failed component instead of being freed quickly.

Walkthrough: C fails, B overloads, A degrades

flowchart LR
  A[API Gateway] -->|rate limit and timeout| B[Order Service]
  B -->|bulkhead pool: payments| C[Payment Service]
  C -.fails.-> B
  B -->|circuit breaker opens| D[Fallback: queue order for async retry]
  A -->|circuit breaker opens| E[Fallback: 503 with Retry-After]
  B -->|isolated pool: other deps unaffected| F[Inventory Service]

1. C (Payment Service) fails, hanging instead of returning errors quickly, perhaps due to a downstream outage of its own.
2. B (Order Service) calls C without a tight timeout. Each call to C now blocks for far longer than normal, tying up a thread or connection from B's pool for the duration.
3. B's resource pool exhausts. As more requests arrive at B, more threads get stuck waiting on C, until B has no capacity left to serve any request, including ones that don't even touch C.
4. A (API Gateway) calls B, and B is now slow or unresponsive for everything, so A's calls to B start timing out or queueing too, degrading A's own capacity in turn.

Worked example: how fast does B's pool actually exhaust?

Little's Law relates the number of requests in flight to the arrival rate and the time each spends being processed:

Say B receives 500 requests per second, and under normal conditions each call to C takes 50ms:

25 concurrent requests is a light load on a typical connection pool. Now C hangs, and B's HTTP client has no explicit timeout of its own, falling back to a default of 30 seconds:

If B's thread pool has 200 threads, the time to exhaust it entirely is:

Under 400 milliseconds. That's how quickly a single hung dependency with no timeout turns into total unavailability for a service handling 500 requests per second: the pool never gets close to steady-state at the 30-second hang time, it simply fills with stuck requests almost instantly and stays full.

Protections at each layer

• At B, calling C: a tight, explicit timeout (measured in low hundreds of milliseconds, not the client library's 30-second default) so a hung call fails fast and frees the thread quickly; a circuit breaker that opens after a run of failures or timeouts, so B stops even attempting calls to C once it's clearly down, and falls back to queueing the order for later processing; a bulkhead, a dedicated connection pool just for calls to C, so exhaustion from C-related calls doesn't consume the threads B needs to serve requests that don't touch C at all (like inventory checks).
• At A, calling B: the same pattern one layer up, a timeout on calls to B, a circuit breaker that trips once B's error rate or latency crosses a threshold, and a fallback (a fast 503 with Retry-After rather than a hung request) so A's own capacity isn't consumed waiting on a B that's already struggling.

Trade-offs & pitfalls

Timeouts that are too aggressive cause false-positive failures under normal, brief latency variance; timeouts that are too loose don't prevent the cascade fast enough, as the Little's Law example shows. Bulkheads cost real resources (a dedicated pool per dependency uses more total connections or threads than one shared pool) in exchange for isolation, so they're worth applying to the dependencies most likely to fail or most likely to take down unrelated traffic if they do. The most common mistake is only protecting the first hop (B to C) and assuming that's sufficient; as the walkthrough shows, without protection at the A to B hop too, the failure still reaches A once B is degraded, just one layer later.

Situation / high-level concern
As a Network Engineer joining a startup with a small, distributed ownership model, I’d raise three theme-based concerns: sustainability (team capacity & burnout), operational risk (resilience, observability, change control), and career growth (skill development and advancement).

Specific concerns I’d raise

• Sustainability
  • On-call load, frequency of incidents, overtime expectations
  • Quality of documentation and automation (are tasks manual or scripted?)
• Operational risk
  • Single points of failure in topology, vendor lock-in, lack of DR testing
  • Monitoring coverage, alert fatigue, runbook availability
  • Change management and peer review process for network changes
• Career growth
  • Mentorship, learning budget, promotion path, exposure to architecture decisions

Evidence I’d request

• Org chart and on-call rota (who covers what; escalation paths)
• Incident metrics: MTTR, incident frequency, recent postmortems
• Sample runbook, architecture diagram, and network ownership matrix
• Monitoring/alert dashboards and logging retention policy
• Change control process and CI/CD examples for network config
• Budget for tools/training and roadmap for infrastructure work
• Security audit or compliance reports if available

Why this matters
These items show whether the role is sustainable day-to-day, whether I can deliver reliable, secure networks at scale, and whether the company invests in my growth — all reduce operational and career risk while signaling maturity.

Direct answer

I choose core switching hardware in two stages. First, pass or fail gates that any candidate must meet (port speeds and density, table scale with 5-year headroom, required protocols, support terms). Then a weighted scorecard across the remaining ones, validated by a proof of concept (PoC) with numeric acceptance criteria written before any box is racked, and a contract that lets us walk away if the PoC criteria are not met. The procurement risks I manage are lead time, licensing, optics lock-in, end-of-life, support coverage, supply-chain integrity and price protection.

Terms used below, in plain words: incast is many senders hitting one receiver port at the same instant; a microburst is a spike of traffic that lasts microseconds and overflows a buffer before any average counter notices; head-of-line blocking is one stuck packet holding up the packets queued behind it; the control plane is the software that learns routes and programs the forwarding chip; a line card is a pluggable board of ports inside a chassis; hitless means no packets are lost while the software is replaced; NOS is the switch's operating system; NETCONF and gNMI are programmatic interfaces for configuring a switch and streaming its state.

In my experience the criteria that usually decide a purchase are table scale, 5-year TCO and support or lead-time terms; the others mostly act as pass or fail gates.

Evaluation criteria and how each is measured

PoC structure and acceptance criteria

Build a mirror of the real design: the two candidate core units as a pair, a traffic generator on enough ports to load them, and emulated or real downstream switches. Write every pass mark before testing, derived from our service-level objectives (SLO) and measured demand.

1. Line rate and latency, using the RFC 2544 (the classic network device benchmarking method) and RFC 8239 methods: zero loss at 100% load at the smallest frame (64 bytes, which means the most packets per second and so the most per-packet work for the forwarding chip; RFC 2544 includes it to measure that per-frame processing cost) and at the jumbo MTU we use.
2. Buffers: RFC 8239 microburst, head-of-line blocking and incast tests, accepting only the loss the applications tolerate (for example none for storage traffic).
3. Scale: fill every table to 130% of the 5-year plan (worked below) and confirm routing and forwarding stay correct and the control plane stays responsive.
4. Failure: pull a link, a line card, a power supply and the active control module, with the generator measuring loss time. The accepted ceiling is whatever the SLO allows, for example under 1 second for routed paths, written down first.
5. Upgrade: perform a software upgrade under load and record packet loss per method.
6. Automation: build and tear down a full configuration through the API and verify telemetry feeds our collector.
7. Interoperability: peer with our existing routers and firewalls using our actual protocols and timers.
   Any failed must-have disqualifies the vendor regardless of price.

Worked example

Production today: 48,000 MAC entries, 9,000 routes. Growth is 25% per year: 1.25^5 = 3.05, so 5 years gives about 146,500 MACs and 27,500 routes. Test at 130%: about 190,000 MACs and 35,700 routes. A box that is datasheet-rated at 128,000 MACs fails this PoC even though it passes today's load, which is exactly the finding a PoC exists to produce.

Cost arithmetic for one candidate (illustrative prices, replace with the quotes): 2 core units at $85,000 = $170,000; 48 optics at $1,200 = $57,600 (assumption: only 48 of the 64 ports need optics, the other 16 use direct attach cables priced at zero here to keep the illustration simple); licences $9,000 per unit per year x 2 units x 5 years = $90,000; support at 12% of hardware per year = 0.12 x $170,000 x 5 = $102,000; power (assumed 5 kW for the two units) 5 kW x 8,760 h x $0.12 per kWh x 5 years = $26,280 (cooling not included). 5-year TCO = 170,000 + 57,600 + 90,000 + 102,000 + 26,280 = $445,880. With 2 units x 32 ports of 400G = 64 ports, that is $445,880 / 64 = about $6,967 per port over 5 years. Compare this number across vendors, not the list price per port.

Scorecard (weights sum to 100, scores 1 to 5, max 500). Each total is score x weight, summed. Vendor A: 4x25 + 3x20 + 3x20 + 4x15 + 3x10 + 5x10 = 100 + 60 + 60 + 60 + 30 + 50 = 360. Vendor B: 5x25 + 4x20 + 2x20 + 3x15 + 4x10 + 3x10 = 125 + 80 + 40 + 45 + 40 + 30 = 360. Vendor C: 3x25 + 5x20 + 5x20 + 3x15 + 3x10 + 4x10 = 75 + 100 + 100 + 45 + 30 + 40 = 390.

Procurement risks and how I manage them

• Lead time and price validity: ask for committed ship dates with penalties, and buy spares in the first order.
• Licensing: get every feature we need priced in the quote, including whether licences are per port or per box and whether they are subscriptions that disable features at expiry.
• Optics: confirm third-party optics are supported and that the vendor will not refuse support over them.
• End of life: require end-of-sale and end-of-support dates for the platform in writing and a 5-year support commitment.
• Support: coverage hours, hardware replacement time, named escalation, and the right to run a specific bug-fix release.
• Security and supply chain: advisory history, firmware signing, SBOM (software bill of materials).
• Acceptance clause: payment tied to passing the PoC criteria on delivered units, with a return right.
• Lock-in: avoid proprietary fabric features unless the benefit is quantified; keep the exit cost in the TCO.

Trade-offs and pitfalls

Never score on datasheet numbers alone, because vendors measure scale on one feature at a time. Do not tune the PoC for one vendor. The most expensive mistake is a PoC with no written pass marks, which turns into a demo.

Direct answer

Flow control protects the receiver: it uses the TCP advertised window (rwnd) so a fast sender never overruns the receiver's buffer. Congestion control protects the network: slow start and congestion avoidance adjust the sender's congestion window (cwnd) based on signs of packet loss or delay, so the sender never overruns the path's actual capacity. The sender is only allowed to have min(cwnd, rwnd) bytes in flight, so either mechanism alone can throttle a connection.

Structured elaboration

• Flow control (receiver-driven): every ACK carries a receive-window value the receiver advertises based on how much free buffer space it has. If the receiver's application is slow to read data (buffer fills up), it advertises a shrinking window, down to zero (a "zero window"), which pauses the sender until the receiver sends a window update or the sender probes with a small keep-alive segment.
• Congestion control (sender/network-driven): the sender keeps its own cwnd, separate from rwnd.
  • Slow start: cwnd begins small and roughly doubles every round-trip time (RTT) until it hits a threshold (ssthresh) or a loss occurs.
  • Congestion avoidance: once past ssthresh, cwnd grows linearly (roughly one segment per RTT), the classic additive-increase part of AIMD (additive increase, multiplicative decrease).
  • Fast retransmit / fast recovery: three duplicate ACKs signal a likely single lost segment, triggering an immediate retransmission and a smaller cwnd cut, rather than waiting for a full retransmission timeout.
  • Modern stacks (e.g. BBR) instead model the bandwidth-delay product directly rather than relying purely on loss, but the same rwnd-vs-cwnd separation still applies.

Worked example (capture-based diagnosis)

An endpoint-limited flow shows a small, essentially constant advertised window across many segments (Wireshark's expert info flags this as "TCP Window Full" or "TCP ZeroWindow"), with the sender's throughput exactly tracking that ceiling and no loss anywhere in the capture. You can sanity-check this: if the window sits near 65,535 bytes and the RTT is about 50 ms, the theoretical throughput ceiling from the window alone is:

If the observed sustained rate matches that number almost exactly, with zero retransmissions, that is strong evidence the receiver's window, not the network, is the bottleneck. A network-congestion flow looks different: you will see duplicate ACKs (three or more in a row) followed by a "TCP Fast Retransmission" or plain "TCP Retransmission" flag, the sender's inferred cwnd visibly halves right after each loss event, and throughput follows a sawtooth pattern rather than a flat ceiling. Rising RTT over time with no window shrinkage is also a network-side signature (queueing/bufferbloat on a congested link), distinct from the flow-control case where RTT can stay flat.

Trade-offs and pitfalls

• Do not read the raw 16-bit window field literally if window scaling (a TCP option that multiplies the advertised window) is negotiated: Wireshark's "calculated window size" already applies the scale factor, the raw field alone will look artificially small.
• Retransmissions and duplicate ACKs are congestion/loss signals, not flow-control signals; conflating the two is the most common wrong turn in this question.
• The two problems are not mutually exclusive: a slow receiver behind a lossy path can show both signatures at once, so check each independently rather than assuming one explanation and stopping.
• On BBR-style connections, duplicate-ACK-based heuristics are less reliable, since BBR is not purely loss-triggered; you need to look at estimated delivery rate and RTT trends instead of just loss events.

Direct answer
IPv6 removed the ability for ROUTERS along the path to fragment a packet; only the ORIGINATING host may fragment an IPv6 packet, using a dedicated fragmentation extension header, which pushes the entire responsibility for correctly sizing packets (and reacting to Path MTU, Maximum Transmission Unit, Discovery feedback) onto the sender rather than sharing it with the network.

Structured elaboration
In IPv4, any router along the path could fragment a packet too large for its outgoing link (unless the Don't Fragment bit was set), a convenience that came at real cost: routers doing fragmentation work on the fly, and receivers having to reassemble fragments that could have been created by ANY device along the path, not just the sender. IPv6's designers removed this entirely: routers now MUST drop an IPv6 packet that's too large for the next link and send back an ICMPv6 "Packet Too Big" message reporting the link's MTU, rather than fragmenting it themselves. If the ORIGINATING host still needs to send data larger than the smallest MTU along the path, it must fragment the packet itself, before sending, using the IPv6 Fragment extension header (which carries the same conceptual information as IPv4's Identification/Flags/Offset fields, just in a dedicated extension header rather than baked into the main IP header).

Worked example
This design change makes Path MTU Discovery load-bearing in IPv6 in a way it wasn't strictly required to be in IPv4: since no device in the middle of the path can rescue an oversized packet by fragmenting it, a sender that doesn't properly discover and respect the path's minimum MTU will simply have its packets dropped along the way (with an ICMPv6 message reporting why, PROVIDED that message isn't itself being filtered somewhere, the classic PMTUD-blackhole failure mode). This is also why a middlebox in the middle of an IPv6 path is a materially different kind of obstacle than in IPv4: it cannot silently paper over an oversized-packet problem by fragmenting on the sender's behalf; it can only drop and (hopefully) report back.

Trade-offs & pitfalls
The IPv6 design trades away routers' ability to "fix" an oversized packet on the fly in exchange for a simpler, more predictable job for routers (never having to fragment) and a stronger incentive for senders to get Path MTU Discovery right in the first place, rather than relying on the network to quietly compensate for an oversized packet. The practical implication: if ICMPv6 "Packet Too Big" messages are filtered anywhere along an IPv6 path (the same class of misconfiguration that breaks IPv4 PMTUD), there is NO fallback fragmentation happening in the middle of the path to mask the problem, the failure is more absolute than the equivalent IPv4 case.

Sequence the migration as discover, then pilot, then expand, treating dependency discovery as the prerequisite that makes everything else possible, not a parallel track: you can't safely segment or write identity-based policy for traffic you haven't first mapped, and skipping this step is the most common reason phased zero-trust rollouts cause outages.

Dependency discovery before segmenting

Instrument the existing legacy network, flow logs, passive traffic capture, or an agent running in observe-only mode, for a meaningful period BEFORE writing a single enforcement rule, to build an actual map of which systems talk to which, on what ports, how often. Treat any "we think we know our dependencies" claim as unverified until telemetry confirms it; undocumented legacy dependencies are the norm in large estates, not the exception.

Pilot selection

Choose a pilot business-meaningful enough to prove real value, not a throwaway internal tool nobody would notice breaking, but well-owned and well-understood enough that the team can move fast and tolerate early friction. A single business unit's application portfolio, with an engaged owner who can validate that access still works, tends to work better than a technically convenient but organizationally orphaned system.

Technical milestones

1. Instrument and map dependencies, as above.
2. Stand up the identity fabric (the identity provider together with the workload-identity and certificate system that issues and verifies who each user and service is) and enroll the pilot's users and services.
3. Introduce identity-aware access in parallel with existing VPN or perimeter access, so both paths work while traffic gradually shifts.
4. Once telemetry from the parallel period confirms parity, retire VPN access for the pilot's scope.
5. Apply microsegmentation to the pilot's traffic using the dependency map from step 1, moving from default-allow-with-logging to default-deny only once the logs show all legitimate paths have been captured.

Stakeholder communication

A zero-trust rollout changes how people and systems get access day to day, so the pilot needs a visible executive sponsor, a clear timeline communicated to affected users well before any cutover, and a fast escalation path for "I lost access to something I need" during the transition. A slow escalation path during the early rollout is what turns manageable friction into organizational resistance to the whole program.

Systems that can't modernize on the same timeline

Some legacy systems, an old appliance, a vendor system with no supported update path, or a system nobody currently owns, genuinely cannot get an identity agent or modern authentication within the pilot's timeframe. Rather than blocking the whole program on them, wrap them with a compensating control, a dedicated, tightly scoped network segment plus a bastion (a single hardened gateway host that everything must route through to reach the legacy system) or proxy that terminates modern identity-aware access on the legacy system's behalf, so the rest of the environment still moves forward while the legacy system's risk is at least contained and explicitly tracked rather than silently left flat.

Worked example

Pilot the finance department's expense-reporting application stack, a handful of services with one well-known owner and moderate but real business visibility. A two-week observe-only telemetry pass reveals the app also depends on an internal directory-lookup service that wasn't in anyone's documented architecture diagram. Because dependency discovery ran BEFORE any enforcement, that dependency gets added to the access plan before cutover instead of surfacing as an outage during it.

Trade-offs and pitfalls

An Operational Technology (OT) or Industrial Control System (ICS) environment, factory or plant equipment running legacy, often proprietary protocols with strict deterministic-timing and safety requirements, generally cannot follow this identity-agent-based timeline at all. It typically needs a specialized compensating-control approach, network-layer isolation plus a monitored, tightly brokered gateway, scoped as its own track with its own timeline and safety sign-off rather than folded into the general enterprise rollout plan. The most common general pitfall is rushing dependency discovery to hit a schedule, which reliably produces outages once default-deny goes live.

Direct answer

A strong answer here is a specific, honest story, not a general statement about valuing feedback: name the situation, the person, the actual content of what was heard, including if it stung a little, and then show a concrete, lasting change in either the work or the habit of asking, not just a one-time fix.

Structured elaboration

• Context. Pick a moment early enough in your career that asking took some initiative or nerve, since that's what this question is really probing: not "have you ever gotten feedback," but "did you go get it rather than wait for it."
• Who you asked, and why them. Name a specific person and why you chose them, a manager, a senior peer, someone whose judgment you specifically trusted, since the choice itself shows some intentionality.
• What you heard. Be specific and honest, including if the feedback was uncomfortable; a vague or safely-positive answer here reads as either not remembering it or not having really asked for anything real.
• What changed, and how you ask now. This is the part that separates a strong answer from a shallow one. Point to something concrete that's different in how you work now, or specifically in how you ask for feedback since then, more often, more specifically, from a wider set of people, not just "I took it to heart."

Worked example

Early in a first cross-functional project, for example a junior analyst's first project working directly with a business team outside their usual reporting line, the candidate proactively asks a more senior colleague on the project, "was there anything about how I presented this that made it harder to land with the business team?" The senior colleague says the analysis was technically solid, but it was presented with all the caveats and methodology up front, so by the time the actual finding showed up, the audience had already tuned out. That's specific, and a little uncomfortable to hear. The concrete change: since then, the candidate leads with the finding and the recommendation first, and puts methodology in an appendix or offers it only if asked. They also developed the habit of asking that same specific "what made this harder to land" question after every stakeholder-facing piece of work, not just waiting for a scheduled review.

Trade-offs and pitfalls

Choosing an example where the feedback was trivially positive doesn't actually demonstrate coachability. Describing what you heard but not what changed leaves the interviewer to guess whether it actually stuck. Over-dramatizing the feedback as devastating can read as performative rather than genuine. And describing only a one-time fix to that specific piece of work, instead of a durable change to how you work or ask for feedback afterward, undersells the point of the story.

Direct answer

OSPF has five basic LSA (link-state advertisement) types plus type 7 for not-so-stubby areas. Types 1 and 2 describe topology inside one area, types 3 and 4 summarize across areas, and type 5 carries routes from outside OSPF. Summary advertisements (type 3) reduce work inside an area because an area border router (ABR) tells other areas only "this prefix is reachable at this cost", never the internal topology, so internal churn stops at the ABR.

Flooding means each router forwards a newly received LSA to its neighbours so that every router in the LSA's scope ends up holding the same copy. "Redistributed" means a route injected into OSPF from another source such as static routes or BGP.

The LSA types

Two-area example (computed)

Area 1 holds eight subnets, 10.1.0.0/24 through 10.1.7.0/24, and the ABR R3 sits between area 1 and area 0. The eight /24s collapse exactly into one prefix, 10.1.0.0/21 (mask 255.255.248.0, 2,048 addresses, covering 10.1.0.0 to 10.1.7.255).

Related behaviour

An internal router in area 1 reaches a destination in area 0 using a type 3 LSA and the router LSA of the ABR. To reach an external prefix it needs the type 5 LSA and, because the ASBR is in another area, a type 4 LSA to find the ASBR. The reason is that a type 5 LSA names the ASBR by router ID, and the router LSA that would show the path to that ASBR never leaves the ASBR's own area (RFC 2328), so the ABR originates a type 4 saying "the ASBR with this router ID is reachable through me at this cost". Stub areas drop types 4 and 5, which is why they are small.

Pitfalls

• Summarize only blocks that really are contiguous. A range that covers addresses not present in the area draws traffic for unused space to the ABR, where it is silently dropped.
• Summarization hides failures from other areas, which is the point, but also means a distant router cannot tell that one specific subnet is down.
• Type 5 LSAs are global, so a flapping redistributed route is felt by every normal area.

Situation / Task
In my role as a network engineer I must keep current on protocol changes, vendor features, and cloud networking while running day-to-day ops.

Learning routine & time allocation

• Weekly: 3–4 hours split — 1h RFCs/blogs (IETF, vendor release notes), 1h hands-on labs (vendor emulators, AWS/GCP free tier), 1–2h training/cert prep or webinars.
• Monthly: 4–8 hours for deeper study (new vendor platforms, advanced features) and cross-team brown-bag.
• Quarterly: Attend a conference or vendor summit and update runbooks.

How I validate & apply safely

• Lab first: replicate changes in an isolated VM/cloud lab or vendor sandbox.
• Automated tests: use IaC (Terraform/Ansible) and test suites to validate configs.
• Staged rollout: deploy to a canary segment during maintenance windows, monitor with KPIs (latency, error rates, flow logs).
• Change control: peer review, rollback plan, and post-change validation checklist.

Result: continuous learning that translates into low-risk, measurable production improvements.

Direct answer

Name one specific gap, not a vague weakness, and tie it to a concrete moment where it actually cost you something, a decision, a proposal, a difficult conversation, so it reads as self-diagnosed rather than generic. Then give a plan with a next action, a way to practice it inside real work, and a way you'll know it's closing.

Structured elaboration

1. Self-diagnose narrowly. "I don't yet make the case for a decision to skeptical stakeholders with confidence" beats "communication."
2. Use common early-career patterns as a diagnostic aid, not the answer itself: chasing visible breadth instead of depth, avoiding the uncomfortable feedback conversation, waiting to be assigned stretch work instead of asking for it, confusing being busy with being impactful. These patterns are useful for locating your own real gap.
3. Attach the plan to real upcoming work, not a course taken in isolation. Define a repeatable loop: attempt, get feedback, adjust, and set a check-in cadence.
4. Define the closing signal: a type of conversation that gets easier, a decision that no longer needs review, rather than a vague sense of improvement.

Worked example

"My gap right now is that I default to solving a problem quietly on my own instead of pulling in the two or three people whose buy-in I'll eventually need, which meant a proposal I was proud of stalled in review because nobody had context going in. My plan: on the next initiative of similar size, I'm deliberately looping in stakeholders at the framing stage instead of the review stage, and tracking whether proposals move faster through review as a result."

Trade-offs & pitfalls

• Naming a gap so generic it could apply to anyone, "communication," "time management", without a concrete instance is the single most common weak answer here.
• Naming a gap that's really a strength in disguise, "I care too much", reads as evasive.
• A plan with no attachment to real work, just "I'll take a course", rarely closes anything, interviewers probe for how you'll practice it live.
• A related early-career trap worth watching for in yourself: mistaking activity or breadth for progress, or avoiding stretch work until it's handed to you instead of asking for it.