Implement compiler for custom language
Design and implement a simple compiler/interpreter
Goal
Design and implement a small compiler/interpreter for a bespoke toy language in your preferred programming language. Explain:
-
Your object-oriented design (key classes and their responsibilities).
-
The compilation pipeline (from source to execution and/or code generation).
-
How you would systematically detect and fix bugs.
Assumptions and scope (you may adapt as needed)
-
Target language: a small, expression-oriented language (call it MiniLang) with integers, booleans, variables, arithmetic, comparisons, if/else, while, let bindings, functions, and print.
-
Implementation language: your choice (example below uses Python, but any OO language is fine).
MiniLang sketch
-
Types: int, bool.
-
Statements: let, assignment, print, if/else, while, block, function def, return.
-
Expressions: literals, variables, unary (!, -), binary (+, -, *, /, <, >, ==, &&, ||), call.
-
Example:
let x = 2 + 3 * 4;
if (x > 10) { print(x); } else { print(0); }
Deliverables
-
A short description of your OO architecture.
-
The compilation pipeline with key phases and invariants.
-
Minimal code skeletons or pseudocode for lexer, parser, AST, and interpreter or bytecode VM.
-
Testing and debugging strategy.
Constraints & Assumptions
-
Preserve the scope, facts, inputs, and requested outputs from the prompt above.
-
If the prompt leaves a detail unspecified, state a reasonable assumption before relying on it.
-
Keep the answer interview-ready: concise enough to present, but concrete enough to implement or evaluate.
Clarifying Questions to Ask
-
Clarify users, core use cases, read/write patterns, scale, latency, availability, and data retention.
-
State explicit assumptions before making sizing or architecture decisions.
-
Prioritize the functional path first, then address reliability, security, observability, and rollout.
What a Strong Answer Covers
-
A scoped requirements summary with concrete non-goals and success metrics.
-
API, data model, architecture, consistency, capacity, and operations.
-
Reasoned trade-offs among simple and scalable designs, including bottlenecks and failure modes.
-
A validation, monitoring, migration, and launch plan appropriate for the risk level.
Follow-up Questions
-
What breaks first at 10x traffic or data volume?
-
How would you degrade gracefully during dependency failures?
-
What metrics and alerts would prove the design is healthy after launch?