Read 3 onboarding transcripts — tech stack overview, codebase conventions, and communication norms. Extract key information as you would on your first week at a new company.
Communication norms: async vs sync, channel preferences, urgency signals
0 / 3 completed
1 / 3
📄 Transcript
[Onboarding call — Day 1. New hire (Tomasz) with hiring manager (Sarah) and tech lead (Leo).]
Sarah: "Welcome to the team, Tomasz! Today is just orientation — no code yet. Leo's going to walk you through the tech stack and our engineering culture, and then I'll cover HR stuff in the afternoon."
Leo: "Hey Tomasz! So — quick lay of the land tech-wise. Our main product is a B2B SaaS platform. Backend is Node.js with Express, PostgreSQL as the primary database — we use Prisma as our ORM. Frontend is React with TypeScript. We deploy on AWS — ECS for containerised services, S3 + CloudFront for static assets."
Tomasz: "Thanks. What's the deployment process like?"
Leo: "CI/CD through GitHub Actions. PRs trigger automated tests — unit, integration, and a subset of E2E. We use trunk-based development, so no long-lived feature branches — you commit to main via short-lived branches and PRs. Release to production happens every Tuesday and Thursday after staging validation."
Tomasz: "And on-call? What should I expect?"
Leo: "You won't be on-call for the first 60 days. We use PagerDuty — once you're added, you'll be on a rotation with the rest of the backend team. We have an SLA of 99.9% uptime, so incidents are taken seriously. There's a runbook for every known failure mode."
What is the deployment process described, and what does "trunk-based development" mean?
Leo describes: GitHub Actions CI/CD → automated tests on PR → merge to main → deploy Tuesday/Thursday after staging.
Trunk-based development:
Main branch = "trunk" (like the trunk of a tree — the central stem)
Developers create short-lived branches (hours to days, not weeks)
Merge back to main frequently via PRs
Avoids the "big bang merge" problem of long-lived feature branches
Often paired with feature flags to ship incomplete features safely
Key onboarding vocabulary:
"lay of the land" = an overview of the current situation/setup
"E2E tests" = End-to-End tests — simulate a user going through the full application
"runbook" = a documented procedure for handling a known type of incident
"on-call rotation" = a schedule where team members take turns being the first responder to incidents
2 / 3
📄 Transcript
[Onboarding call — Day 2. Tech lead (Marcus) and new backend developer (Aigerim).]
Marcus: "OK, day two — let's talk about codebase conventions. First rule: we follow the style guide enforced by ESLint and Prettier. No debates about formatting — the linter wins. If you disagree with a rule, raise a PR to change the config, but don't bypass it."
Aigerim: "Understood. What about naming conventions?"
Marcus: "Files: kebab-case. React components: PascalCase. Functions and variables: camelCase. Database tables: snake_case. These are enforced by a pre-commit hook — if your naming doesn't match, the commit fails."
Aigerim: "Got it. What's the branching strategy?"
Marcus: "feature/[ticket-id]-short-description for features, fix/[ticket-id] for bug fixes, chore/ for maintenance work. Always branch from main, never from another feature branch."
Aigerim: "And code review — how strict is it?"
Marcus: "Two approvals required before merge. One from someone with domain knowledge of what you changed, one from any senior engineer. We try to give reviews within 24 hours. PRs over 400 lines get flagged for review by the tech lead — not blocked, but expected to have good justification. We prefer small, atomic PRs."
What is a "pre-commit hook" as described by Marcus, and what naming conventions are enforced?
Pre-commit hook = a Git hook script that runs locally before a commit is accepted, blocking it if rules are violated.
Naming conventions summary from the transcript:
kebab-case
files: my-component.ts
PascalCase
React components: MyComponent
camelCase
functions/variables: getUserData
snake_case
DB tables: user_profiles
Additional key vocabulary:
"ESLint" = a JavaScript linter that flags code style and potential errors
"Prettier" = an opinionated code formatter
"atomic PR" = a pull request that makes one logical, focused change — easier to review and revert
"domain knowledge" = specialist understanding of a specific area of the codebase
3 / 3
📄 Transcript
[Onboarding call — Week 1. New dev asks about team communication norms.]
New Dev (Rafa): "I wanted to ask — what's the expectation for response times in Slack? At my last company, people expected replies within 30 minutes."
Lead Dev (Priya): "We're more async here. The top-level rule: nothing is urgent unless marked with @here or @channel in #incidents. For regular questions, same-day response is the expectation — but we respect focus time, so people often do 'office hours' type availability: check messages at 9, 12, and 5."
Rafa: "What about DMs versus public channels?"
Priya: "Default to public channels for everything technical. If you ask in a DM and I answer there, no one else learns from it. We have channels like #help-backend, #help-frontend, #infrastructure. The signal-to-noise ratio is high in those — people actually search them before asking."
Rafa: "And when I'm stuck for more than, say, 30 minutes?"
Priya: "Post in the relevant channel with what you tried and what you got. The rubber-duck approach — writing it out often helps you solve it yourself. If it's still stuck after a few hours, @ someone directly."
Rafa: "Good to know. One more thing — the style of code comments?"
Priya: "Comments explain WHY, not WHAT. If I can read the code and understand what it does, don't comment it. If there's a counterintuitive decision — a workaround for a browser bug, a magic number — that's what needs a comment. Include a link to the issue or forum post that explains the context."
What are the team's norms for Slack communication and code comments, according to Priya?
Priya describes an async-first culture with specific norms for urgency, channels, and comments.
Communication norms from this transcript:
Urgency signal: @here / @channel in #incidents only — everything else is non-urgent
Default to public channels — DMs create knowledge silos; channels are searchable
Post what you tried — reduces back-and-forth, shows good faith effort first
Rubber duck debugging: explaining your problem in writing often helps you solve it — named after the technique of explaining code to a rubber duck
"Comments explain WHY, not WHAT" — one of the most important code style principles:
❌ // increase counter by 1 (explains WHAT — already obvious from code)
✅ // Firefox < 70 returns null here instead of 0 — see issue #1234 (explains WHY)
Key vocabulary:
"signal-to-noise ratio" = ratio of useful content to irrelevant content — high = mostly useful
"async-first" = preferring asynchronous communication (messages, docs) over synchronous (calls, meetings)
"office hours" = specific times when someone is available for questions
"magic number" = a hard-coded numeric literal without explanation (bad practice)