The 30-Minute Software Engineer Onboarding Prompt

Turn your manager interview, engineer preferences and 30/60/90 expectations into a practical How to Work With [Your Company] guide.

Works with ChatGPT, Claude and other leading AI tools.

You are an expert in software-engineering onboarding, manager-engineer working agreements, and distributed team effectiveness.

Your task is to turn structured onboarding inputs into a practical, engineer-facing working guide that removes ambiguity from the first 90 days.

You will receive up to four sources:

SOURCE 1: Hiring Manager Interview Transcript

SOURCE 2: Engineer Working Preferences

SOURCE 3: Technical Onboarding Information

SOURCE 4: 30/60/90 Expectations

Your primary output is:

HOW TO WORK WITH [COMPANY NAME]
Engineering Working Guide

This document will be given to a newly hired software engineer.

Its purpose is to help them understand:

- what good performance looks like
- how their manager prefers to work
- how communication should happen
- when they should act independently
- when they should ask or escalate
- what creates friction
- who owns what
- how they and their manager can work effectively together
- how responsibility should increase over the first 90 days

The finished document should feel practical, human, specific, and useful.

It should NOT feel like generic HR documentation.

-----------------------------------
NON-NEGOTIABLE RULES
-----------------------------------

1. USE ONLY THE PROVIDED SOURCES

Do not invent:

- company policies
- working hours
- communication expectations
- technical processes
- people
- milestones
- decision boundaries
- manager preferences
- engineer preferences

If something important is missing, flag it rather than guessing.

2. DISTINGUISH FACTS FROM PREFERENCES

Be careful to distinguish between:

- formal company processes
- explicit manager expectations
- personal manager preferences
- engineer preferences
- examples
- aspirations
- information that is still unclear

Do not present a personal preference as formal company policy unless the source explicitly says it is.

3. DO NOT OVER-INTERPRET

If the manager says:

“I don't like being interrupted all day.”

Do not turn that into:

“Only contact your manager once per day.”

Instead write something like:

“Where practical, group non-urgent questions rather than sending frequent interruptions throughout the day.”

Then flag any missing detail that needs clarification.

4. TRANSLATE TRAITS INTO OBSERVABLE BEHAVIORS

Avoid vague labels such as:

- proactive
- good communicator
- takes ownership
- team player
- self-starter

Translate them into behaviors someone can actually follow.

For example:

Too vague:
“Be proactive.”

Better:
“If you identify a problem, investigate it and bring a possible solution or recommendation rather than simply reporting that the problem exists.”

Too vague:
“Communicate well.”

Better:
“If something is likely to be delayed, raise it as soon as you know rather than waiting until the deadline.”

5. HANDLE STORIES ABOUT PREVIOUS EMPLOYEES CAREFULLY

If the manager discusses previous engineers:

- do not name them
- do not repeat personal criticism
- do not include sensitive comments
- do not compare the new engineer with them

Extract only the useful behavioral expectation.

6. TREAT MANAGER AND ENGINEER INPUTS SEPARATELY

The manager's preference does not automatically override the engineer's preference.

Where they align, say so.

Where they differ, explain the difference neutrally.

Do not invent a compromise unless the supplied information supports one.

7. KEEP THE TONE ADULT-TO-ADULT

The tone should be:

- warm
- direct
- concise
- practical
- clear
- non-corporate
- non-patronizing

Avoid:

- HR jargon
- motivational filler
- generic advice
- excessive explanation
- threatening language
- language that makes the engineer sound subordinate or untrusted

8. KEEP IT CONCISE

The engineer should realistically read and use this document.

Prefer short sections, bullets, examples, and simple tables.

Do not repeat the same expectation in multiple sections unless necessary.

9. USE US ENGLISH

Use US English spelling throughout.

For example:

- behaviors
- realized
- prioritized
- organization
- summarize
- finalizing

10. USE THE ACT VS. ASK FRAMEWORK WHERE SUPPORTED

Use these four levels:

LEVEL 1: JUST DO IT
Make the decision and move forward.

LEVEL 2: DO IT, THEN TELL ME
Act independently, then communicate what you decided.

LEVEL 3: RECOMMEND, THEN CHECK
Investigate, form a recommendation, and discuss it before proceeding.

LEVEL 4: GET APPROVAL FIRST
Do not proceed without explicit approval.

Where possible, show both:

- the expected level when the engineer starts
- the level the manager hopes they will reach as context and trust increase

Do not assume autonomy should remain fixed.

11. DO NOT INVENT 30/60/90 MILESTONES

Use the supplied expectations.

Where enough information exists, organize them as:

Days 1-30: Understand
Days 31-60: Contribute
Days 61-90: Own

If there is not enough information to create meaningful milestones, keep the section broad and flag what needs clarification.

-----------------------------------
CREATE THE ENGINEER-FACING GUIDE
-----------------------------------

Use this structure:

# HOW TO WORK WITH [COMPANY NAME]

## Engineering Working Guide

Start with a short welcome.

Explain that this guide exists to make expectations, communication, decision-making, and working styles explicit from Day 1 so the engineer does not have to learn them through trial and error.

Keep this introduction brief.

-----------------------------------
1. THE COMPANY & WHAT WE'RE BUILDING
-----------------------------------

Summarize only what is supported by the sources:

- what the company does
- who the customer is
- why customers choose the company
- the company's current priorities
- how engineering contributes
- the most relevant context for this engineer

Keep it concise.

-----------------------------------
2. WHAT GREAT LOOKS LIKE HERE
-----------------------------------

Extract 5-8 concrete behaviors where possible.

For each, use this format:

### [Behavior]

One or two sentences explaining what this looks like in practice.

Where useful, include a short example based on something the manager actually said.

Prioritize specific behaviors over generic values.

-----------------------------------
3. THINGS THAT CREATE FRICTION
-----------------------------------

Summarize the behaviors the manager identified as unhelpful.

Write constructively.

For example:

Instead of:
“Don't disappear.”

Prefer:
“If you're blocked or progress has stalled, make it visible early rather than going quiet.”

This section should provide useful guardrails without sounding punitive.

-----------------------------------
4. HOW WE COMMUNICATE
-----------------------------------

Cover only what was actually discussed.

Where available, explain expectations around:

### Slack / Teams

### Email

### Loom / Video

### Calls

### Project Management Tools

### Progress Updates

### Urgent Communication

### Asynchronous Communication

Be specific where the sources are specific.

Do not manufacture response-time expectations.

-----------------------------------
5. HOW WE MAKE DECISIONS
-----------------------------------

Explain the manager's expectations around autonomy.

Use the Act vs. Ask framework.

Where enough information exists, create a table:

| Area / Decision | Starting Level | Expected Level Later | What This Means |
|---|---|---|---|

Do not invent decision categories.

If the manager clearly expects autonomy to increase over time, explain that explicitly.

-----------------------------------
6. WHEN YOU'RE BLOCKED
-----------------------------------

Explain:

- how long the engineer should normally try independently
- who they should contact
- what information they should provide
- when escalation is expected

Where appropriate, use this format:

1. What I'm trying to do
2. What's blocking me
3. What I've already tried
4. What I think we should do next

The tone should encourage asking for help efficiently, not discourage questions.

-----------------------------------
7. WORKING HOURS & AVAILABILITY
-----------------------------------

Include only information explicitly supported by the sources.

Where known, cover:

- timezone
- expected working hours
- required overlap
- core availability
- expected response times
- asynchronous working expectations
- what genuinely qualifies as urgent outside core hours

Do not infer working hours from geography.

-----------------------------------
8. YOUR TEAM
-----------------------------------

List the important people mentioned in the sources.

For each, explain:

- name
- role
- what they own
- when the engineer should go to them

Keep this practical.

-----------------------------------
9. HOW YOU AND YOUR MANAGER WORK BEST
-----------------------------------

Use both the manager interview and the engineer's working preferences.

Create three subsections:

### Where You're Naturally Aligned

Identify meaningful areas where their preferences match.

### Things to Be Conscious Of

Identify differences that could create misunderstanding.

Describe these neutrally.

Do not label them as problems unless the evidence supports that.

### Working Agreements

Include only agreements that are explicitly supported by the information provided.

Do not invent compromises.

-----------------------------------
10. YOUR FIRST 90 DAYS
-----------------------------------

Use:

- the manager's answer to what success looks like after 90 days
- the supplied 30/60/90 expectations
- any relevant technical onboarding information

Where supported, organize as:

### Days 1-30: Understand

What should they understand, learn, and begin doing?

### Days 31-60: Contribute

What should they increasingly contribute or handle independently?

### Days 61-90: Own

What should they increasingly own, decide, or improve?

Make progression in autonomy visible where supported.

Do not create arbitrary KPIs.

-----------------------------------
11. THE MOST IMPORTANT THINGS TO REMEMBER
-----------------------------------

Finish the engineer-facing guide with 5-7 concise takeaways.

These should reflect the strongest recurring themes from the supplied information.

They should be practical behaviors, not generic motivational statements.

For example:

- Raise risks early.
- Bring recommendations, not just problems.
- Group non-urgent questions where practical.
- Ask for help before a blocker becomes a delay.

Only include takeaways genuinely supported by the sources.

-----------------------------------
QUALITY CHECK BEFORE FINALIZING
-----------------------------------

Before producing the final engineer-facing guide, verify:

- Every meaningful claim is grounded in the supplied sources.
- No company policy has been invented.
- No precise rule has been created from a vague comment.
- No sensitive comments about previous employees remain.
- Manager and engineer preferences have not been conflated.
- Differences in working styles are described neutrally.
- 30/60/90 expectations have not been invented.
- The tone is practical and respectful.
- Repetition has been removed.
- The document is concise enough to be genuinely useful.

Then produce the finished guide.

-----------------------------------
AFTER THE ENGINEER-FACING GUIDE
-----------------------------------

Create a clearly separate section titled:

# MANAGER REVIEW: DO NOT SEND TO ENGINEER YET

This section is for the hiring manager only.

Include:

## A. INFORMATION THAT NEEDS CLARIFICATION

List important gaps that prevent the guide from being more specific.

Only include meaningful gaps.

## B. POSSIBLE AMBIGUITIES

Identify statements that could reasonably be interpreted in more than one way.

Briefly explain what needs confirmation.

## C. POTENTIAL CONTRADICTIONS

Identify any expectations that appear to conflict.

For example:

“You said you want the engineer to make decisions independently, but later said all technical decisions should be checked first. Clarify which types of decisions belong at each level.”

Do not resolve contradictions yourself.

## D. MANAGER / ENGINEER DIFFERENCES TO DISCUSS

Identify meaningful differences in working preferences.

Describe them neutrally.

Do not assume either person is right.

## E. SUGGESTED FOLLOW-UP QUESTIONS

Provide a short list of the highest-value questions needed to resolve the gaps, ambiguities, or contradictions.

Do not invent the answers.

-----------------------------------
INPUTS
-----------------------------------

# SOURCE 1: HIRING MANAGER INTERVIEW TRANSCRIPT

[PASTE TRANSCRIPT HERE]


# SOURCE 2: ENGINEER WORKING PREFERENCES

[PASTE ENGINEER ANSWERS HERE]


# SOURCE 3: TECHNICAL ONBOARDING INFORMATION

[PASTE TECHNICAL ONBOARDING INFORMATION HERE]


# SOURCE 4: 30/60/90 EXPECTATIONS

[PASTE COMPLETED 30/60/90 INFORMATION HERE]

What to paste in

1. Manager interview transcript
2. Engineer working preferences
3. Technical onboarding information
4. 30/60/90 expectations