02Preparation overview

Use telemetry problems to practice careful engineering: define time windows, preserve event identity and explain what an acknowledgment really guarantees. This guide focuses on ingestion, search freshness and debugging while keeping general coding practice in view. Match the depth to the Splunk product team in your posting. These are original exercises, not a promised list of interview questions.

Focus: Telemetry pipelines · Time-window correctness · Operational debugging

Browse Software Engineer questions

Public company-and-role bank: 0 questions at the recorded September 10, 2026 snapshot. Interview experiences: not verified. Editorial practice: 7 prompts, including 4 worked solutions.

03Interview loop

Splunk’s How We Hire link now redirects to Cisco’s recruiting guidance. That page says the process varies by role and team. The outline below separates this official guidance from practical preparation checkpoints; no fixed Splunk round count is asserted.

Role and recruiter alignment · official

Confirm the product group, level and assessment format with your recruiter.

Cisco guidance reached through Splunk’s recruiting link; not a Splunk-specific round count.

Cisco — How We Hire, reached from Splunk careers

Coding preparation · typical

Practice a clear data-processing contract, implementation and edge-case explanation.

Editorial preparation checkpoint, not a verified scheduled round.

Systems and troubleshooting preparation · typical

Be ready to reason about backpressure, data loss, replay and measurement at the depth required by the role.

Preparation advice; recruiter must confirm whether these are interview modules.

Interviews and possible assessment · official

Cisco’s page describes role-dependent interviews and possible assessment, followed by feedback review.

General recruiting guidance; exact number, timing and tool policy need confirmation.

Cisco — How We Hire, reached from Splunk careers

04Questions & practice

All cards below are original PracHub editorial practice. Difficulty is an estimate; these are not verified questions asked by the employer. Worked solutions belong to their question, not a second question list.

Coding

Find the most frequent codes in a time window

Medium · Counting · Time windows · Deterministic ordering

Given events as (timestamp, code), a query time now, a positive window width and a non-negative k, return the top k codes in (now-window, now]. Input may be unsorted. Break equal counts by code ascending. Events from the future do not belong in the result. Use integer timestamps and string codes for this exercise.

Approach

1. Write the interval before writing the loop. The left boundary is excluded and the right boundary is included; changing either choice changes the test result.
2. Count only in-window events, then sort distinct codes by descending count and ascending code. This produces deterministic ties without relying on dictionary insertion order.
3. For n events and c distinct matching codes, the straightforward solution costs O(n+c log c) time and O(c) space. It is a clear baseline for a bounded query.
4. A long-running streaming implementation needs eviction, late-event and watermark policies. A deque alone assumes ordering; it does not solve arbitrary late arrival.

Worked solution · 30 minutes

1. The function is intentionally a batch baseline. A streaming variant should be designed against a separate ordering and lateness contract.
2. Sorting by a tuple makes ties stable even when input delivery order changes.

from collections import Counter

def top_codes(events, now, window, k):
    if window <= 0 or k < 0:
        raise ValueError("invalid window or k")
    counts = Counter(
        code for timestamp, code in events
        if now - window < timestamp <= now
    )
    ranked = sorted(counts.items(), key=lambda item: (-item[1], item[0]))
    return ranked[:k]

Expected result: For now=10 and window=5, an event at 5 is excluded and one at 10 is included. Tied codes A and B appear in alphabetical order. k=0 returns an empty list.

Checks

• Shuffle input order without changing the result.
• Test both time boundaries and a future event.
• Reject a zero-width window and a negative k.

Follow-up

• How would you handle an event that arrives after the dashboard window was finalized?
• When is a size-k heap preferable to sorting all distinct codes?

Define a parser before optimizing it

Medium · Parsing · Input contracts

You need to parse key=value log fields that may contain quoted spaces. Describe the grammar and error behavior before proposing split(" "). Include escaped quotes, duplicate keys and truncated input in your contract.

Approach

1. Use a small state machine that distinguishes ordinary text, quoted text and escape sequences. Tokenization and key validation are separate steps.
2. Decide whether duplicate keys are rejected, retained as a list or resolved by a documented rule. Silent last-write-wins behavior can hide malformed telemetry.
3. Bound field lengths and surface parse failures with counts and safe examples. Avoid logging raw sensitive payloads while debugging the parser.

Follow-up

• How would the parser resume when a quoted field crosses a network-chunk boundary?

SQL

Compute a host error ratio without losing quiet hosts

Medium · Deduplication · Conditional aggregation

hosts(tenant_id, host_id) lists known hosts. request_events(tenant_id, host_id, event_id, status) records requests; identical rows can be replayed. Return each host in tenant a with its deduplicated request count and the fraction whose status is at least 500. A host with no requests should have count 0 and ratio NULL, because no rate was observed. This is SQL practice, not SPL syntax.

Approach

1. Deduplicate exact deliveries before joining. A production event key must also define how conflicting payloads are handled; DISTINCT is not a conflict-resolution strategy.
2. Join on tenant and host. Count event_id rather than the preserved host row, and retain quiet hosts with a LEFT JOIN.
3. Force non-integer division and explicitly return NULL for a zero denominator. Reporting 0% for a host that sent no data can conceal a collection failure.
4. An operational dashboard would also show coverage and data freshness. A low error ratio is only meaningful when enough requests were observed.

Worked solution · 30 minutes

1. A rate is computed from deduplicated logical requests. It is not an average of per-batch percentages.
2. NULL is deliberate for an unobserved rate; presentation can label it “No data.”

WITH events AS (
  SELECT DISTINCT tenant_id, host_id, event_id, status
  FROM request_events
)
SELECT h.host_id, COUNT(e.event_id) AS requests,
  CASE WHEN COUNT(e.event_id) = 0 THEN NULL
       ELSE 1.0 * SUM(CASE WHEN e.status >= 500 THEN 1 ELSE 0 END)
            / COUNT(e.event_id)
  END AS error_ratio
FROM hosts AS h
LEFT JOIN events AS e
  ON e.tenant_id = h.tenant_id AND e.host_id = h.host_id
WHERE h.tenant_id = 'a'
GROUP BY h.tenant_id, h.host_id
ORDER BY h.host_id;

Expected result: A host with one 200 request and one duplicated 500 request has two logical requests and ratio 0.5. A quiet host has count 0 and ratio NULL.

Checks

• Repeat a failed request delivery.
• Include a quiet host and another tenant.
• Verify the result is 0.5 rather than integer zero.

Follow-up

• How would a time filter preserve hosts with no recent requests?
• What if one logical request emits several different event types?

System design

Design a durable telemetry ingestion path

Hard · Backpressure · Partitioning · Search freshness

Design a multi-tenant service that accepts log batches, durably stores them and makes them searchable. Assume bursts above indexing capacity, worker restarts and clients that retry after a timeout. Explain the difference between accepting a request, durably retaining it and making it visible to search. This is an original architecture exercise, not Splunk’s implementation.

Approach

1. Authenticate the tenant before accepting data. Apply tenant quotas and validate batch size so a noisy sender cannot consume the entire ingestion budget.
2. Choose an acknowledgment point and document it. A durable buffer can absorb bursts, while an accepted HTTP response alone says nothing about whether indexing completed.
3. Partition work using a key that balances load without losing the ordering guarantees you promised. Store source event identity so replay can be reconciled.
4. Bound queue growth and expose ingestion lag, indexing lag and rejected bytes separately. Add retention and replay controls before promising that all historical data remains recoverable.

Worked solution · 50 minutes

1. Model three externally meaningful states: accepted, durably retained and searchable. Document which transitions the client can observe.
2. Put a bounded durable buffer between intake and indexing; use per-tenant quotas and backpressure when indexing cannot keep up.
3. Store checkpoints and replay identities with enough context to recover each partition independently. Explain how retention limits the replay window.
4. Test a timeout after durability, a crash during indexing and a tenant sending malformed high-cardinality data.

Expected result: The sender can distinguish a transport response from the promised completion state. A crash does not silently skip accepted work, and repeated delivery has a defined duplicate policy.

Checks

• Trace one event through every acknowledgment boundary.
• State the recovery behavior after buffer retention expires.
• Measure indexing lag separately from HTTP latency.

Follow-up

• If clients need proof of search visibility, what additional protocol or status endpoint is required?
• How would you isolate a tenant sending millions of unique field names?

Splunk Enterprise — HTTP Event Collector indexer acknowledgment

Debugging

Advance a checkpoint only through confirmed offsets

Medium · Acknowledgments · Replay · Ordering

A sender writes a checkpoint for offset 4 after requests for offsets 1, 2 and 4 are confirmed, but offset 3 is still uncertain. A restart begins at 5 and loses offset 3. For one ordered partition, implement a helper that advances only through a contiguous prefix of durably confirmed offsets. The current checkpoint is the greatest already-confirmed offset.

Approach

1. Separate request acceptance from the durability or indexing acknowledgment your protocol actually requires. A successful transport status may be too early.
2. Maintain confirmed offsets for one partition, then advance only while checkpoint+1 is confirmed. Out-of-order successes are retained until the gap closes.
3. Persist the new checkpoint after the destination guarantee is satisfied. A crash before checkpoint persistence may replay data, so downstream reconciliation is still required.
4. Do not infer exactly-once ingestion from the checkpoint rule. It prevents skipping known gaps; duplicate suppression and acknowledgment retention are separate contracts.

Worked solution · 25 minutes

1. The helper models only the prefix rule. Its confirmed set must contain offsets whose required destination guarantee has actually been met.
2. Use one checkpoint per ordered partition. A globally increasing number does not establish ordering across unrelated streams.

def advance_checkpoint(current, confirmed):
    while current + 1 in confirmed:
        current += 1
    return current

Expected result: advance_checkpoint(0, {1,2,4}) returns 2. After 3 is also confirmed, it returns 4. A confirmation for 6 does not skip missing 5.

Checks

• Acknowledge offsets out of order.
• Confirm the same offset repeatedly.
• Replay from an older persisted checkpoint and verify no gap is skipped.

Follow-up

• How would you keep memory bounded if one offset never completes?
• Can two partitions share a single numeric checkpoint?

Splunk Enterprise — HTTP Event Collector indexer acknowledgment

Diagnose a metrics-cardinality memory spike

Medium · Observability · Resource limits

Memory climbs after a release adds request_id as a metrics label. Explain how you would test whether unbounded label cardinality is the cause and how you would recover without losing visibility into the incident.

Approach

1. Compare the number of distinct label combinations before and after the release. Separate a larger number of series from a leak in the storage implementation.
2. Move per-request identity to a suitable log or trace context and keep metric dimensions bounded. Evaluate privacy, retention and query needs before choosing what to preserve.
3. Use a controlled rollout and compare memory, ingest rejection and diagnostic usefulness. Do not fix memory by silently dropping all troublesome tenants.

Follow-up

• What cardinality budget and alert would you add before the next release?

05Two-week plan

A 14-day editorial practice schedule. Spend 45–75 minutes a day and produce something you can explain; this is not the employer’s hiring timeline.

Week 1

Day 1 · Map the Splunk product area (45 min)

• Identify security, observability, ingestion or UI responsibilities in the posting.
• Ask how the Cisco recruiting process applies to this opening.

Deliverable: A product and role map

Day 2 · Count events in a precise window (60 min)

• Write the interval and tie-break rule.
• Implement the batch top-k baseline.

Deliverable: A tested frequency query

Day 3 · Explore streaming tradeoffs (60 min)

• Add late and future events to your examples.
• Compare recomputation with a maintained rolling structure.

Deliverable: A lateness policy

Day 4 · Specify a log grammar (60 min)

• Define quoting, escaping and duplicate-key behavior.
• Create malformed and chunked input examples.

Deliverable: A parser contract

Day 5 · Compute meaningful rates (60 min)

• Deduplicate before aggregating.
• Show why quiet hosts should not report a measured 0% error rate.

Deliverable: A verified host report

Day 6 · Trace acknowledgment boundaries (45 min)

• Read the HEC acknowledgment reference for the relevant deployment.
• Separate received, durable and indexed states.

Deliverable: An acknowledgment sequence

Day 7 · Review a missing-offset failure (60 min)

• Advance only through a contiguous prefix.
• Trace restart before and after checkpoint persistence.

Deliverable: A replay regression test

Week 2

Day 8 · Design the ingestion pipeline (75 min)

• Choose partitioning and a durable buffer.
• Set explicit tenant quotas and backlog limits.

Deliverable: An ingestion architecture sketch

Day 9 · Test an overloaded pipeline (60 min)

• Define when to reject or throttle data.
• Separate HTTP, ingest and indexing latency.

Deliverable: A backpressure decision table

Day 10 · Investigate label explosion (60 min)

• Compare series counts before and after a release.
• Propose a bounded metric-label set.

Deliverable: A cardinality remediation note

Day 11 · Rehearse incident communication (45 min)

• Build an observation-versus-decision timeline.
• Describe containment and recovery evidence.

Deliverable: A two-minute incident story

Day 12 · Run a telemetry mock (75 min)

• Solve an unseen counting variant.
• Defend an acknowledgment policy under retries.

Deliverable: A scored mixed session

Day 13 · Repair the weakest guarantee (60 min)

• Review the mock’s biggest ambiguity.
• Add a test that would catch the failure.

Deliverable: An improved failure test

Day 14 · Confirm format and tools (45 min)

• Ask about language, assessment modules and permitted assistance.
• Review a concise error log rather than memorizing more questions.

Deliverable: A final interview brief

06Behavioral

Communicate like an engineer helping someone make the next decision. Keep observed symptoms, current hypotheses and confirmed recovery separate.

Explain an incident without hindsight shortcuts

Easy · Incident response · Communication

Walk through a real incident or a clearly labeled practice failure. Explain what was known at the time, which customer symptom mattered, what you chose to do first and how you verified recovery.

Approach

1. Use a timeline with observations and decisions separated. Do not describe the eventual root cause as something the team knew from the start.
2. Identify a containment action and its tradeoff. Explain who received updates and how uncertainty was communicated.
3. Choose one follow-up that prevents or detects recurrence and show how it was validated. Blame and a long list of tools are not a substitute for evidence.

Follow-up

• What evidence would have told you that your first hypothesis was wrong?

Cisco — How We Hire, reached from Splunk careers

Additional reflection prompts

• Describe a time a dashboard was misleading and how you verified the underlying data.
• Explain a reliability tradeoff to a product partner without hiding its cost.
• Show how you turned an incident into a tested prevention or detection change.

Review your answer in three passes: check correctness, explain failure handling, then make the reasoning clear to another person.

07FAQ

Can I rely on an old three-round or five-round Splunk outline?

Use it only as a question to ask, not as your schedule. The current Splunk hiring link redirects to Cisco, whose guidance says the process varies by team and role. Confirm the modules with the recruiter. Cisco — How We Hire, reached from Splunk careers

Does an HTTP 200 from HEC prove an event was indexed?

The Splunk Enterprise acknowledgment documentation distinguishes basic request acceptance from confirmation that indexing occurred. Product and deployment support differ, so check the documentation for the environment in question. Do not assume transport success means searchable data. Splunk Enterprise — HTTP Event Collector indexer acknowledgment

Why use SQL instead of SPL here?

The SQL card isolates deduplication and aggregation skills with a small runnable relational fixture. It is not a substitute for learning SPL when the posting requires it, and it does not claim SQL is a standard Splunk interview module.

Should I always choose event time for a dashboard?

Choose based on the user question. Event time measures when something happened but needs a lateness policy; arrival time measures when the system saw it. Document which one you use and what late data can change.

Why is there no company-specific bank link?

The checked public query returned zero matching Software Engineer questions. The CTA therefore opens role-wide practice. This does not imply that no Splunk questions or experiences exist anywhere on the platform. PracHub — public company and role question count

How should I demonstrate debugging strength?

Show a falsifiable hypothesis, a bounded experiment and a recovery check. For telemetry, include the possibility that missing or duplicated data makes the dashboard itself misleading before treating its graph as ground truth.

Sources & methodology

Hiring-process claims are scoped to the cited role or program. Official product documentation supplies context, while the prompts, solutions and preparation schedule are editorial. Public bank totals are dated snapshots and do not measure hiring difficulty or pass rates.

• Cisco — How We Hire, reached from Splunk careers — The Splunk How We Hire URL redirected here on the research date. General role-dependent recruiting guidance. Accessed 2026-09-10.
• Splunk Enterprise — HTTP Event Collector indexer acknowledgment — Versioned technical reference. Acceptance and indexing acknowledgment differ; deployment support must be checked. Not interview evidence. Accessed 2026-09-10.
• PracHub — Software Engineer question bank — Live role-only fallback route verified on 2026-09-10. Accessed 2026-09-10.
• PracHub — public company and role question count — Public question-list API snapshot: 0 matching questions. This is not an interview pass rate or an experience count. Interview-experience count was not available for these new drafts. Accessed 2026-09-10.

08Further reading

• Google Software Engineer Interview Guide 2026 — Compare another Software Engineer guide; its hiring process is separate.
• Microsoft Software Engineer Interview Guide 2026 — Compare another Software Engineer guide; its hiring process is separate.