← Oracle Interview Insights

Oracle·Software Engineer·Technical Phone Screen·Intermediate

Intermediate
Jun 2026

Summary

Oracle SWE interview with a meaty system design coding question around log parsing and querying. Felt more like a take-home problem squeezed into a live session, lots of follow-up angles to cover.

Questions Asked (1)

Q1

Build a log parser that converts raw log lines into structured records with timestamp, level, and message fields. Then design an API with an insert method and a query method that filters by time range and optionally by log level. Walk through timestamp parsing, timezone handling, malformed line handling, large-scale data strategies, and complexity analysis. Include basic tests.

System DesignAPI & IntegrationsAlgorithms & Data Structures
Author's notes

This was a lot to fit into one question.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and assumptions, then walk through the parser design covering timestamp parsing, timezone normalization, and malformed line handling. Next, design the API with insert and query methods, discussing data structures and indexing for efficient time-range and level filtering. Finally, address large-scale strategies, complexity analysis, and outline basic tests.

Pro tip: Demonstrate production awareness by discussing how to handle timezone ambiguities (e.g., DST transitions) and proposing a dead-letter queue for malformed lines to avoid data loss. Also, mention that you would validate assumptions with the interviewer before diving deep.

1. Clarify Requirements and Assumptions

Ask about log format, expected volume, query patterns, and whether timestamps include timezone info. Confirm assumptions about malformed lines and performance goals.

2. Design the Parser

Outline parsing logic: extract timestamp, level, and message. Discuss timestamp parsing (e.g., ISO 8601, custom formats), timezone handling (normalize to UTC), and malformed line handling (skip, log error, or dead-letter queue).

3. Design the API and Data Structures

Define insert(record) and query(startTime, endTime, level?). Choose data structures (e.g., sorted list, balanced BST, or time-partitioned storage) and indexing (e.g., composite index on time and level) to support efficient queries.

4. Address Large-Scale and Complexity

Discuss strategies for large-scale data: partitioning by time, using distributed storage (e.g., Cassandra, Elasticsearch), and trade-offs. Analyze time/space complexity of insert and query operations.

5. Outline Basic Tests

Propose unit tests for parsing valid/invalid lines, timezone conversions, and API methods. Include edge cases like empty logs, boundary times, and level filtering.

Key Points to Mention

  • Timestamp parsing: support multiple formats (ISO 8601, RFC 3339) and use robust libraries; handle missing timezone by assuming UTC or configurable default.
  • Timezone handling: normalize all timestamps to UTC for consistency; be aware of DST transitions and ambiguous local times.
  • Malformed line handling: log errors, skip lines, or route to a dead-letter queue; ensure parser resilience.
  • API design: insert should validate and store records; query should accept start/end times and optional level, returning matching records efficiently.
  • Large-scale strategies: time-based partitioning, indexing, and distributed systems; consider write-heavy vs read-heavy workloads.
  • Complexity analysis: insert O(log n) with balanced tree or O(1) with append-only log; query O(log n + k) where k is result size; discuss trade-offs.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.