Forward Deployed Engineer, AI
Apple
1 day ago
Remote
Worldwide
The Maps Client Quality Engineering Intelligence (QEI) team builds AI-native tooling used every day by the Maps Client Quality Engineering organization — QE leads, SDETs, and engineering managers. Our work lands directly in their triage sessions, release readiness reviews, and on-call rotations.\\n\\nAs a Forward Deployed Engineer on QEI, you will stay in tight communication with the engineers and leads we serve — learning their workflows, surfacing where they get stuck, and identifying which tools would change their day — then translating what you learn into the tools you build and ship. Adoption is what we optimize for, measured over a release cycle rather than at merge time.\\n\\nYou will partner with Maps Client Quality Engineering leads and SDETs, SWE platform teams, Maps Eval, Release Engineering, and Apple"s AI/ML platform organization.
The Quality Engineering Intelligence (QEI) team owns how Maps Client Quality Engineering standardizes AI integration across the organization. We build the shared platform, set the patterns, and work alongside QE Leads, SDETs, and engineering managers to bring AI capabilities into the workflows they run every day — so AI adoption happens in a consistent, supported way rather than as one-off experiments scattered across teams. \\n\\nOur mandate is to keep the organization ahead of where the industry is going on AI engineering. We evaluate emerging models, agents, and tooling patterns as they appear, harden the ones that prove out into reusable building blocks, and graduate field-tested work back into the platform so the rest of the team can build on top of it.\\n\\nWho thrives in this role?\\n\\n- Engineers who want to own a product end-to-end — discovery, build, ship, adoption — rather than specialize in one phase.\\n\\n- Engineers who enjoy understanding how other engineers work and what would change their day, and who treat that discovery as part of the job rather than a handoff from someone else.\\n\\n- Engineers comfortable starting from observation rather than a written spec, and revising direction as they learn.\\n\\n- Engineers with applied AI experience who treat the model as a tool, not the product. You ship Python and TypeScript every week and reach for an LLM only when it is the right answer.\\n\\n- Engineers who stay calm under release pressure and surface risks early, before they become blockers.\\n\\n- Engineers who communicate clearly across engineering teams, leadership, and the QE org they are embedded with.\\n\\n
Stay close to the users. Build a working understanding of how a triage lead handles a presubmit session,how a release readiness review runs, where SDETs lose time on flaky tests. Earn that understanding through review attendance, shared channels, and one-on-ones — not by waiting for a spec.\\n\\nChoose what to build. The most consequential decision is what to take on next. Most ideas will not make the cut. Picking well — and being willing to drop work that is not landing — is the core of the role.\\n\\nBuild end-to-end. Python services (FastAPI, aiohttp), Next.js, and TypeScript front-ends, RAG pipelines, agents, and MCP integrations. End-to-end includes auth, deployment, observability, and the rollback path.\\n\\nMake sound trade-offs. Choose between scope, speed, and quality under release pressure. Adjust plans early to protect delivery rather than late to explain a miss.\\n\\nStay hands-on in the code. Read and review across services and front-ends. Step in directly when progress or clarity depends on it, even on code you do not own.\\n\\nStay with the work after launch. Adoption is the deliverable. After a release cycle, the question is who is using it and how often. If the answer is no one, you go back and find out why.\\n\\nGeneralize what works. Patterns proven in the field become shared building blocks — agents, skills, MCP servers, and services that other tools depend on. You own that path back to the platform.\\n\\n\\n
5+ years shipping production software end-to-end — backend, frontend, or both, used by real users(internal or external).\\n\\nStrong Python and TypeScript. You can move between FastAPI / aiohttp and Next.js without a warm-up.\\n\\nA specific, recent example of a tool or feature you built that another team picked up unprompted — you can describe the team, the problem, and how adoption played out, in terms consistent with your prior confidentiality obligations.\\n\\nA specific, recent example of a feature you decided not to build, and the reasoning behind it. Demonstrated engineering judgment in scoping — including descoping or deprecating features that did not meet adoption goals.\\n\\nComfort working from observation rather than from a written spec. You have done at least one project where you started by learning the workflow first, not by reading a doc.\\n\\nWorking knowledge of LLM application building — you have shipped something using an LLM API, written prompts that mattered, and debugged a retrieval-augmented system that was returning the wrong thing.\\n\\nYou can describe one time you removed or retired a feature you personally built, because adoption did not justify keeping it.\\n\\nBachelor"s or Master"s degree in Computer Science or equivalent, with 3-6 years of industry experience in software development.
Experience as a Forward Deployed Engineer, Solutions Engineer, Applied AI Engineer, internal tools engineer, or developer experience engineer — any role where you owned both the build and the adoption.\\n\\nYou have built and shipped MCP servers, agents, or RAG systems against an internal knowledge base.\\n\\nBackground in QE, developer tooling, internal platforms, or test infrastructure — XCTest / XCUI experience is a plus, but workflow understanding matters more than framework familiarity.\\n\\nComfort with Apple-internal engineering platforms (Radar, Stash, Arches, Twist) or a track record of getting fluent in unfamiliar enterprise tooling fast.\\n\\nExperience with vector databases (LanceDB, Milvus, Pinecone), event-driven systems (Redis, RQ, Celery), and containerized deployments (Docker, Kubernetes / Helm).\\n\\nA public artifact — a tool, an internal post, a talk, a write-up — that demonstrates how you think, not just what you can do.
The Quality Engineering Intelligence (QEI) team owns how Maps Client Quality Engineering standardizes AI integration across the organization. We build the shared platform, set the patterns, and work alongside QE Leads, SDETs, and engineering managers to bring AI capabilities into the workflows they run every day — so AI adoption happens in a consistent, supported way rather than as one-off experiments scattered across teams. \\n\\nOur mandate is to keep the organization ahead of where the industry is going on AI engineering. We evaluate emerging models, agents, and tooling patterns as they appear, harden the ones that prove out into reusable building blocks, and graduate field-tested work back into the platform so the rest of the team can build on top of it.\\n\\nWho thrives in this role?\\n\\n- Engineers who want to own a product end-to-end — discovery, build, ship, adoption — rather than specialize in one phase.\\n\\n- Engineers who enjoy understanding how other engineers work and what would change their day, and who treat that discovery as part of the job rather than a handoff from someone else.\\n\\n- Engineers comfortable starting from observation rather than a written spec, and revising direction as they learn.\\n\\n- Engineers with applied AI experience who treat the model as a tool, not the product. You ship Python and TypeScript every week and reach for an LLM only when it is the right answer.\\n\\n- Engineers who stay calm under release pressure and surface risks early, before they become blockers.\\n\\n- Engineers who communicate clearly across engineering teams, leadership, and the QE org they are embedded with.\\n\\n
Stay close to the users. Build a working understanding of how a triage lead handles a presubmit session,how a release readiness review runs, where SDETs lose time on flaky tests. Earn that understanding through review attendance, shared channels, and one-on-ones — not by waiting for a spec.\\n\\nChoose what to build. The most consequential decision is what to take on next. Most ideas will not make the cut. Picking well — and being willing to drop work that is not landing — is the core of the role.\\n\\nBuild end-to-end. Python services (FastAPI, aiohttp), Next.js, and TypeScript front-ends, RAG pipelines, agents, and MCP integrations. End-to-end includes auth, deployment, observability, and the rollback path.\\n\\nMake sound trade-offs. Choose between scope, speed, and quality under release pressure. Adjust plans early to protect delivery rather than late to explain a miss.\\n\\nStay hands-on in the code. Read and review across services and front-ends. Step in directly when progress or clarity depends on it, even on code you do not own.\\n\\nStay with the work after launch. Adoption is the deliverable. After a release cycle, the question is who is using it and how often. If the answer is no one, you go back and find out why.\\n\\nGeneralize what works. Patterns proven in the field become shared building blocks — agents, skills, MCP servers, and services that other tools depend on. You own that path back to the platform.\\n\\n\\n
5+ years shipping production software end-to-end — backend, frontend, or both, used by real users(internal or external).\\n\\nStrong Python and TypeScript. You can move between FastAPI / aiohttp and Next.js without a warm-up.\\n\\nA specific, recent example of a tool or feature you built that another team picked up unprompted — you can describe the team, the problem, and how adoption played out, in terms consistent with your prior confidentiality obligations.\\n\\nA specific, recent example of a feature you decided not to build, and the reasoning behind it. Demonstrated engineering judgment in scoping — including descoping or deprecating features that did not meet adoption goals.\\n\\nComfort working from observation rather than from a written spec. You have done at least one project where you started by learning the workflow first, not by reading a doc.\\n\\nWorking knowledge of LLM application building — you have shipped something using an LLM API, written prompts that mattered, and debugged a retrieval-augmented system that was returning the wrong thing.\\n\\nYou can describe one time you removed or retired a feature you personally built, because adoption did not justify keeping it.\\n\\nBachelor"s or Master"s degree in Computer Science or equivalent, with 3-6 years of industry experience in software development.
Experience as a Forward Deployed Engineer, Solutions Engineer, Applied AI Engineer, internal tools engineer, or developer experience engineer — any role where you owned both the build and the adoption.\\n\\nYou have built and shipped MCP servers, agents, or RAG systems against an internal knowledge base.\\n\\nBackground in QE, developer tooling, internal platforms, or test infrastructure — XCTest / XCUI experience is a plus, but workflow understanding matters more than framework familiarity.\\n\\nComfort with Apple-internal engineering platforms (Radar, Stash, Arches, Twist) or a track record of getting fluent in unfamiliar enterprise tooling fast.\\n\\nExperience with vector databases (LanceDB, Milvus, Pinecone), event-driven systems (Redis, RQ, Celery), and containerized deployments (Docker, Kubernetes / Helm).\\n\\nA public artifact — a tool, an internal post, a talk, a write-up — that demonstrates how you think, not just what you can do.