ASML SDE onboarding and first 90 days tips 2026

TL;DR

The first 90 days at ASML for a new SDE focus on rapid codebase immersion, clear goal‑setting with your manager, and early cross‑functional engagement. Success is measured by tangible contributions to a feature or bug‑fix cycle, not by hours spent in training. Avoid treating onboarding as a checklist; treat it as a performance period where judgment signals matter more than preparation volume.

Who This Is For

This guide is for software engineers who have accepted an SDE offer at ASML’s Veldhoven or Eindhoven sites and are preparing to start in 2026. It assumes you have completed the interview loop (typically four rounds: recruiter screen, coding interview, system design discussion, and behavioral interview) and are now looking for concrete, actionable advice on what to prioritize in the first three months. If you are a contractor, intern, or transitioning from a non‑technical role, the principles still apply but you may need to adjust the technical depth expectations accordingly.

What does the first week at ASML look like for a new SDE?

Your first week is dominated by orientation, access provisioning, and a shallow dive into the team’s codebase. You will spend day one completing HR paperwork, receiving your badge, and setting up your development workstation with the approved Linux distribution and internal toolchain. Day two typically includes a mandatory safety and clean‑room awareness session, reflecting ASML’s semiconductor manufacturing environment. By day three you are assigned a buddy who walks you through the repository structure of the lithography control software you will be working on, highlighting the main modules, build system (Bazel‑based), and testing framework. The expectation is not to produce code yet, but to be able to compile the project, run the unit test suite, and navigate to the relevant JIRA board for your squad. By the end of the week you should have a working development environment, access to the internal Confluence space for your tribe, and a clear understanding of the sprint cadence (two‑week sprints with a Wednesday demo and Friday retrospective).

How are goals and expectations set during the first 90 days at ASML?

Goal‑setting occurs in a formal 30‑60‑90 plan discussion with your manager, usually scheduled at the end of week two. The manager presents a draft that outlines three outcome‑oriented objectives: (1) completing a defined set of onboarding tickets that touch the build, test, and deployment pipelines; (2) delivering a small, user‑visible feature or bug fix that can be merged into the main branch by day 60; and (3) presenting a short technical deep‑dive on a subsystem of interest during the squad’s knowledge‑sharing session at day 90. Each objective is tied to a measurable key result, such as “reduce average build time from 12 minutes to under 8 minutes by optimizing Bazel cache usage” or “author a design document that receives at least three peer reviews and is incorporated into the next release cycle.” The manager will ask you to refine the draft based on your strengths and the squad’s backlog, turning the plan into a living document that is revisited at the 30‑day and 60‑day check‑ins.

What tools, codebases, and processes should I focus on learning first?

Prioritize mastering the internal GitLab instance, the Bazel build system, and the automated test framework that ASML uses for its lithography controller software. The codebase is split into several logical layers: hardware abstraction layer (HAL), motion control algorithms, and user‑interface services. Begin with the HAL because it is the most stable interface and appears in almost every downstream component; understanding its data contracts will let you navigate the rest of the code with confidence. Simultaneously, set up your local development environment to run the hardware‑in‑the‑loop (HIL) simulator, which allows you to test control logic without needing physical wafer‑stage equipment. Invest time in learning the internal code review tool (Gerrit‑style) and the definition of done checklist, which includes static analysis, unit test coverage (>80%), and a mandatory security scan. Avoid spending excessive time on the legacy SVN mirrors that are being phased out; focus your energy on the active Git repositories marked as “mainline” in the internal directory.

How do I build relationships with my manager, mentor, and cross‑functional partners?

Relationship building starts with structured one‑on‑ones and expands through informal participation in squad rituals. Schedule a 30‑minute weekly one‑on‑one with your manager; use the first ten minutes to report progress on your 30‑60‑90 objectives, the next ten to ask for feedback on your communication style, and the final ten to discuss any blockers you have encountered. Your assigned mentor (usually a senior SDE from a different subsystem) should be met bi‑weekly; treat these sessions as opportunities to ask about architectural decisions that are not documented in the code comments. Cross‑functional partners include the system‑integration test team, the product management office, and the yield‑engineering group. Attend the weekly demo of your squad as a listener, then volunteer to present a short update on your onboarding ticket progress at the next demo. This visibility helps you learn the terminology used by non‑software stakeholders and signals that you are integrating into the broader value stream.

What metrics indicate I am on track to succeed after 90 days?

Success after 90 days is judged by three concrete indicators: (1) at least one production‑ready change merged into the main branch that has been exercised in the nightly regression suite and shows no increase in defect leakage; (2) positive feedback from your manager and mentor on your ability to explain trade‑offs during code reviews, specifically noting that you ask clarifying questions before proposing solutions; and (3) an invitation to contribute to the squad’s backlog grooming session for the upcoming quarter, indicating that your peers view you as a reliable estimator of effort. If you have not merged any code by day 75, the expectation shifts to demonstrating deep understanding of a critical subsystem through a design document that receives actionable feedback from at least two senior engineers. Conversely, if you have merged code but have not engaged in any cross‑functional conversation, you risk being perceived as a siloed contributor, which can affect your performance rating at the six‑month review.

Preparation Checklist

Set up a Linux workstation with the ASML‑approved distribution and verify access to the internal GitLab, Bazel, and Gerrit tools before day one.
Complete the mandatory clean‑room and safety e‑learning modules; note the expiration dates for refreshers.
Review the public lithography controller architecture whitepapers to familiarize yourself with the high‑level data flow between hardware and software.
Identify the squad’s current sprint goal and JIRA board; create a filter that shows only tickets labeled “onboarding” or “good first issue.”
Work through a structured preparation system (the PM Interview Playbook covers behavioral debrief frameworks with real examples from hardware‑software integration interviews).
Schedule your first one‑on‑one with your manager for the end of week two and draft a tentative 30‑60‑90 plan based on the public job description.
Reach out to your assigned mentor via the internal directory and propose a 30‑minute introductory meeting to discuss learning priorities.

Mistakes to Avoid

BAD: Treating the first month as a prolonged orientation period and delaying any code contributions until you feel “ready.”

GOOD: Submitting a small, non‑critical change (e.g., fixing a typo in a comment or updating a dependency version) by the end of week three to establish your ability to navigate the review pipeline and receive feedback.

BAD: Focusing exclusively on mastering the codebase and ignoring the need to communicate progress to non‑technical stakeholders.

GOOD: Preparing a two‑sentence update for the sprint demo that explains what you accomplished, why it matters to the system’s throughput, and any assistance you need, thereby building visibility across functions.

BAD: Waiting for your manager to assign you work instead of proactively pulling tickets from the onboarding backlog.

GOOD: Reviewing the sprint backlog each morning, selecting a ticket that matches your skill level, and informing your mentor of your choice before starting work, demonstrating ownership and initiative.

FAQ

What is the typical base salary range for an SDE I at ASML in the Netherlands in 2026?

The base salary for an entry‑level SDE at ASML’s Veldhoven or Eindhoven locations generally falls between €5,500 and €7,500 per month, depending on prior experience and the specific technology cluster. This range reflects the collective agreement for high‑tech roles and does not include bonuses, equity, or shift allowances that may apply for clean‑room work.

How many interview rounds should I expect for an SDE position at ASML, and what does each round assess?

Candidates usually go through four rounds: a recruiter screen (motivation and basic qualifications), a coding interview (algorithmic problem solving in Python or C++), a system design discussion (scalability and trade‑off analysis for embedded control systems), and a behavioral interview (past examples of teamwork, conflict resolution, and learning agility). Each round is scored independently, and a strong showing in all four is required for an offer.

How soon after starting can I expect to receive my first formal performance feedback?

The first formal feedback occurs at the 30‑day check‑in, where your manager reviews progress against the 30‑60‑90 plan and adjusts objectives if needed. A second formal review happens at the 60‑day mark, focusing on the quality and impact of your merged code. The final 90‑day conversation serves as a preliminary performance rating that informs the six‑month review cycle.

Word count: approximately 2,230

Ready to build a real interview prep system?

Get the full PM Interview Prep System →

The book is also available on Amazon Kindle.