Systems Engineer Intern / Co-op

About the role

Dedalus Labs builds persistent computers for AI agents. Our flagship product, Dedalus Machines, gives agents an isolated environment where they can run software, keep files and state, and work over time.

You'll implement and debug the software that creates, schedules, and runs Machines. Projects can involve the control plane, Kubernetes controllers and operators, or our Rust virtual machine monitor (VMM), the software that runs virtual machines. We want someone curious about how a system behaves when requests overlap, a node fails, or a process stops halfway through an operation.

About the internship

This is an evergreen opening. We review applications on an ongoing basis. Internships and co-ops last 3-9 months, depending on your school and co-op program.

Show us that you can learn something difficult, finish a working version, and improve it when the first approach fails. Prior production ownership is not required. You should be able to explain your project’s hardest bug, limits, and your contribution.

Work you might take on

• Kubernetes and orchestration: Improve a controller or operator and test how it reconciles desired and actual resource state. Investigate scheduling, pod lifecycle, networking, or recovery after a node failure.

• Control-plane correctness: Fix a resource-lifecycle bug involving retries, cancellation, concurrent requests, or cleanup. Write a test that reproduces the failure and verifies the repair.

• Runtime and storage: Improve VM startup, snapshot restore, memory use, or an I/O path. Establish a baseline and measure the change on the same workload.

• Failure testing: Inject a process crash, delayed response, or interrupted operation to expose an ordering or recovery assumption. Explain which guarantees the test establishes.

Finish with tested code, an explanation of your decisions, and a handoff another engineer can use.

What we look for

You can build and debug software in Rust, Go, C, C++, or a similar language. Rust is preferred for runtime work. You understand the memory, concurrency, data structures, and operating-system behavior your project depends on.

Kubernetes experience is especially relevant to control-plane work: controllers, operators, reconciliation, scheduling, networking, and resource lifecycles. For runtime work, relevant projects include a storage engine, networking tool, virtual machine, compiler, or operating-system component. Depth in either area is welcome.

Coursework, research, employment, open source, and independent projects all count. Explain what you personally implemented and learned. Experience at a big tech company or on another large, fast-moving codebase is a plus, not a requirement.

You understand when to use unit, integration, end-to-end, and property-based tests, and what each can and cannot establish. You choose efficient ways to verify a change, test invariants and failure cases, and make failures reproducible. Experience with formal verification or model checking is a plus.

When stuck, you narrow the problem, read source or documentation, and run an informative experiment. You ask for help with evidence, act on feedback, and finish the work.

You can use AI tools. You must understand, test, and correct the code you submit.

This internship may be a poor fit if

• You want a tutorial with every implementation step supplied.

• You cannot explain or debug the code in the project you submit.

• You lose interest after the first successful run, before checking failure cases or documenting what remains incomplete.

Logistics

40 hours per week, five days onsite in San Francisco. Relocation assistance may be available. Strong interns may be considered for full-time roles.

Show us your work

Show us a controller, service, runtime, storage component, or other systems project you built, and a difficult correctness or performance problem you investigated. They can come from the same project. Use existing work.

• Work: Show the code, demo, design, or result. Explain what you personally owned, what you reused, and one decision that made the result better or simpler.

• Investigation: Describe the symptom, your first explanation, the evidence that changed your thinking, and how you established the result. Include the workload or users involved and any important limitations.

• Engineering judgment: Link a public PR or commit, by you or anyone else, that you find interesting. Explain why it is an example of quality software engineering in the context in which it was written.

• Writing: Share one piece of writing you care about as a separate, required sample. Any medium or length is welcome. Tell us why you wrote it, who it was for, and what you wanted to communicate. Looking back, what works well and what would you change? We care about the quality of your thinking and writing, and your reflection on the work. Link it or paste a redacted excerpt. Explain your contribution and any coauthors or AI assistance.

Employment, open source, research, coursework, and independent projects all count. Links to your technical work or existing demos are optional but highly recommended so we can evaluate your body of work. Redacted excerpts are welcome for private work.

Tell us which problem in this role you want to own and why.

You can also explore our engineering tooling: Bessemer (BSMR) and Hollywood .