Platform Engineer Intern / Co-op

Dedalus Labs; San Francisco (CA); On-site; USD 30,000 - 42,000; Full time

Benefits offered by this job

Meals provided

Office benefits

Relocation support

Visa support

Job summary

Dedalus Labs in San Francisco, CA is offering an internship to work on our platform tooling. You will help improve CI/CD workflows, build systems, and observability across our service stack.

Requirements include proficiency in Python, TypeScript, Go, or Rust, plus experience with Git and Linux. Coursework, research, or open-source work counts towards qualifications. This role emphasizes hands-on delivery and learning. 40 hours/week onsite.

Qualifications

• Proficient in writing and debugging software in Python, TypeScript, Go, or Rust.
• Experience with Git and Linux environments.
• Able to explain research or project work and talk about debugging approaches.

Responsibilities

• Improve CI/CD and builds, including GitHub Actions workflows and test reliability.
• Automate release pipelines and provide traceability from source to build.
• Enhance observability by connecting logs, metrics, traces, and errors across services.
• Improve telemetry ingestion, batching, buffering, and filtering to keep data affordable.

Skills

Python

TypeScript

Go

Rust

Git

Linux

Education

Pursuing CS/Engineering degree

Tools

GitHub Actions

Build systems

Observability tools

Grafana

Datadog

Sentry

OpenTelemetry

Kubernetes

Job description

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 improve the internal platform engineers use to build, test, release, and understand our software. This means GitHub Actions, build systems, release pipelines, and observability: collecting and connecting logs, metrics, traces, and errors so we can follow an operation across the platform and turn failures or regressions into specific fixes.

Our open-source tooling includes Bessemer (BSMR), our build system, and Hollywood, which generates GitHub Actions from typed TypeScript definitions and runs actions locally.

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

• CI/CD and builds: Improve a GitHub Actions workflow, investigate a flaky test, reduce runner queue time, or fix a build-cache miss. Measure the effect on build time and reliability.

• Release pipelines: Automate artifact publishing, staging checks, release promotion, or rollback verification. Make it possible to trace a running version back to its source and build.

• Observability: Instrument a service and connect its logs, traces, metrics, and errors using consistent request, resource, and release identifiers. Build a dashboard or alert that helps an engineer identify a cause and take action.

• Efficient ingestion: Improve telemetry collection, batching, buffering, or filtering. Measure ingestion delay, dropped events, and resource use so collecting more useful data stays affordable.

Finish with tested changes, documentation, and evidence that the workflow is faster, more reliable, or easier to diagnose.

What we look for

You can write and debug software in Python, TypeScript, Go, Rust, or a similar language, and work comfortably with Git and Linux. Show us a CI workflow, release pipeline, developer tool, or observability project you built or improved. Coursework, research, open source, and independent projects count.

Experience with GitHub Actions, build systems, release automation, or logs and observability is especially useful. Grafana, Datadog, Sentry, OpenTelemetry, and similar tools are relevant. Explain how you used the data to diagnose a problem or improve a decision. Containers, Kubernetes, and infrastructure as code are useful supporting skills.

Experience at a big tech company or on another large, fast-moving codebase is a plus, not a requirement. We value what it taught you about code review, shared tooling, release discipline, and making changes other engineers can trust.

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.

We evaluate your work relative to your experience and opportunities. A degree or particular employer is not required.

This internship may be a poor fit if

• You want to configure tools without understanding the workflows and failure modes they support.

• You need every next step supplied before investigating a failed build, release, or missing signal.

• You call a pipeline or dashboard finished without checking whether another engineer can use it to ship or diagnose a problem.

Logistics

40 hours per week, five days onsite in San Francisco. Meals and office benefits included. Relocation and visa support may be considered individually. Strong interns may be considered for full-time roles.

Show us your work

Show us a build or release workflow, developer tool, or observability project you improved, and a difficult 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.