Founding Software Engineer

Vigil Labs builds AI to solve markets, starting with agents that supercharge discretionary traders. To commercialize our technology, we operate an eight-figure hedge fund.

Vigil Labs is backed by Ribbit Capital, Nova, Lux Capital, SV Angel, Jack Altman, Kevin Hartz, Professor Chris Manning, the CEO of Kalshi, Cyan Banister, Stanley Tang, Karim Atiyeh, and Don Wilson, raised $29M in total seed funding with a recent round led by Ribbit to further our research and ambition to build a market-native intelligence layer where agents drive PnL.

We are based in Palo Alto, with a team spanning Citadel, Millennium, xAI, and SIG. The team includes top-ranked prediction market and crypto traders, alongside AI/ML researchers from CMU, Cornell, Stanford, and Princeton, including IMO medalists.

We are building at the frontier of markets and artificial intelligence. The work spans research, systems, and product: pioneering what new technology makes possible, building the infrastructure that makes it reliable, and putting it to work in both crypto and equities.

We want people who care deeply about that mission and want to build something consequential together. If you primarily want a predictable 9–5 software engineering job, this probably isn't the right seat. Things move quickly here. We build quickly, respond to problems with urgency, and expect people to take substantial responsibility for what they ship. Please read this document carefully before applying.

The role

You will work directly with traders, researchers, and other engineers to build Vigil's technology. That includes the systems that ingest and process information, the infrastructure that supports research and execution, and the products and agents that help us understand and act on markets.

The work crosses layers. One project might involve designing a novel data pipeline for alpha generation or debugging a distributed system. Another might involve building an evaluation framework, testing a research idea, or developing a product alongside a trader. We need engineers with enough depth to solve difficult technical problems and enough range to follow a problem beyond the part of the stack they already know.

You will own substantial pieces of this work from understanding the problem through design, implementation, deployment, and operation. You will help decide what we build, how we build it, and how we know it works.

Agents are an important part of both our product and how we operate. We want to turn more of our research and internal workflows into systems that can run autonomously. Doing that well requires strong software engineering auilding systems and products from 0 → 1.

The full file is 15.6KB at companies/vigil-labs/roles/founding-engin four PDF extraction artifacts (eight-figure, market-native, 9–5,curly quotes) and dropped the page labels. Paste the whole file into the raw description field:

Founding Engineer

Vigil Labs builds AI to solve markets, starting with agents that traders. To commercialize our technology, we operate an eight-figurehedge fund.

Vigil Labs is backed by Ribbit Capital, Nova, Lux Capital, SV Angtz, Professor Chris Manning, the CEO of Kalshi, Cyan Banister,Stanley Tang, Karim Atiyeh, and Don Wilson, raised $29M in total seed funding with a recent round led by Ribbit to further our research and ambition to build a market-native intelligence layer where agents drive PnL.

We are based in Palo Alto, with a team spanning Citadel, Millenni includes top-ranked prediction market and crypto traders, alongsideAI/ML researchers from CMU, Cornell, Stanford, and Princeton, including IMO medalists.

We are building at the frontier of markets and artificial intelligence. The work spans research, systems, and product: pioneering what new technology makes possible, building the infrastructure that makes it reliable, and putting it to work in both crypto and equities.

We want people who care deeply about that mission and want to build something consequential together. If you primarily want a predictable 9–5 software engineering job, this probably isn't the right seat. Things move quickly here. We build quickly, respond to problems with urgency, and expect people to take substantial responsibility for what they ship. Please read this document carefully before applying.

The role

You will work directly with traders, researchers, and other enginnology. That includes the systems that ingest and processinformation, the infrastructure that supports research and execution, and the products and agents that help us understand and act on markets.

The work crosses layers. One project might involve designing a novel data pipeline for alpha generation or debugging a distributed system. Another might involve building an evaluation framework, testing a research idea, or developing a product alongside a trader. We need engineers with enough depth to solve difficult technical problems and enough range to follow a problem beyond the part of the stack they already know.

You will own substantial pieces of this work from understanding the problem through design, implementation, deployment, and operation. You will help decide what we build, how we build it, and how we know it works.

Agents are an important part of both our product and how we operate. We want to turn more of our research and internal workflows into systems that can run autonomously. Doing that well requires strong software engineering and prior experience with building systems and products from 0 → 1.

There is significant room to shape the role around your strengths. The expectation is that you become someone we can trust with an important area and give substantial autonomy to move it forward.

Who you are

You have strong engineering fundamentals and evidence that you c

You have built and shipped substantial software that other people actually use or depend on. You can explain the decisions you made, the constraints you worked under, what failed, and what you changed as a result.

We expect:

• Experience owning production software. You haveing, implementing, testing, deploying, and debugging. You understandthe responsibility that comes with other people depending on your systems.
• Strong systems judgment. You can reason about date, concurrency, failure modes, and performance & you do so at a high level. You understand how a local design decision can create problems elsewhere.
• Depth in a relevant area. That could be backend or distributed systems, data infrastructure, full-stack product engineering, research infrastructure, or applied AI and agent systems.
• The ability to communicate your reasoning. You adeoff, or an unexpected result clearly enough for someone else toevaluate it.

You do not need to arrive as an expert in every part of our stack. You do need the foundations and resourcefulness to become effective in unfamiliar territory.

Experience with financial systems, real-time data, research tooling, or multi-agent systems is particularly relevant but certainly not required. So is experience building products in close contact with demanding users. We care much more about the substance of that experience than the names on your resume.

You take ownership without needing to be managed through the work

You can take a direction and a set of priorities, work out what needs to happen, and drive it to completion. We don't have the capacity or intention to continuously assign your next step, check your progress, or remind y already own. If we did, we would just do it ourselves!

A useful benchmark: we give you a problem, disappear for a few days, and come back to meaningful progress or a solved problem, with the important decisions and remaining issues clearly communicated.

You follow a problem across boundaries. If a feature fails because, you investigate it. If a deployment reveals a bad assumption, you stay with it. You don't consider your responsibility finished becauss been merged.

You also know when to escalate. A production incident, a consequetural blocker should be raised promptly. We expect independence andsound judgment about when others need to be involved. We are also a team, and do not expect you to solve everything.

You take pride in your work beyond completing an assignment

You notice when something is wrong, awkward, slow, or unnecessarisponsible for improving it.

That includes work people may never see: correcting a subtle data issue, making a deployment dependable, improving an internal tool, or removing a failure mode before it becomes an incident. Foundational work matters here as much as visible product work.

You want to understand why something is being built, who depends tes to the business. You can push back on a proposed implementation when you see a better way to achieve the outcome.

You don't need constant recognition to do careful work. You take satisfaction in building something useful and knowing it is sound.

You enjoy difficult problems and move with urgency

You should feel energized by an environment where the problems arand the opportunity is moving quickly.

You can make progress with incomplete information. You identify the important uncertainty, investigate it, and make a decision. You know when a small experiment will answer the question and when the consequences justify deeper design work.

We want meaningful improvements to our systems and product every few days. Some foundational projects take longer, but we still expect you to break them into concrete milestones and handle the entire project management cycle booking thinking is critical for our lean team.

When something breaks, you respond with urgency. You understand the impact, restore correct behavior, and address the underlying cause. You care enough about what you build to see that process through.

You think for yourself and use AI exceptionally well

We use AI extensively and expect you to become excellent at working with it. You should be curious about new capabilities, willing to change how you work, and proactive about automating repetitive effort. You should probably consider yourself part of the top 1% of Claude Code/Codex users.

You remain accountable for the result. You must understand the cons behind it, and the ways it can fail. You should be able toexplain, modify, and debug it yourself. We want people who can reason from first principles, break down a difficult problem, and direct agents effectively instead of producing slop that slows the team down.

You want to understand markets and the mission

You do not need to have any formal background in finance at all. You ideally should have some genuine curiosity about markets and a willingness to learn how our research, trading, and technology fit together.

The strongest engineers here will develop an understanding of the decisions our systems support. That context should influence what you prioritize, the questions you ask, and the failure modes you take seriously.

We want people who see a long-term opportunity to build something important at Vigil and want to become exceptional at the work required to do it.

The engineering bar

Correctness must be demonstrated. Passing tests and a successful deployment are necessary, but you also need to inspect the actual behavior. Check outputs against source data. Exercise boundaries and failure ced questions or unknown behaviors. Understand whether the systemproduces the result we intended.

Research needs rigor. Distinguish a promising example from a repeatable improvement. Be clear about the hypothesis, the baseline, the evaluation, and what the evidence supports. Investigate results that look suspiciously good.

Production ownership includes operation. Think ary, and how someone will diagnose a failure. A system should beunderstandable when it is behaving badly, too.

Good architecture supports speed over time. We value simple designs, clear interfaces, and decisions that hold up as the system grows. You should recognize when a shortcut creates recurring work and when add earned its place.

Details matter. A misleading number, an incorrect assumption, or an unreliable integration can undermine an otherwise impressive piece of engineering. Everyone is responsible for the final quality and accuracy of their output, regardless of the initial guidance they received.

How we work together

We protect deep work and minimize unnecessary coordination. Be thoughtful about interruptions. Keep important context in shared channels and durable documentation so people can find it without arranging a meeting.

Communicate progress and blockers without being chased. If somethrly. If a decision changes, make the implications clear. If something is frustrating or structurally broken, raise it before it becomes a recurring problem.

We debate hard and align fast. You should be comfortable challengect feedback, and changing your mind when the evidence warrants it. Good technical disagreement should improve the decision and lead to

We also expect engineers to improve how the organization works. Randoffs, and coordination bottlenecks are opportunities to buildbetter tooling and automation. Where agents can reliably gather context, execute work, and route decisions, we should use them. People should spend more of their attention on work that requires their judgment.

Integrity is non-negotiable. We handle sensitive information and build systems connected to real capital. Be precise about what you know, what you have verified, and what remains uncertain.

Who will struggle here

This role is likely to be a poor fit if:

• You are just looking for a 9–5 software engineering job that pay
• You need fully specified tickets and frequent direction to make
• You consistently treat problems outside your immediate componentibility.
• You are comfortable shipping code or conclusions you cannot expl
• You wait to be asked before communicating a blocker, a mistake, i>
• You are interested only in the visible or fashionable parts of e
• You want stable scope, predictable intensity, and a clean separation from the consequences of your work once the day ends.
• You have little interest in understanding markets, the business, or why the technology matters.

These expectations are central to how we work. We want candidates to make an informed decision about whether this environment suits them.

What success looks like

You become someone the team can trust with difficult, important problems and have confidence in the result and the rigor behind it.

The systems you own work reliably, and you can show the evidence.se what you build. You make sound technical decisions and improvethem as you learn.

You ship meaningful progress at a fast cadence. You catch issues, resolve failures, and communicate clearly. The same problems require less attention over time because you address their causes.

Your presence increases the team's capacity and the output of oureammates spend less time assigning steps, checking status, andrepairing incomplete work. You earn greater responsibility through the quality of your judgment and execution.

We truly believe in Jeff Bezos' quote: "We want to fight entropy.ly go up." We expect each person we hire to make the teamstronger.

How we hire

Our process is designed to evaluate who you are as an engineer anout technical ability, autonomy, judgment, persistence, and the care you put into the result.

The proposed process includes:

1. A short written application describing your work and interest in
2. A conversation with the team about your experience, technical de
3. A substantive engineering take-home with a defined time box and
4. A paid, in-person work trial involving a problem we're tackling on the job and meaningful ownership.
5. References from people who have worked closely with you.

Exercises may differ depending on your strengths across systems, neering, but the standard of rigor and ownership will remainconsistent.

Use AI and agents during the engineering exercises. We will assesify their output, and respond when something fails. You must be able to explain and modify the work you submit.