Before you sign, run four checks in this order: (1) read the artifacts — engineering blog, GitHub org, product changelog, careers page — and grade them for specificity. (2) Use the remaining interview loops to ask questions that require a concrete example, not a value statement. (3) Do at least one back-channel reference call with a former engineer you find on LinkedIn. (4) Read employee reviews last, weighted toward the last 12 months, looking for repeated patterns and not star ratings.
If any of those checks return "we don't do that here" energy — empty blog, calendar-full engineers, nobody willing to talk to you off the record, or a wall of "the pace" complaints from the last quarter — the offer is not the offer you think it is.
The offer arrived. The recruiter is friendly. The comp looks fine. You have seven days to sign or renegotiate, and everyone you know is asking whether you're going to take it. The pressure is real, and it points in exactly the wrong direction: toward closing the loop, not toward the last useful hour of diligence.
Here is the uncomfortable truth about engineering culture: the interview loop is designed to sell you the job. The people who show up to your on-sites are the same people who will benefit from your acceptance, and they are — usually unconsciously — presenting the best version of the team. That is not deceit. It is gravity. Your job in the days between offer and signature is to correct for it.
What follows is the due-diligence playbook. Nine concrete signals, organized in the order you should actually check them: public artifacts first, interview loops second, back-channel references third, employee reviews fourth, and a final 48-hour checklist to run before the ink dries.
Start with what's actually visible
The first hour is free and everyone should spend it. Long before you talk to a single human, four surfaces will tell you most of what you need to know.
A real engineering blog is one of the highest-signal artifacts a company produces. Not because writing is a virtue in itself, but because a functioning engineering blog requires four things at once: engineers who can write, managers who let them, a communications team that doesn't strip the interesting parts out, and a culture that treats internal knowledge as worth externalizing. When any of those is broken, the blog dies.
Read the last six months of posts. Are they written by engineers, or by marketing? Do they name specific systems, tradeoffs, and mistakes — or do they read like recruitment brochures? A post titled "How We Scaled to 10M Users" that describes actual architectural decisions is a good sign. A post titled "Meet the Team: Meet Priya!" is not a bad sign, but it is not the sign you're looking for.
Even for companies whose core product is closed source, the GitHub org tells you something. Are there real open-source libraries with real maintenance activity? Do individual engineers have their contributions credited under their own accounts, or is everything funneled through a corporate bot? Is the last commit six months old? Do PRs get thoughtful review comments, or does everything land with a rubber-stamp approve?
You're not scoring them on being an open-source company. You're checking whether the engineering org treats code as something worth being seen doing well.
The changelog is where marketing lies get exposed. If the careers page says "we ship fast" and the last user-facing release note is from three months ago, one of those two things is wrong. Look for consistent cadence rather than one heroic release followed by silence. A tiny weekly changelog is a healthier signal than a giant quarterly one; it usually correlates with smaller PRs, lower blast radius, and a real deploy pipeline.
What to ask during the interview loop
Interview questions are the second-order test. The first-order test is whether the interviewer can answer them at all. Generic "what's your culture like?" questions get generic answers. Specific questions get specific answers — or they surface the fact that the person on the other side of the Zoom does not actually know what the culture is like when nobody is looking.
These are the questions that get past the pitch:
This is the single highest-signal question you can ask an engineering interviewer, and it does triple duty. It tests whether they have blameless postmortems (they'll describe the incident calmly and factually, not defensively). It tests whether they have shared ownership (they'll say "we", not "someone on the platform team"). And it tests whether recent deploys have actually gone badly enough for someone to remember one — which, uncomfortably, tells you whether the team is shipping meaningful volume at all.
Follow-ups that work: "What changed in the process because of it?" and "Who was in the postmortem, and did anyone in the room say something that surprised the group?"
Every engineering org has a stated process (design docs, RFCs, review meetings) and a real process (three people in a Slack DM, an executive with a strong opinion, a Google Doc that got approved because everyone was too tired to disagree). You want to hear the real one. Ask for a specific recent example, not a description of the framework.
Bonus question: "Who was the last IC to overrule a director on a technical call?" If the answer is "that doesn't happen here," you're joining a top-down engineering org and you should know it before you sign.
Ask the specific quarter, not the abstract policy. Real answers include the shape of the rotation (weekly, biweekly), whether it's paid or unpaid on top of salary, how often pages actually fire during off-hours, and whether the last person on call slept through the weekend. If the interviewer says "on-call is pretty light" and cannot name the last time they were paged, either they aren't senior enough to be on the rotation, or the rotation is fake.
Also ask: "Who owns reliability at the org level?" A named human means someone is accountable. "Everyone owns it" usually means no one does.
The reference-call playbook
Back-channel references are the highest-leverage step in the entire due-diligence process, and 90% of engineers never do them. The reason isn't laziness; it's that reaching out to strangers feels awkward. It is awkward. It is also worth every ounce of the awkwardness.
Here is the process, condensed:
Step 1. Go to LinkedIn. Search the company name. Filter to "Past" employees who held engineering roles in the last 12 to 24 months. You want people who worked there recently enough that their information is current, but who no longer have anything to protect. Aim for three to five candidates.
Step 2. Send a short, honest message. Something like: "Hi — I have an offer from [team] at [company]. Would you be open to a 15-minute call for an unfiltered read on the culture? Happy to keep it completely off the record. Totally understand if not." No preamble, no attempts to network first. Directness reads as respect.
Step 3. On the call, ask three questions. "Why did you leave?" — and then be quiet. "What do you wish you'd known on day one?" "If you were interviewing there today, what would you push hard on?" These three cover 80% of what you need. Everything else you learn will be gravy.
Reach out to former engineers, current engineers you didn't meet during the loop, and — if you can find one — someone who was on the specific team you're joining. If you cannot find a single former engineer willing to spare 15 minutes for a call, that itself is data. Healthy engineering orgs produce alumni who feel warmly enough to help.
Reading between the lines on employee reviews
Employee reviews are the fourth check, not the first. They are directional, not decisive. Read them last, after you already have hypotheses to test.
Weight recency heavily. Culture changes with leadership. A five-star review from 2022 tells you almost nothing about the team in 2026. Filter to the last 12 months and read those first. If the last 12 months look meaningfully different from the last 36, you're looking at a company in the middle of a phase change — and the direction of that change usually matters more than the average.
Look for repeated language, not stars. One angry reviewer using the phrase "constant reorgs" is noise. Six independent reviewers using that phrase in six months is structural. The star rating is heavily gamed by HR-driven review campaigns; the language patterns are much harder to fake.
Read the cons more carefully than the pros. Pros are easy to write and often generic ("smart teammates, good comp"). Cons take real energy and reveal what specifically wore people down. If ten reviewers independently mention the same con, that's a load-bearing problem no interviewer will disclose to you.
Ignore the "I love it here" review posted the day after a bad TechCrunch article. You know the ones. Suspicious clusters of five-star reviews inside a two-week window, all from anonymous accounts with similar phrasing, are the internet's way of telling you the company is running a review-inflation campaign. The presence of the campaign is more interesting than the reviews it produced.
Our research across hundreds of company culture profiles keeps producing the same finding: the review signal is real, but it lags reality by six to twelve months. Use it as the last check on a hypothesis, not the first.
Red flags to run from
Some patterns are recoverable. These are the ones that predict a bad fit with high enough reliability that you should downgrade the offer, renegotiate hard, or walk away.
- A recently reversed remote or hybrid policy. Companies that promised remote in 2021 and yanked it in 2024 or 2025 have already told you what they will do the next time leadership feels anxious. If you're joining under the current policy, ask on the call: "How stable is the current policy?" — and then note whether the interviewer flinches. If your role depends on remote at all, browse companies with genuine remote cultures before you sign.
- Interviewers whose calendars are 90% meetings. Ask casually: "What does your typical Tuesday look like?" If the answer describes seven meetings and no focus time, that's the job. Meetings are load-bearing but calendars that full mean no deep work is happening.
- Layoffs in the last 12 months with no clear rehiring plan. Layoffs happen. The question is whether the team you're joining is rebuilding or shrinking further. Ask directly: "How has the team changed in the last year, and what's the plan for the next?" Vagueness here is telling.
- Refusal to share the comp band before the final offer. Modern engineering orgs publish or at least share comp bands. If a company refuses to disclose the range for your level before you commit hours to interviewing, the salary politics inside are probably worse than you think.
- No IC ladder past Senior. If the promotion path forces you into management at the L5 or L6 level, you're being told the org values managers over builders. That's a legitimate choice for some companies. It is not a choice you should discover the day after signing.
- Interviewers who cannot answer a hard technical question about the team. "What's the last hard technical decision this team made?" is a fair question. If nobody in your loop can answer it, either the team isn't making hard decisions, or the person interviewing you doesn't know what the team is doing. Both are problems.
Green flags most candidates miss
The good signals are quieter than the bad ones. They rarely show up in the pitch. Watch for them anyway.
- "Blameless postmortem" written into the job description. This is a small phrase that reveals a lot. Teams that mention postmortems as a normal artifact of engineering work are teams that have already normalized incident response as a learning process rather than a blame process.
- Open-source contributions from ICs, not just from a "developer relations" team. When individual engineers ship OSS on company time and get credited under their real names, the culture rewards external craftsmanship. That is unusual and telling.
- An engineering blog written by engineers, not marketing. Bylines matter. Posts written by named engineers — with technical depth their marketing team could not have generated — mean the org lets engineers speak in public. That freedom almost always maps to freedom in code review, technical decisions, and pushback.
- Public, specific comp bands. Not "competitive" or "market-rate." Actual numbers on the job posting. This is table stakes in 2026 for anyone claiming a healthy compensation culture, and companies that still hide bands are usually hiding something worth asking about.
- A "here's what we're bad at" answer during your interview loop. Ask every interviewer: "What's the thing about this team you'd fix if you could?" People who give a real, specific answer work somewhere they trust. People who say "honestly, I can't think of anything" work somewhere they don't yet feel safe telling the truth.
- Alumni who speak fondly. The strongest culture signal available to you: the LinkedIn messages from ex-employees that come back friendly, thoughtful, and unhurried. Nobody's paying them to say nice things. If they still do, the org treated them well on the way out. That is a leading indicator of how it will treat you.
Your final 48 hours
The offer expires soon. You've done the artifact check, run one or two interview loops, and made at least one reference call. Here's the checklist before you sign.
The 48-hour pre-signature checklist
Run each of these. Most take under 30 minutes. Skip none.
- Read the last three months of the engineering blog. If you can't stay awake, that's a signal.
- Pull the GitHub org. Check the last five PRs on their most-active repo. Read the review comments.
- Do one more back-channel call. Yes, even if you've already done one. The second call is where the pattern locks in.
- Read the last twelve months of employee reviews. Ignore stars. Look for repeated phrases in the cons.
- Ask for a 30-minute skip-level with your prospective grand-boss. Most companies will say yes if you ask. Their willingness to grant it, and how the conversation goes, is itself signal.
- Compare this offer against at least one other. Even a stale one from three months ago. Use the compare tool to line up the culture, comp, and structural signals side by side.
- Write down the three specific things you expect to be true on day 90. Team size, project scope, on-call load. Put the note in your own calendar. If those three things aren't true by day 90, the interview loop lied — and you'll want the evidence for the conversation that follows.
The offer will not get worse if you take another 48 hours. If it does — if the recruiter tightens the window because you asked for a skip-level or a reference conversation — that is possibly the most useful data point you'll receive in the entire process. A company that pressures you out of doing basic diligence in July will pressure you into worse things in November.
Every engineer who has ever regretted an offer will tell you the same thing: the signals were there. They were just quieter than the pitch. This is the playbook for hearing them anyway.
When you're ready, browse the culture directory for the companies you're considering, or use the compare tool to line up two offers side by side. For the reverse perspective — how the best companies evaluate you for culture fit — see the culture-fit interview questions guide and how to screen culture fit without bias.
Browse culture profiles for hundreds of companies
Every company on JobsByCulture is profiled with employee-reported culture data, work-life-balance signals, and values evidenced by verified reviews — so the last 48 hours before you sign go a lot faster.
Open the Culture Directory → Or browse open roles →