
FDE Data Engineer - Space
Posted 6 days ago
The role in short
Deploy, integrate, and operate the UDS Data Capability platform in government environments, building data pipelines and governance solutions while working directly with mission stakeholders.
EMPLOYER IS A CONTRACTOR FOR THE U.S. GOVERNMENT. THIS POSITION WILL REQUIRE U.S. CITIZENSHIP.
Role Description
This is a forward-deployed engineering role. You'll work shoulder-to-shoulder with mission heroes: the users, operators, and program engineers who run real workloads in real DoD environments. You'll help take UDS Data Capability from "deployable" to "running in production under classification." You will deploy, integrate, and operate our data stack in the mission hero's environment alongside senior engineers, then carry what you learn back into the product so the next engagement is easier.
The scope of this work varies by engagement. Some programs require standing up a governed data platform to centralize sensor or operational data from known sources, where the problem is well-defined and the priority is building and shipping. Others involve consolidating data across hundreds of interconnected government systems of record with overlapping schemas, deeply interdependent data flows, and significant architectural complexity. You should be comfortable building independently against defined problems and growing into more ambiguous, complex engagements over time.
Forward-deployed means aligned with the mission hero, not always on a plane. Most of the work is remote. You'll travel to sites when the engagement calls for it: initial standup, integration work, incident response, training and knowledge transfer. The rest of the time, you'll be on a video call or in a shared chat with that same mission hero. The role is defined by the relationship with the mission hero, not by where you sit.
You are a data engineer who can build across the breadth of a data platform (storage, ingestion, streaming, governance, and access) and deliver working solutions in constrained, mission-critical environments.
Responsibilities
- Deploy and configure UDS Data Capability in the mission hero's environment. Stand up the UDS Store (Iceberg, Rook/Ceph, pgvector, Postgres), wire up UDS Transit for air-gap data movement, configure UDS Govern policies (Pepr/Lula), and integrate UDS Connect (Strimzi/Kafka) where streaming or legacy connectors are required.
- Build and support integrations with existing mission systems. Connect UDS Data Capability to legacy databases, flat-file drops, SOAP/REST endpoints, message buses, existing object storage, and identity providers (Keycloak, mission-side SSO). Prior experience integrating with these types of systems is more relevant than experience building on them.
- Contribute to mapping complex data landscapes. Some engagements involve hundreds of interconnected systems of record with overlapping schemas and deeply interdependent data flows. You'll help trace how data moves across systems and identify dependencies alongside senior engineers and government stakeholders.
- Build pipelines that move data through classification boundaries, including ingestion, transformation, catalog registration, model/dataset packaging via Zarf, cross-domain transit, and eventual consistency across DDIL conditions.
- Implement data provenance, lineage, and governance practices. Track where data came from, how it transformed, and who can access it.
- Operate what you deploy. Day-2 ownership includes capacity, performance, backup/restore (Velero), observability (Vector/Loki), incident response, and upgrade paths. Hand off to the mission hero's ops team once it's stable.
- Generate accreditation artifacts, including STIG evidence, cATO documentation, FIPS validation notes, and policy mappings. You produce the evidence the mission hero's ISSM/ISSO needs to run this in IL4/IL5.
- Contribute field feedback back to product and engineering. File issues, write postmortems, and surface what's working and what's breaking in the mission environment.
- Support training and knowledge transfer. Contribute to runbooks, architecture docs, and working sessions that leave the mission hero's team self-sufficient.
The listed responsibilities are not exhaustive and additional responsibilities may be assigned based on the evolving needs of the organization. We are seeking a dynamic individual who is able to adapt and take on new responsibilities as they arise.
Required Qualifications
Data engineering breadth
- Unstructured data at scale. Experience storing and querying large unstructured datasets using data lake architectures. Spark experience preferred.
- Streaming & integration. Experience with stream processing infrastructure (Kafka, Redpanda, Flink, or equivalent) and bridging data from heterogeneous sources into modern pipelines.
- Data warehousing. Open-source data warehousing platform experience. These environments do not support proprietary platforms, so you need to be comfortable building without them.
- Pipelines & orchestration. Airflow, Dagster, Argo Workflows, or similar. Comfort building, scheduling, monitoring, and recovering production data pipelines.
- Data modeling & SQL. Fluent in SQL. Comfortable designing schemas for both analytical and operational workloads.
Open-source orientation. You are comfortable building on open-source tooling and contributing back to it.
What "forward-deployed" requires
- U.S. citizenship and the ability to obtain and maintain a DoD security clearance. Clearance sponsorship available for the right candidate.
- Comfort working directly with mission heroes and government stakeholders. Clear communication with both technical and non-technical audiences.
- Comfort with periodic on-site work, sometimes for days at a stretch, and equal comfort working remotely.
- Bias toward delivery. Preference for shipping a working integration over perfecting a design that hasn't met a real workload.
- Self-direction. You will encounter environments and problems that are not yet documented and will need to work through them independently.
Preferred Qualifications
- Data provenance, lineage, and governance. Experience with lineage tracking, data catalogs, provenance systems, or governance frameworks. Depth here will be weighted heavily.
- DoD or defense program experience.
- Active Secret clearance (or higher).
- Lakehouse & storage: Apache Iceberg (or Delta/Hudi), object storage (Ceph/S3-compatible), Postgres (including extensions like pgvector), columnar/OLAP engines (Trino, DuckDB, ClickHouse, Spark SQL).
- Change Data Capture: Debezium or similar CDC patterns.
- Governance, catalog & access: REST catalogs (Iceberg REST, Polaris/Gravitino/Nessie family), ABAC/RBAC patterns, OIDC/OAuth, lineage and audit.
- Kubernetes awareness. Deep K8s expertise is not required; general familiarity with deployments, operators, and how applications run on Kubernetes is valuable.
- Linux fundamentals, container runtime behavior, networking, TLS, secrets management.
- IaC (Terraform, Pulumi, or similar) and GitOps patterns (Flux, ArgoCD).
- Familiarity with the CNCF ecosystem, including the distinction between foundation projects and single-vendor projects.
- AI/ML awareness. General understanding of how data infrastructure supports model training, versioning, provenance, and AI operations.
- Familiarity with Air Force or Space Force systems of record (e.g., MILPDS, ARMS) and how data flows between them.
You do not need to meet every preferred qualification. You do need to be credible across the core data engineering requirements.
Prep for this interview
4 questions likely to come up at Defense Unicorns, each matched to a line in this posting.
- 1Data and SQL
They wrote: “Data modeling & SQL. Fluent in SQL. Comfortable designing schemas for both analytical and operational workloads.”
Write a query that finds each customer's first and most recent order.
How to answer
Why they ask: A quick check that you're comfortable with grouping, joins and window functions.
- Clarify the tables and what counts as an order (cancelled ones?)
- Use MIN/MAX with GROUP BY, or ROW_NUMBER() if you need the whole row
- Handle ties on the same timestamp, and customers with no orders
- Explain how you'd test it on a few known customers
Tip: Say what you'd check in the data before writing the query: duplicates, time zones, nulls.
- 2Cloud, deployment and security
They wrote: “U.S. citizenship and the ability to obtain and maintain a DoD security clearance. Clearance sponsorship available for the right candidate.”
The customer's security team sends a 200-question review. How do you handle it?
How to answer
Why they ask: Security reviews often block deals. FDEs help get through them.
- Start from your company's standard answers (SOC 2 report, past reviews)
- Answer clearly; don't oversell
- Bring in your security team for anything you're unsure of
- Keep the new answers for the next customer
Tip: Reuse past answers, flag honest gaps, and offer a call for the hard questions.
- 3Discovery and scoping
They wrote: “Comfort working directly with mission heroes and government stakeholders. Clear communication with both technical and non-technical audiences.”
A customer says “we want AI in our claims process.” What do you ask in the first meeting?
How to answer
Why they ask: Most FDE work starts this vague. They want to hear you find the real problem before you pick a tool.
- Map the current process: who touches a claim, in what order, with which systems
- Find the slowest or most error-prone step and ask what it costs them
- Agree on one measurable goal (for example time per claim, or error rate)
- Ask what data you can access, and who signs off on security
Tip: Ask about the work, not the technology. Who does it today, how long it takes, what a mistake costs, and how they'd know it got better.
- 4Integrations and APIs
They wrote: “Streaming & integration. Experience with stream processing infrastructure (Kafka, Redpanda, Flink, or equivalent) and bridging data from heterogeneous sources into modern pipelines.”
Walk me through connecting our product to a customer's internal system that has no documentation.
How to answer
Why they ask: This happens weekly in the job. They want a calm, step-by-step method.
- Find who owns the system and get read access to a test environment
- Watch real traffic or logs to learn the data shapes
- Build a thin adapter with logging around every call
- Agree on how failures get reported, and who fixes what
Tip: Talk about finding the owner of the system first. The code is the easy part.
Not the one? Get the next one by email
New roles land here every day. Pick what you want to hear about.
Want the job, not just the posting? Learn how FDEs work.
FDE Info is our free weekly newsletter for forward deployed engineers: tools, field notes from real deployments, and how FDE teams hire and pay.
Free. One email a week. Unsubscribe in one click.