Senior Engineer Onboarding, Interview, and Team Learning Checklist
Checklist onboarding, interview preparation, team learning, discussion prompts, design review drills, production-readiness questions, and practical learning plan untuk senior Java/backend engineer di CPQ, Quote, Order, Billing, Telco BSS/OSS systems.
Senior Engineer Onboarding, Interview, and Team Learning Checklist
1. Core Idea
Enterprise data modelling bukan skill yang selesai dibaca sekali. Skill ini harus dipakai untuk:
- onboarding ke domain baru,
- memahami production system,
- mereview desain,
- bertanya ke tim dengan tepat,
- memecahkan incident,
- menulis ADR,
- menilai PR,
- mempersiapkan interview senior/staff backend,
- membangun shared vocabulary di tim.
Mental model:
A senior engineer becomes effective faster by learning the data model as business truth, not as a list of tables.
Checklist ini membantu mengubah seri ini menjadi workflow praktis untuk belajar dan bekerja.
2. First 30 Days Onboarding Goal
Dalam 30 hari pertama di tim Quote & Order / CPQ / Billing, target bukan menghafal semua table.
Target realistis:
Know what the main business objects are,
who owns them,
how they move through lifecycle,
how they integrate,
how they fail,
and how to trace one customer case end-to-end.
Outcome yang diharapkan:
- bisa menjelaskan quote-to-order flow,
- bisa membedakan quote item/order item/product instance/charge/invoice line,
- tahu source-of-truth utama,
- tahu event/API utama,
- tahu status lifecycle utama,
- tahu production debugging entry points,
- tahu checklist internal yang masih perlu diverifikasi.
3. Domain Vocabulary Checklist
Pastikan bisa menjelaskan perbedaan:
- customer vs account vs billing account,
- party vs contact vs user,
- product offering vs product specification vs product instance,
- product catalog vs price list,
- quote vs quote revision,
- quote item vs order item,
- order action vs order status,
- order cancel vs product disconnect,
- product order vs service order vs resource order,
- fulfillment task vs workflow task,
- product inventory vs service inventory vs resource inventory,
- charge vs invoice line,
- subscription vs recurring charge,
- usage event vs rated usage,
- audit vs event vs log,
- source-of-truth vs projection,
- snapshot vs reference,
- internal ID vs business number vs external ID.
Jika istilah ini belum jelas, PR review data model akan berisiko.
4. Internal System Discovery Checklist
Saat masuk ke tim, cari jawaban:
Which services own quote, order, product inventory, billing integration?
Where are API contracts documented?
Where are event schemas documented?
Where is database schema/migration repository?
Where are status/reason code definitions?
Where are support dashboards?
Where are outbox/inbox/DLQ dashboards?
Where are data quality/reconciliation jobs?
Where are runbooks?
Where are ADRs?
Where are known recurring incidents?
Catat jawaban sebagai personal map.
5. Source-of-Truth Discovery
Untuk setiap entity, tanyakan:
| Entity | Questions |
|---|---|
| Customer | CRM-owned or internal-owned? |
| Account | Which system owns hierarchy? |
| Billing Account | Billing-owned or Quote/Order-owned? |
| Product Catalog | Catalog service? external? versioning? |
| Quote | Which service owns revisions/acceptance? |
| Order | Which service owns lifecycle? |
| Product Inventory | Internal or external BSS-owned? |
| Service Inventory | Internal or OSS-owned? |
| Resource Inventory | Internal or OSS-owned? |
| Charge/Invoice | Billing system or local service? |
| Approval | Workflow engine or approval service? |
Do not assume ownership from table location alone.
6. End-to-End Trace Exercise
Pick one real or non-sensitive sample:
quote_number -> order_number -> product_instance -> charge -> invoice_line
Trace:
- quote header,
- quote revision/version,
- quote items,
- price snapshot,
- approval,
- acceptance,
- product order,
- order items,
- decomposition,
- fulfillment tasks,
- product/service/resource inventory,
- billing trigger/charge,
- invoice line,
- support timeline,
- events/outbox/inbox.
If no real data is available, use synthetic/golden test data.
7. API and Event Learning Checklist
For each major operation, identify:
API endpoint / command
Request DTO
Response DTO
Domain command
Aggregate/entity touched
Status transition
Audit record
Outbox event
Consumer service
Error codes
Idempotency key
Start with:
- create quote,
- price quote,
- submit quote,
- approve quote,
- accept quote,
- convert quote to order,
- submit order,
- cancel/amend order,
- complete fulfillment task,
- activate product,
- trigger billing,
- issue invoice.
8. Database Learning Checklist
Untuk schema utama, pahami:
- primary key strategy,
- business number strategy,
- tenant/environment scope,
- version/optimistic locking,
- status fields,
- source references,
- external references,
- audit/history tables,
- unique constraints,
- indexes,
- JSONB usage,
- effective dating,
- retention/archive,
- migration style.
Questions:
Which constraints enforce business invariants?
Which invariants are only enforced in application?
Which tables are hot?
Which tables grow fastest?
Which tables are append-only?
Which queries are most important?
9. Workflow and State Machine Checklist
For quote/order/fulfillment/billing:
- list states,
- list transitions,
- identify terminal states,
- identify retry/fallout states,
- identify cancellation/amendment path,
- identify who/what triggers transition,
- identify audit/status history,
- identify events emitted,
- identify forbidden transitions,
- identify stale event handling,
- identify manual repair path.
If state machine is not documented, build your own working map and verify with team.
10. Integration Discovery Checklist
For each external system:
system name
owner
direction inbound/outbound
API/event/file/batch
external IDs
mapping table
retry policy
DLQ/failure model
reconciliation rule
support dashboard
runbook
known failure modes
Important external categories:
- CRM,
- billing,
- ERP/finance,
- OSS/provisioning,
- workflow engine,
- identity provider,
- payment provider,
- reporting/warehouse,
- customer portal,
- partner APIs.
11. Production Debugging Onboarding
Learn how to answer:
- Where do I find logs by correlation ID?
- Where do I find audit timeline?
- Where do I find status history?
- Where do I find outbox/inbox?
- Where do I find DLQ messages?
- Where do I find workflow process instance?
- Where do I find external integration request/response?
- Where do I find data quality mismatches?
- Where do I find repair cases?
- Who approves production repair?
- What is the escalation path?
A senior engineer must know the operational map, not only code map.
12. Questions to Ask Senior Teammates
Good onboarding questions:
What data model area has caused the most incidents?
Which entity has the most confusing meaning?
Which status field is hardest to reason about?
Where do duplicate orders/charges usually come from?
Which external integration is most fragile?
Which table is hardest to migrate?
Which report/KPI is most disputed?
Which manual repair is most common?
Which data quality check catches real issues?
What is one design decision you wish new engineers understood earlier?
These questions reveal production reality.
13. Interview Preparation Themes
For senior/backend interview or internal growth, be ready to discuss:
- designing quote/order model,
- modelling product catalog versions,
- quote snapshot vs reference,
- order lifecycle state machine,
- idempotency for quote-to-order conversion,
- outbox/inbox pattern,
- distributed consistency and saga,
- optimistic/pessimistic locking,
- PostgreSQL indexing for tenant/status queries,
- data migration/backfill strategy,
- audit and status history,
- cache invalidation,
- search projection consistency,
- data quality/reconciliation,
- privacy/security classification,
- incident debugging.
Do not only discuss framework syntax. Discuss correctness.
14. Interview Drill 1 — Design Quote-to-Order
Prompt:
Design a data model for a CPQ system where accepted quotes are converted into orders. Quotes can have multiple versions, approval applies to exact quote version, and conversion can be retried.
Expected points:
- quote family/revision,
- quote item,
- price snapshot,
- approval target version,
- accepted immutable revision,
- product order source quote version,
- order item source quote item,
- idempotency key,
- unique constraint one order per quote version,
- outbox event,
- status history,
- conflict handling,
- tests for duplicate conversion.
15. Interview Drill 2 — Active Product Not Billed
Prompt:
Production reconciliation finds active billable products without active recurring charges. How would you model detection, investigation, and repair?
Expected points:
- product instance source-of-truth,
- charge/billing owner,
- billing readiness,
- reconciliation rule,
- severity/owner/SLA,
- data quality result,
- idempotent repair command,
- external billing check,
- revenue impact,
- audit/repair case,
- preventive action.
16. Interview Drill 3 — Catalog Versioning
Prompt:
Product offering changes after quote is created. How do you ensure accepted quote and order remain historically correct?
Expected points:
- product offering version,
- catalog publication,
- quote item configuration snapshot,
- price snapshot,
- accepted quote immutability,
- order item commercial snapshot,
- lineage to catalog version,
- policy for draft quote revalidation,
- migration/deprecation,
- reporting impact.
17. Interview Drill 4 — Event-Driven Order Fulfillment
Prompt:
Order service publishes OrderCreated. Fulfillment consumes it and creates tasks. Events can be duplicated and out-of-order.
Expected points:
- outbox,
- inbox,
- event ID,
- aggregate version,
- idempotent task creation,
- unique key for task,
- stale event guard,
- retry/DLQ,
- projection version,
- reconciliation,
- observability.
18. Interview Drill 5 — Data Migration
Prompt:
You need to add billing_account_id to millions of existing orders and backfill from accepted quote snapshot.
Expected points:
- expand/contract,
- nullable column first,
- batch backfill,
- source-of-truth,
- exception table,
- progress tracking,
- idempotency,
- validation query,
- index concurrently,
- old/new app compatibility,
- rollback/forward fix,
- monitoring.
19. Team Learning Session Format
A good 60-minute session:
0-10 min: choose one scenario/incident.
10-20 min: map current entities and source-of-truth.
20-35 min: identify invariants/failure modes.
35-45 min: propose model or fix.
45-55 min: review tradeoffs and migration.
55-60 min: action items and internal verification.
Rotate topics:
- quote versioning,
- product catalog,
- order state machine,
- fulfillment fallout,
- billing activation,
- data quality,
- event replay,
- privacy purge,
- migration/backfill,
- support timeline.
20. Personal Knowledge Map Template
Create a personal note:
## Core domain objects
## Service ownership
## Main APIs
## Main events
## Main tables
## Main state machines
## Main external systems
## Main support dashboards
## Main reconciliation rules
## Common incidents
## Safe repair workflows
## Open questions
Update weekly during onboarding.
21. Codebase Exploration Checklist
In repository, inspect:
- API resource/controller classes,
- DTO classes,
- domain command classes,
- service/application layer,
- aggregate/domain model,
- repository/mapper,
- migration files,
- event producer/outbox,
- event consumer/inbox,
- audit/status history implementation,
- error model,
- integration clients,
- tests/golden datasets,
- runbook links.
Map code to data model concepts.
22. PR Review Practice Checklist
Pick recent PRs and ask:
- What entity changed?
- What invariant changed?
- What source-of-truth changed?
- What API/event contract changed?
- What migration was included?
- What indexes changed?
- What tests were added?
- What failure mode was considered?
- What operational visibility was added?
- What documentation/ADR changed?
This builds review muscle.
23. Incident Review Learning Checklist
For each incident/postmortem, extract:
Data object involved
Invariant broken
Source-of-truth confusion
Missing constraint/idempotency/reconciliation
Event/integration issue
Migration/config trigger
Detection gap
Repair action
Preventive action
Lesson for data model design
Over time, this becomes a domain-specific anti-pattern catalog.
24. Onboarding Milestone — Week 1
By end of week 1:
- know team/product scope,
- know main services/repositories,
- know quote/order/billing high-level flow,
- know main environments,
- know how to find logs/correlation ID,
- know how to run tests locally,
- know where schemas/migrations live,
- know who to ask for domain/billing/OSS questions.
Deliverable:
1-page personal architecture map.
25. Onboarding Milestone — Week 2
By end of week 2:
- trace one quote-to-order scenario,
- explain key entities,
- read one migration,
- read one API contract,
- read one event contract,
- inspect one outbox/inbox flow,
- review one PR with data modelling lens,
- identify one unclear term and verify glossary meaning.
Deliverable:
End-to-end trace note for one sample order.
26. Onboarding Milestone — Week 3
By end of week 3:
- understand order lifecycle/fallout/retry,
- understand product inventory/billing trigger linkage,
- understand one external integration,
- understand one reconciliation rule,
- understand one known incident pattern,
- propose one documentation or test improvement.
Deliverable:
Mini data model review of one feature or incident.
27. Onboarding Milestone — Week 4
By end of week 4:
- confidently review small data model changes,
- identify source-of-truth and invariants,
- know operational debugging path,
- know safe repair escalation,
- understand team conventions,
- contribute to ADR/review/test improvement.
Deliverable:
PR review checklist customized for team.
28. Senior Engineer Self-Assessment
Rate 1–5:
| Area | Score |
|---|---|
| Domain vocabulary | |
| Quote/order lifecycle | |
| Product catalog/versioning | |
| Billing/charge/invoice modelling | |
| Product/service/resource inventory | |
| PostgreSQL constraints/indexes | |
| API/DTO contract design | |
| Event/outbox/inbox design | |
| Idempotency/concurrency | |
| Migration/backfill | |
| Security/privacy | |
| Observability/debugging | |
| Reconciliation/data quality | |
| Production repair governance | |
| Trade-off communication |
Target: no critical area below 3 for senior ownership.
29. Team Maturity Assessment
Ask:
- Is source-of-truth documented?
- Are state machines documented?
- Are contract schemas versioned?
- Are data quality rules running?
- Are support timelines available?
- Are repair workflows auditable?
- Are migrations reviewed for production safety?
- Are test datasets realistic?
- Are PRs reviewed for data semantics?
- Are incidents feeding preventive design changes?
This helps move from individual learning to team capability.
30. Red Flags During Onboarding
Watch for:
- "only one person understands billing mapping",
- "status means different things depending where",
- "we usually fix with SQL",
- "no one knows why this field exists",
- "dashboard is probably wrong",
- "event replay is risky",
- "external ID mapping is messy",
- "migration takes too long so we avoid it",
- "we do not have a test case for that",
- "support asks engineering every time."
These are learning priorities and improvement opportunities.
31. Internal Verification Checklist
Verify in actual team:
- Official onboarding docs.
- Domain glossary availability.
- Source-of-truth documentation.
- Architecture diagrams.
- PR review standards.
- Migration/release standards.
- Incident/runbook process.
- Support dashboards.
- Data quality/reconciliation dashboards.
- Security/privacy classification process.
- TMF alignment expectations.
- Known historical pain points.
This checklist should become team-specific over time.
32. Summary
Senior onboarding for enterprise data modelling requires deliberate practice.
A strong learning plan includes:
- domain vocabulary,
- system ownership,
- end-to-end tracing,
- API/event/schema exploration,
- production debugging,
- interview/design drills,
- PR review practice,
- incident learning,
- milestone-based onboarding,
- self-assessment,
- team maturity assessment.
The key principle:
To become effective in enterprise Quote & Order systems, learn the data model as a living production contract between customer promise, system execution, billing truth, and operational recovery.
You just completed lesson 79 in final stretch. Use the series map if you want to review the broader track, or continue directly into the next lesson while the context is still warm.
Keep the momentum while the lesson is still fresh. Move backward for review or continue forward into the next concept.