Ownership Questions

Taking full responsibility for outcomes, acting with long term perspective, and driving results on behalf of the company. Demonstrates personal accountability, follow through on commitments, solving problems even when work falls outside formal scope, and using failures as learning opportunities.

HardTechnical

21 practiced

You must renegotiate a key vendor contract after repeated failures. Draft the technical and contractual changes you'd seek to include stronger uptime SLAs, concrete ownership clauses, dedicated escalation contacts, measurement metrics, and penalties or credits for non-compliance.

Sample Answer

**Context & objective**As the network engineer leading renegotiation, I would convert operational pain into precise technical and contractual commitments so failures are measurable, owned, and remediable.

**Technical SLAs & metrics**- Uptime: 99.99% availability per month (≤4.38 min downtime). Measured per service endpoint.- Latency: 95th percentile < 50 ms on primary links; 99th < 100 ms on inter-region links.- Packet loss: ≤0.1% sustained (1-minute samples).- Jitter: ≤10 ms (VoIP-sensitive segments).- MTTR / MTTD: MTTD ≤ 5 min for major incidents, MTTR ≤ 1 hour for P1, ≤ 4 hours for P2.- Synthetic & real-user monitoring: ICMP + TCP handshake + application synthetic transactions from 5 global probes and our passive NetFlow/tcpdump sampling.- Measurement windows & reporting: rolling 30-day and monthly reports with raw telemetry exported (SNMP/NetFlow/REST API).

**Ownership & responsibilities**- RACI: vendor responsible for network, transit, and configuration changes (R), we own service requirements and change approvals (A).- Named technical owners: vendor provides 24/7 on-call escalation roster (primary, secondary, tertiary) with guaranteed contactability and escalation SLAs.- Change control: all planned changes require 72-hour notice, maintenance windows, rollback plan, and test validation.

**Escalation & contacts**- Triage Ack: vendor acknowledges P1 within 15 minutes, assigns engineer within 30 minutes.- Dedicated escalation path: direct-dial + secure Slack/MS Teams channel + weekly review with our network team lead.- Executive escalation: mapped contact list leading to vendor CTO within 24 hours for unresolved P1 beyond SLA.

**Measurement & verification**- Joint monitoring feed: vendor provides read-only API access to telemetry; we retain right to independent probes and third-party auditor to validate SLA monthly.- Alerting: standardized event schema (severity, timestamp, affected links) pushed to our SIEM/monitoring.

**Penalties, credits & remediation**- Tiered service credits: 10% monthly credit for <99.99 but ≥99.9, 30% for <99.9 but ≥99.0, 60% for <99.0.- Failure-to-restore credits for P1: additional daily credits escalated for prolonged outages.- Root cause & remediation: vendor must deliver RCA within 48 hours and a remediation plan with milestones; failure to meet remediation milestones triggers increased credits and 30/60/90-day probation.- Termination: after 3 SLA violations in a rolling 12 months or failure to meet remediation milestones, option for immediate termination and vendor-funded migration support (data export, cutover assistance).

**Operational clauses**- Security & patching: vendor must notify security patches 10 days prior; emergency patching process with coordination.- Configuration backups & change logs: daily backups, signed configs, and audit trail retention 12 months.- Liability limits & indemnification: align to risk profile for network outages impacting revenue/SLAs.

These changes make expectations concrete, enable measurable monitoring, ensure clear ownership/escalation, and create financial and contractual incentives for reliable delivery.

HardTechnical

34 practiced

After multiple outages you identify the root cause requires a major network architecture rewrite. Executives are reluctant to fund it. Prepare an executive briefing: 1) one-paragraph summary of the problem, 2) quantified risks/costs, 3) phased plan with milestones and ownership, 4) fallback options and expected benefits.

Sample Answer

**Summary (1 paragraph)** Repeated outages traced to an aging flat L2/L3 topology, overloaded east-west paths, and single points of failure in our legacy WAN appliances. Packet loss and failover delays during peak windows are causing application tier degradation and multi-hour outages. A targeted network architecture rewrite—introducing spine-leaf fabric in datacenters, segmented DC-to-cloud WAN with redundant tunnels (BGP over IPsec/SD-WAN), and automated orchestration—is required to eliminate these systemic failure modes and meet SLAs.

**Quantified risks / costs** - Outages: 18 hours downtime last 12 months → ~$1.8M revenue/ops impact (avg $100k/hour). - Risk of SLA breach fines & churn: estimated $600k/year. - Current ops cost: 1.2 FTEs firefighting (~$150k/year). - One-time rewrite estimate: $1.2–1.6M capex + 6 months of implementation.

**Phased plan, milestones & ownership** 1) Discovery (4 weeks) — inventory, traffic matrix, risk register. Owner: NetEng Lead. 2) Pilot (8 weeks) — deploy spine-leaf in secondary DC + SD-WAN overlay for one app domain; validate failover and telemetry. Owner: Infrastructure Architect. 3) Rollout Phase 1 (12 weeks) — datacenter fabric migration, automated configs (Ansible/NetBox). Owner: NetEng Team. 4) Rollout Phase 2 (12 weeks) — WAN segmentation, cloud peers, DR tests. Owner: Cloud Networking. 5) Stabilize & Handover (4 weeks) — runbooks, training, SLA validation. Owner: Operations. Each phase gated by acceptance tests (latency, loss <0.1%, failover <30s) and ROI checkpoint.

**Fallback options & expected benefits** - Short-term: add parallel circuits and active-active appliances (+50% redundancy, reduces outage probability but not root-cause). - Mid-term: SD-WAN overlay without full fabric (~40% improvement in path diversity, faster failover). These reduce immediate risk while preserving phased rewrite funding window, but yield higher cumulative OPEX and incomplete resolution of east-west bottlenecks.

EasyTechnical

22 practiced

Describe the process you use to track and close action items from postmortems. Include tools, ownership conventions, validation steps, and how you ensure items are not forgotten over weeks or months.

MediumTechnical

22 practiced

You're hired into a company with many undocumented legacy devices and an unclear topology. As the new owner of the core fabric, outline a first-90-days plan to inventory, baseline, secure, monitor, and deliver quick wins while minimizing production risk.

EasyTechnical

27 practiced

How do you structure and maintain runbooks and playbooks so that any network engineer on the team can take ownership during an incident? Provide the headings/sections you include and the processes you use to keep them current and validated.

Sample Answer

**Overview / Purpose** Short one-line summary of the runbook/playbook and when to use it (e.g., "BGP peer flap — production edge routers").

**Prerequisites & Impact** - Required access (jump box, VPN, TACACS role) - Systems, devices, IPs, and services affected - Business impact / SLA / escalation thresholds

**Quick Triage Checklist (first 5 minutes)** - Health checks (ping, traceroute, interface counters) - Monitoring alerts to check (NMS, NetFlow, BGP sessions) - Known maintenance windows or recent changes

**Step-by-Step Play (ordered, reversible)** - Command snippets with exact syntax and expected output (include variations for IOS/JunOS, cloud gateways) - Safe rollback steps for each change - Timing and wait periods between steps

**Verification & Acceptance Criteria** - Specific tests (BGP state, routing table entries, traffic flows, monitor alerts cleared) - How to confirm client/CSI impact resolved

**Escalation & Communication** - Contact list (on-call, senior neteng, SRE, vendor) with primary/secondary - Slack/phone templates and stakeholder update cadence

**Post-Incident Actions** - Required logs and data to collect - RCA owner, timeline, and follow-up ticket templates

**Change History & Ownership** - Owner, last-reviewed date, version, linked RFC/Change Request

Processes to keep them current and validated- Template + mandatory fields so every runbook is consistent - Quarterly review assigned to owners; auto-reminders via ticketing system - Validation drills: annual tabletop and semi-annual live walk-throughs (one per quarter for critical runbooks) with checklists and sign-off - Pull requests in docs repo with CI linting for required sections; gated merge with two approvers - Post-incident updates: mandatory doc update within the RCA workflow before closure - Metrics: track runbook usage, time-to-recovery, and errors to prioritize updates

Example: For a BGP flap runbook I include exact show commands, typical outputs to recognize, vendor CLI variations, a rollback ACL, escalation to ISP NOC at 30 minutes, and a required tabletop within 2 weeks after any incident.

Unlock Full Question Bank

Get access to hundreds of Ownership interview questions and detailed answers.

Join thousands of developers preparing for their dream job.