Applied intuition·Software Engineer·Onsite - System Design / Architecture·Senior

SeniorPrefer not to say

Jun 2026

Summary

System design round at Applied Intuition for a software engineer role. One big open-ended question about building a schema catalog service, and the whole session was basically a design discussion. Pretty intellectually interesting but also a lot of ground to cover in one go.

Questions Asked (1)

Design a service that lets users query the contents of a large collection of schema files (Avro, Protobuf, JSON Schema, SQL DDL, etc.). The service should support queries like 'find all schemas with a field named user_id of type long' or 'find schemas that reference type Address'. Walk through parsing and normalization, storage choices, query API design, keeping the catalog fresh when files change, and scaling to millions of schemas.

System DesignData ModelingTechnical Trade-offs

Author's notes

This one is genuinely hard to scope in real time because the prompt is almost entirely open.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and scale, then walk through the pipeline: parsing heterogeneous schema formats into a normalized intermediate representation, storing both the raw schemas and extracted metadata in a searchable index, designing a query API that supports field-level and reference-level lookups, and handling updates via change detection. Emphasize trade-offs between consistency, latency, and cost at scale, and propose a concrete architecture with components like a parser service, metadata store, and search index.

Pro tip: Anchor your design around a normalized schema graph model—this makes cross-format queries trivial and future-proofs the system for new schema languages. Also, discuss how you'd handle schema evolution and versioning, as interviewers often probe for real-world robustness.

1. Clarify Requirements and Scope

Ask about query patterns, latency/consistency needs, schema formats, update frequency, and scale (millions of schemas, fields per schema). Define what 'reference' means (e.g., type dependencies, foreign keys).

2. Parsing and Normalization

Design a pluggable parser per format that outputs a common intermediate representation (IR) capturing entities, fields, types, and references. Normalize type names (e.g., long vs int64) and handle nested/complex types.

3. Storage and Indexing

Store raw schemas in object storage for durability, and extracted metadata in a search-optimized store (e.g., Elasticsearch, or a graph DB for references). Denormalize fields and references into inverted indexes for fast lookups.

4. Query API Design

Expose a declarative query DSL or REST API supporting filters like field name, type, and references. Consider pagination, sorting, and aggregation. Optionally provide a GraphQL endpoint for flexible queries.

5. Freshness and Scaling

Implement change detection via webhooks, polling, or file system watchers; process updates through a queue to re-parse and re-index incrementally. Scale by sharding the index, caching hot queries, and using async processing for bulk updates.

Key Points to Mention

Intermediate representation (IR) for cross-format normalization and querying
Choice of storage: inverted index (Elasticsearch) vs. graph database for references
Incremental indexing and change data capture (CDC) for freshness
Query API design: filters, pagination, and support for complex queries
Sharding and partitioning strategies for millions of schemas
Trade-offs: consistency vs. latency, cost of re-indexing, and schema evolution

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