5 exercises on key phrases for your first week on a development team. Choose the most natural and professional option.
0 / 5 completed
1 / 5
It is your first week and you want to understand the architecture. How do you ask your tech lead?
ASKING FOR A WALKTHROUGH: "Could you walk me through [specific topic] when you have [time]? I've [done homework] but I'd love to hear [specific value]." shows preparation, respects the other person's time, and frames the ask around insight rather than just information-delivery. Examples: "Could you walk me through the deployment pipeline when you have a moment? I've read the CI config but the staging vs. prod split wasn't clear." / "Could you walk me through how incidents are handled here — I've read the runbook, but I'd love to know the unwritten norms." / "Could you walk me through the data model? I've explored the schema but some relationships aren't obvious." Options A/C show lack of preparation; B shows unwillingness to collaborate.
2 / 5
You're looking for the on-call escalation process. How do you ask a team member?
FINDING INFORMATION PROFESSIONALLY: "Where should I look for [X] — is it in [option A], [option B], or somewhere else?" shows you've already considered the likely locations and reduces the cognitive load on the person you're asking. Examples: "Where should I look for the API authentication docs — is it in the README, the internal wiki, or Notion?" / "Where should I look for the test data setup guide — is it in the repo or is there a separate onboarding doc?" / "Where should I look for the staging environment credentials — is it in 1Password or the .env.example?" Options A/C/D are either too terse, too passive, or subtly cynical — B is the only one that signals active self-direction.
3 / 5
You want to make a change in part of the codebase you haven't worked in before. How do you communicate this?
RESPECTING OWNERSHIP: "I don't want to step on anyone's toes — who owns...?" is a phrase that signals collaboration and awareness of team boundaries. It prevents duplicated work and builds trust with the owning team. Examples: "I don't want to step on anyone's toes — who owns the auth middleware? I'm planning to add a new token validation step." / "I don't want to step on any toes — is there an owner for the design system? I want to propose a new token." / "Who owns the billing module? I'm adding a webhook handler and want to make sure it fits the existing pattern." Options B/C either don't ask permission at all. D asks too passively — it suggests you only want to look, not act.
4 / 5
You've noticed something in the codebase that seems odd — a piece of code that looks like a bug. How do you raise it professionally?
RAISING OBSERVATIONS AS A NEW JOINER: "I noticed [specific observation] — is that intentional, or is it something we should look into?" is perfectly calibrated for a new joiner. It surfaces the concern without claiming certainty, and gives the team an easy way to confirm or clarify. Examples: "I noticed the migration doesn't have a rollback script — is that intentional, or is there a separate process for that?" / "I noticed the integration tests only run on main, not on PRs — is that by design?" / "I noticed the rate limiter configuration in staging doesn't match prod — is that expected?" Options A/B sound accusatory or lack specificity; D is too tentative to prompt action.
5 / 5
You're joining a team meeting for the first time. How do you introduce yourself?
FIRST-WEEK TEAM INTRODUCTION: A strong introduction includes your name, role, team, and a forward-looking phrase that signals engagement. "I'm excited to be here and looking forward to getting up to speed with everyone" is warm, professional, and opens a collaborative dynamic. Examples: "Hi — I'm Marco, joining as a senior frontend engineer. I come from a fintech background and I'm looking forward to contributing to the design system." / "Hi everyone, I'm Yuna, the new data engineer. I'll be working on the pipeline team. Great to meet you all." / "I'm Dmitri, recently joined as a DevOps engineer. Happy to be here and keen to learn how the infrastructure is structured." Options A/B/C are either too terse, too passive, or signal unpreparedness.