Software Engineer, Terminal Interface

Normal Computing | Build with Us

Normal is an applied AI company solving the hardest problems in AI and silicon. We build foundational hardware and software for the semiconductor industry, critical AI infrastructure, and the broader systems that power our world, in partnership with the world's most advanced institutions. We work as one team across New York City, Silicon Valley (Mountain View), London, Copenhagen, and Seoul.

Normal CLI is how semiconductor engineers do AI-assisted verification work. It is a large interactive terminal application, built in Python and Textual, that design verification engineers keep open all day, usually in environments we do not control: remote workstations inside chip companies, SSH sessions, tmux, Windows and WSL. Our users are accustomed to terminal products, and for many of them this is the first and only surface of Normal they will use.

We expect that to remain true.

We are hiring the engineer who will own it as a product: product ionizing what began as a research tool and giving it a dedicated end-user focus. You will own the interaction model and the information design — how people enter and edit instructions, how a long agent run stays legible while it streams, how tool use and proposed changes are presented for review, and how work is interrupted, resumed, and recovered after a failure.

You will also own the local session client beneath it, and be a leading voice in the client API the rest of our product is built on.

The boundaries matter here. Our ML and research engineers keep the harness — the skills, tools, hooks, and model behavior that make the agent good at chip verification. You take the application those capabilities reach users through. You will sit on the product engineering team that also builds our desktop workbench, our web product, and our agent orchestration, so the terminal moves into the same product as everything else, with the same vocabulary, state, and quality bar.

On any given day, you might rework how a long verification run folds and summarizes itself so an engineer can read it at a glance, chase down why text input breaks under one customer's terminal and IME combination, turn a recurring support thread into a reusable component and a snapshot test, or push back on a runtime event shape that cannot be rendered well.

• The terminal application:
  Information architecture and interaction across commands, navigation, input and editing, streamed output, progress, review, interruption, recovery, empty states, and errors that tell the user what to do next.

• Cross-platform behavior:
  Correct, fast behavior across terminals, shells, multiplexers, remote sessions, macOS, Linux, Windows and WSL, non-English input and IMEs, and constrained customer environments.

• The client boundary:
  The local session client, and a leading voice in the structured-event interface it consumes. You shape what the runtime emits so the UI does not have to infer intent from formatted text.

• Standards other contributors build against:
  Define the command, picker, progress, output, and review patterns that research and product engineers use when they add domain workflows, and keep the experience coherent as they do.

• Responsiveness under load:
  Streaming, cancellation, concurrency, and event-loop behavior for work that runs for a long time and must stay interruptible and understandable throughout.

• A coherent product across surfaces:
  Shared terminology, state, authentication, and handoffs between the terminal and the rest of our EDA product, so users moving between them do not have to learn two systems.

• Architecture:
  Evolve a large Textual application toward reusable components and a clear line between product UI, domain logic, and runtime concerns.

• Confidence to change it:
  Snapshot and visual-regression coverage, packaging, installation, self-update, and the tests that make it safe to change an interactive application people depend on.

• 4+ years of software engineering experience, including significant time building and maintaining an interactive terminal application, TUI, or comparably rich local client — not command wrappers.

• Experien…