Before You Accept the Job, Reconstruct a Real Working Week

TL;DR: Before accepting a job, ask the employer to reconstruct ordinary work and one difficult week. Connect the tasks to the decisions you would control, the support actually available, and the evidence used to judge success. A realistic job preview helps you assess the role rather than merely perform enthusiasm for it. The goal is a small set of resolved questions that could change your decision, not exhaustive access to company information or a guarantee that the job will remain unchanged.

The offer describes an opportunity; the week reveals a job

A title can be accurate and still leave the important questions unanswered. Two senior engineers may have the same salary band and work on the same product. One spends most mornings designing changes with a stable team. The other spends them reconciling commitments made by several departments, with implementation pushed into the gaps. Either job can be worthwhile. They develop different capabilities and make different demands on the person accepting them.

The candidate needs a way to move from attractive adjectives to observable work. “Autonomous” might mean choosing technical methods, deciding product priorities, or working without guidance because no experienced colleague is available. “Fast paced” might describe short delivery cycles or recurrent interruptions. Asking whether the company values autonomy will rarely distinguish these arrangements. Asking how last week's conflicting requests were resolved might.

The US Office of Personnel Management describes a realistic job preview as a way to communicate desirable and difficult aspects of a role so applicants can evaluate their fit. Its examples include conversations with current employees and observations of work. That is a useful starting principle, not a claim that every private employer offers a formal preview or that requesting one guarantees a better outcome.

This article follows an original fictional offer conversation. Maya, a backend engineer, is considering a platform position at Alder, a subscription software company. The correspondence, work calendar, and decisions below are invented to demonstrate candidate reasoning. They are not a report about an employer, a compensation recommendation, or a script for extracting confidential information.

Letter one: request evidence that could change the decision

Maya's offer emphasizes ownership of developer productivity. She likes the technical direction, but the phrase could include build systems, internal tooling, production support, and work assigned by every engineering team. Instead of asking for a general culture conversation, she sends three focused questions.

I am excited by the platform work. Before making a decision, could we spend a short conversation reconstructing a recent ordinary week for someone in this role? I would especially like to understand how incoming requests are prioritized, what the role can decide independently, and how support interruptions affect planned work. A redacted example or verbal walkthrough is entirely sufficient.

The request states a purpose and gives the employer several low effort ways to answer. It does not demand internal dashboards or employee calendars. A verbal reconstruction may be enough when the tasks and tradeoffs are specific. A company with strict confidentiality requirements can still explain a decision pattern without identifying customers, incidents, or commercial plans.

Maya also identifies what would alter her choice. She wants substantial implementation responsibility, an established escalation route, and time to learn the platform before taking independent support duty. She is willing to handle interruptions. She is unwilling to accept accountability for several product teams' delivery dates without authority to sequence their requests. These preferences distinguish a meaningful boundary from a wish that every week be pleasant.

Do this preparation before the employer responds. Otherwise, a warm conversation can expand your willingness to tolerate ambiguity without resolving it. Write two or three conditions in behavioral language. “Good mentorship” becomes “someone with relevant system knowledge reviews my first substantial changes.” “Work life balance” becomes a question about actual coverage arrangements and how exceptional work is handled, rather than an assumption based on a slogan.

Reconstruct the work from events, not percentages alone

The manager answers that engineers typically split their time between planned improvements and support. That is helpful but incomplete. A percentage says little about fragmentation. Ten support hours arranged in two blocks create a different week from ten hours distributed across forty interruptions. Ask what triggered the work and what happened to the task already underway.

Maya proposes a simple reconstruction: identify the most recent completed improvement, a recurring request, and an unplanned disruption. For the improvement, the manager describes shortening a build stage. For the request, the team maintains repository templates. The disruption was an unreliable integration test that blocked several releases. These examples begin to reveal the role's actual mix without pretending that one sampled week represents the entire year.

A small calendar can expose the remaining uncertainty:

The third column is the point. A preview should turn description into a better question. A polished list of technologies can remain compatible with many different jobs. Entry conditions, competing work, and the destination of unfinished tasks narrow that range.

Ask whether the sampled week was ordinary, unusually quiet, or unusually difficult. If the manager chooses the organization's best week, the preview may show what is possible rather than what is typical. You do not need a statistical study, but you do need the person's own qualification. “This was the first quiet week after a migration” changes how much weight to place on it.

Follow one request across the boundary of the team

The repository template request appears straightforward until Maya asks who decides whether it belongs in the shared platform. The requesting team wanted a custom deployment step. The platform engineer believed it would create maintenance work for everyone. The disagreement is more informative than the eventual implementation.

Trace four moments: who framed the request, who assessed the alternatives, who made the decision, and who maintained the result. These responsibilities may belong to different people. A candidate can reasonably enjoy implementing requests while disliking product discovery, or want discovery responsibility while lacking interest in long term operational support. The offer should make that combination visible.

OPM's job analysis guidance connects tasks, required competencies, and the relationship between them. The candidate's version of that exercise is deliberately smaller: translate a claimed skill into the work that would require it. If the job advert asks for stakeholder management, find the real disagreement the role must handle. If it asks for architectural judgment, find a decision the role can actually influence.

Maya learns that the platform engineer can recommend rejecting a customization, but the engineering director resolves disputes when delivery commitments are affected. That is neither complete independence nor helplessness. It is a decision boundary she can assess. She then asks how quickly such disputes receive attention. Escalation authority that exists only on an organization chart may not help when a team is waiting for an answer.

Notice the difference between responsibility and consultation. Being invited to every meeting does not necessarily confer authority. Conversely, lacking the final vote does not necessarily make a role weak. The practical question is whether the role has a credible route to resolve the conflicts for which it will be held accountable.

Ask for the difficult week without staging a stress test

A preview becomes lopsided when it covers only normal flow. Maya asks the manager to describe a recent week in which planned work slipped. She asks what changed, which commitments were reduced, and what the team would now do differently. This is a request for an operating example, not a challenge to prove that the organization never makes mistakes.

The manager describes the integration test failure. Several engineers investigated, but the permanent repair took longer than expected because the test crossed team boundaries. The useful follow up is not “Was that stressful?” It is “What happened to the platform objective while people were investigating?” The answer reveals whether the organization adjusts expectations or silently keeps every promise in place.

Suppose the objective's delivery date moved and the change was communicated. That suggests a mechanism for acknowledging finite capacity. Suppose instead that everyone worked around the disruption without changing commitments. Maya should ask whether that response was exceptional or expected. A single emergency is not enough to infer a culture, but the organization's account of what was justified is relevant evidence.

Avoid turning the conversation into a personal resilience audition. You do not need to promise that you would have worked longer, nor diagnose the current team as disorganized. Your task is to understand the terms under which difficult work occurs. A reasonable employer may be candid about unresolved problems. Candor is useful precisely because it allows the candidate to choose whether those are problems they want to help solve.

Letter two: compare accounts without asking who is telling the truth

Maya next speaks with a prospective peer. The manager described a mostly protected improvement schedule. The peer says requests arrive throughout the day. This need not mean either person is dishonest. They may observe different parts of the work, use different definitions, or be describing different periods.

She asks the peer to distinguish scheduled support from informal messages. It turns out that formal tickets are batched, but engineers also receive direct requests. The manager's account counted only the ticket queue. The disagreement is now concrete enough to resolve: does the organization intend to redirect direct requests, and who has the authority to insist on that change?

A useful follow up might read:

I heard that formal requests are batched, while direct messages still interrupt planned work. My understanding is that the team wants to move those messages into the shared queue. Is that already an agreed operating rule, or would establishing it be part of the work expected from the new hire?

This wording preserves the distinction between current conditions and an improvement opportunity. An employer can hire someone to build a process that does not yet exist. The candidate should know that they are accepting process design and organizational negotiation, rather than inheriting a functioning arrangement.

Do not collect accounts as votes. Three similar answers may all originate in the same recruitment briefing. One detailed counterexample can be more informative than several broad assurances. Conversely, one unhappy person's experience should not automatically define the role. Ask what specific event supports the claim and what would make that experience more or less relevant to your prospective assignment.

Separate available support from support that is merely possible

The role includes unfamiliar infrastructure. Maya does not expect to know it on arrival, but “the team will help” leaves important logistics unstated. Who knows the relevant systems? Are they available during the same working hours? Are they maintaining the documentation, or about to move to another role? How will the team decide when Maya is ready for an independent change?

These questions concern access rather than a promise of constant attention. A busy senior engineer may provide excellent support through a scheduled design review and a clear escalation route. A friendly group may provide poor support if nobody has the necessary knowledge or time. Asking for the mechanism is more useful than asking whether colleagues are supportive people.

Consider a proposed onboarding sequence. In the first week Maya follows an existing change from request to release. She then makes a bounded change with a reviewer, and later joins support alongside an experienced engineer. These are candidate and manager planning ideas, not a universal timetable. The important feature is that greater responsibility follows an observable demonstration, rather than an arbitrary date or a verbal declaration of confidence.

Dependencies should have names or roles. “There will be documentation” is a future intention. “The current owner will walk through the deployment process before moving teams” is a more specific plan, but still depends on availability. If a crucial dependency is uncertain, keep it uncertain in your notes. Do not mentally convert a plausible plan into a resource that already exists.

Determine what success means when several people influence it

The manager says the new hire should improve developer productivity. Maya asks how the organization would distinguish useful progress from a busy quarter. A count of completed tickets could reward small requests while leaving larger bottlenecks untouched. A build time measure could improve while engineers still wait for approvals. The role needs a tractable connection between work and the outcome management cares about.

Instead of proposing a measurement system during the interview, she asks about a recent favorable performance judgment: what changed, who noticed, and what evidence supported the judgment? This reveals whether the manager values implementation, adoption, service responsiveness, or political reassurance. It also shows how contextual factors enter the assessment.

If success depends on adoption by product teams, ask who helps with adoption. A platform engineer can create a tool that others are not required to use. They should know whether persuasion is a core responsibility, whether team leads have agreed to a migration, and what happens if a dependency slips. An ambitious objective is different from an individual guarantee over outcomes outside individual control.

Maya writes a provisional statement: “Success includes shipping a small number of platform improvements that teams use, while making support demand visible. It does not mean every request is delivered immediately.” The manager can now correct a concrete interpretation. If the correction is that immediate delivery remains expected, Maya has learned something consequential before accepting.

Compare the offers by reversibility, not an invented total score

Maya has another option: remaining on her current product team. It offers a familiar manager and deeper product context but fewer infrastructure decisions. The platform role offers broader systems exposure and more uncertainty about request management. Neither is captured well by adding arbitrary points for title, excitement, and culture.

She separates three kinds of considerations. Some are hard constraints, such as an incompatible coverage requirement. Some are preferences, such as the proportion of collaborative design. Others are uncertainties whose resolution could change the decision, such as whether the new hire must establish the support process. Hard constraints should not disappear because a role scores well elsewhere.

Reversibility matters because some mistakes are easier to correct than others. An imperfect development environment may be fixable within the role. A reporting arrangement that gives another department control of priorities may be harder to change. The question is not whether the offer contains uncertainty, but whether Maya can tolerate the plausible downside and influence the matters that concern her.

Avoid giving numerical precision to guesses. You can compare a known requirement with your availability. You cannot reliably calculate the probability that a manager will protect focus time from one conversation. Write the evidence and your confidence in plain language. “Two concrete examples, both from the migration period” is more honest and useful than a confidence score whose denominator nobody can explain.

When a preview is unavailable, reduce the claim you are willing to believe

Not every candidate can arrange a peer conversation. A small organization may have nobody already doing the proposed job. A recruiter may be unable to coordinate another meeting before a deadline. A restricted environment may prevent showing even a redacted work artifact. Lack of access is a limitation on your knowledge, not proof of bad faith. It still affects what you can reasonably infer.

In that situation, ask for a hypothetical decision with concrete alternatives. If two teams need the same engineer next week, who chooses the order? If a service problem arrives during a planned release, which commitment moves? The answer is weaker than an observed example because it describes an intention, but it can still expose incompatible expectations. Record it as the intended procedure rather than evidence that the procedure has worked.

For a newly created role, distinguish the initial mandate from the future ambition. A company may eventually want an internal platform, yet initially need someone to stabilize an existing build process. Ask which resources are already approved and which depend on future hiring or budget decisions. A credible small mandate can be more attractive than a broad vision whose enabling conditions are all provisional.

Candidates with limited bargaining power should concentrate their questions. You do not need to conduct an elaborate investigation to benefit from the method. One question about the most consequential uncertainty may matter more than twenty questions about minor preferences. A person balancing immediate income needs can rationally accept an imperfectly understood role. The method should clarify that choice rather than shame them for lacking alternatives.

Maya would treat an unavailable preview as a reason to narrow her conclusion. She might say, “I know the intended responsibility, but I have little evidence about interruption patterns.” That sentence leaves room for an informed acceptance, a request for more time, or a decline. It prevents the absence of evidence from being filled automatically by the most appealing version of the job.

The decision memo should preserve unresolved disagreement

Maya's final memo fits on one page. It states what she is accepting, what the employer clarified, what remains unsettled, and the personal tradeoff she is choosing. This document is primarily for her own reasoning. It need not become a negotiated employment instrument, and a conversational summary should not be mistaken for a legal guarantee.

The central paragraph reads: “I would be joining a platform team that is improving its request process, not a team with completely protected development time. The director resolves cross team priority disputes. Initial infrastructure changes receive experienced review. I want the broader systems responsibility and can accept the current interruption level if the agreed queue policy is actively supported.”

A separate line identifies the open issue: whether direct requests will actually be redirected. Maya asks the manager to confirm the intended rule and the responsible owner. If the employer cannot answer before her decision deadline, she must decide under that uncertainty. Asking a question does not obligate the organization to produce an answer, but an unanswered material question remains material.

The memo also records why she might decline. This is not pessimism; it protects the decision from being rewritten later as inevitable. If she accepts because the learning opportunity outweighs an acknowledged process weakness, an initially difficult month does not by itself prove the choice was foolish. If she accepts only by imagining the weakness away, the decision has no such defensible basis.

Use the preview after joining, while allowing the job to change

A realistic preview is a starting model rather than a permanent snapshot. Once Maya joins, she can compare the work she observes with the model she accepted. Perhaps direct requests decline, but onboarding takes longer. Perhaps support volume is modest, yet each request involves substantial coordination. These differences call for a conversation about work design, not an immediate accusation that the employer misrepresented everything.

Bring specific discrepancies to the manager. “Three unplanned requests displaced the migration review this week; how should we sequence them?” is actionable. “This job is not what I expected” may be true but gives little direction. The earlier memo helps identify whether the discrepancy concerns a known uncertainty, a changed circumstance, or a commitment that has not been supported.

Changes can also improve the role. A request process that seemed immature may create an opportunity to build judgment and influence. The preview should not trap the candidate in a demand that every day match the sampled calendar. Its value is that it gives both parties a shared language for discussing change without erasing what was originally understood.

Accepting a job means choosing work under uncertainty. Reconstructing a real week will not remove that uncertainty. It can reveal which part belongs to the work itself, which part comes from missing information, and which part is a mismatch you should take seriously before saying yes.

Sources

• US Office of Personnel Management: Realistic Job Previews — the purpose and possible forms of balanced role information for candidate self evaluation.
• US Office of Personnel Management: Job Analysis — the relationship between tasks and the competencies needed to perform them. The candidate correspondence and decision method in this article are original applications, not an OPM procedure.