Dataford
Interview QuestionsInterview GuidesExperiencesCoaching
New
Pricing
Get started
Dataford
Popular roles
Software EngineerData AnalystData ScientistData EngineerBusiness AnalystAI EngineerMachine Learning EngineerProduct Manager
Browse
Browse All RolesEvery role hub, from analyst to MLBrowse All CompaniesCompany-specific interview loopsAll Interview GuidesThe full guide library
Top questions by role
Software EngineerData AnalystData ScientistData EngineerBusiness AnalystAI EngineerMachine Learning EngineerProduct Manager
Top questions by skill
SQLPythonStatisticsMachine LearningA/B TestingSystem DesignGenerative AIProduct SenseMetricsBehavioral
Browse all questions →Try a mock interview
Experiences
Practice
Mock InterviewsTimed interview simulations with feedbackCoaching1:1 coaching with people at your target companiesSuccess PathYour 6-week structured planModulesCurated lessons by topicWebinarsTalks from ex-Big Tech data leadsPlaygroundA free-form scratch editor
Learn
BlogInterview strategy and career adviceTech Job Market ReportHiring trends across data and AI rolesFor UniversitiesDataford for career centersAbout DatafordWho we are and how we build
Pricing
Build my plan

Build Testable Network Config Pipeline

EasyPipelines00:00
Practice interviewer
In session
5 left
00:00

Your question is Build Testable Network Config Pipeline. Take a moment with it on the right.

Talk me through your thinking if you like. When you're confident, submit your answer and I'll grade it like a real screen (7/10 or better passes).

You need to log in / sign up to chat or submit.

Problem

Context

NetOpsCloud manages configuration backups and compliance checks for 8,000 enterprise network devices across Cisco, Juniper, and Arista environments. Today, engineers run ad hoc Python scripts from laptops to pull configs over SSH, parse command output, and upload files to S3; the scripts are hard to read, difficult to test, and frequently fail during retries.

You need to design a production-grade data pipeline that turns network automation scripts into a readable, testable, and observable batch ETL system. The pipeline should collect device state, normalize vendor-specific outputs, store raw and curated records, and support safe re-runs without duplicate data.

Scale Requirements

  • Devices: 8,000 active devices, growing to 20,000 in 12 months
  • Collection frequency: Every 15 minutes for critical devices, hourly for standard devices
  • Payload size: 200KB-2MB raw text per device snapshot
  • Daily volume: ~1.5-3 TB raw command output
  • Latency target: Snapshot available in curated warehouse tables within 10 minutes of scheduled run
  • Retention: 90 days raw snapshots, 2 years normalized inventory/compliance history

Requirements

  1. Design an orchestrated batch pipeline to collect configs and operational state from devices over SSH/API.
  2. Make the extraction and parsing code modular, readable, and unit-testable across vendors.
  3. Ensure idempotent re-runs for partial failures, duplicate scheduler triggers, and backfills.
  4. Store both raw command output and normalized tables for interfaces, routes, software versions, and compliance findings.
  5. Add automated data quality checks for missing devices, parse failures, schema drift, and stale snapshots.
  6. Describe CI/CD, test strategy, and how you would separate pure parsing logic from side effects such as network calls and storage writes.
  7. Provide monitoring, alerting, and recovery procedures for device timeouts, parser regressions, and warehouse load failures.

Constraints

  • Infrastructure must run on AWS using managed services where practical.
  • Security requires encrypted secrets, audit logging, and no plaintext credentials in code.
  • Budget allows moderate batch compute but not a 24/7 large streaming cluster.
  • Some devices are rate-limited and can only be queried once per collection window.