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, test coverage automation, root cause analysis, and more.\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.
Our 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.
Who thrives in this role?
- Engineers who want to own a product end-to-end - discovery, build, ship, adoption - rather than specialize in one phase.
- 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.
- Engineers comfortable starting from observation rather than a written spec, and revising direction as they learn.
- 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.
- Engineers who stay calm under release pressure and surface risks early, before they become blockers.
- Engineers who communicate clearly across engineering teams, leadership, and the QE org they are embedded with.
5+ years shipping production software end-to-end - backend, frontend, or both, used by real users(internal or external).
Strong Python and TypeScript. You can move between FastAPI / aiohttp and Next.js without a warm-up.
A 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.
A 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.
Comfort 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.
Working 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.
You can describe one time you removed or retired a feature you personally built, because adoption did not justify keeping it.
Bachelor'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.
You have built and shipped MCP servers, agents, or RAG systems against an internal knowledge base.
Background in QE, developer tooling, internal platforms, or test infrastructure - XCTest / XCUI experience is a plus, but workflow understanding matters more than framework familiarity.
Comfort with Apple-internal engineering platforms (Radar, Stash, Arches, Twist) or a track record of getting fluent in unfamiliar enterprise tooling fast.
Experience with vector databases (LanceDB, Milvus, Pinecone), event-driven systems (Redis, RQ, Celery), and containerized deployments (Docker, Kubernetes / Helm).
A public artifact - a tool, an internal post, a talk, a write-up - that demonstrates how you think, not just what you can do.
