Analysis, Custom Resume & Interview Prep
When INAJ finds a good match for you, it analyzes it automatically — no clicks required. By the time the job appears in your Good matches column, the full analysis is either ready or nearly ready. Open the role (click View on a card) and you land in its workspace. At the top sits the Actions panel — a checklist of everything you can do with this role: generate a tailored resume and cover letter, mark yourself applied, and prep for the interview. The panel tracks what’s done, runs jobs for you, and shows live progress as it goes.
The Actions panel
The panel starts collapsed as a single bar that shows how far along you are — e.g. “Actions · 2 of 4 done”. When something is running, the bar carries the live status and a countdown instead, like “1 task in progress · about 1m left”, so you can see what’s happening without expanding anything. Click the bar to open it.
Inside are four actions. While the automatic analysis is still finishing in the background, the resume, cover letter, and “mark applied” rows show “Analyzing this job…” and unlock as soon as it’s done; interview prep opens once you’ve generated a resume. Each row shows its state at a glance:
- Available — a checkbox and a rough time estimate. Tick the ones you want and run them.
- Running — a spinner and a live “about N left” countdown.
- Done — a green check and a View → link that jumps straight to that result on the page (or opens the resume / cover-letter PDF).
- Locked — greyed out, with the reason it's not available yet (e.g. “Analyze this job first”).
You can tick several available actions and start them together with Run selected — they queue up and the bar tracks the whole batch. Here's the panel mid-flow, with the analysis done and the resume building:
Analysis (automatic)
For every Good match, INAJ runs the full analysis automatically — there is no “Analyze” button to click. The job appears in your Good matches column only after the analysis is complete, so the write-up is already there when you open the workspace.
The analysis covers: Role Summary, Fit Assessment (what matches and what doesn’t), Skill Gaps, Strengths (what in your background is particularly relevant), and a Customization Plan for your resume. Most analyses complete within 1–3 minutes of the initial evaluation.
If you open a role while its analysis is still running (it just appeared in your feed), the Actions panel shows “Analyzing this job…” in place of the Generate Resume and Generate Cover Letter rows. The page refreshes itself automatically when the analysis finishes.
Here's what a completed analysis looks like:
Role Summary
| Attribute | Detail |
|---|---|
| Role type | Individual Contributor |
| Domain | Infrastructure / Platform |
| Function | Site Reliability / Platform Engineering |
| Seniority | Staff |
| Work mode | Remote (US timezone overlap required) |
| Team size | 10–15 engineers across two sub-teams |
| TL;DR | Own reliability and capacity planning for a distributed data pipeline serving 50 M events/day; drive the on-call rotation overhaul the team has been deferring. |
Match with CV
| JD Requirement | Your Experience |
|---|---|
| 5+ years SRE or platform engineering at scale | 7 years; Acme Corp platform team (2022–present) + prior infra role at Initech |
| Led migration of a monolithic system to distributed architecture | Drove monolith→microservices migration at Acme — directly matches the TL;DR ask |
| Kubernetes (EKS or GKE) — production ownership | Owns EKS clusters at Acme; authored cluster autoscaler runbooks |
| On-call program design or overhaul | Not explicitly stated in CV — worth surfacing if you have informal experience here |
| Strong written communication / RFC authorship | CV lists two architecture RFCs merged to company standards; strong match |
Fit Assessment
Strengths: The platform migration experience is the strongest signal — the JD spells out that problem explicitly. Your Kubernetes ownership and tenure are direct matches for the level and scope. Written communication history differentiates you at Staff level where influence-without-authority matters.
Gaps: On-call program design is the only named requirement that doesn't appear in your CV. If you've touched this informally, the custom resume will add a bullet; if not, be ready to address it in screening.
Skill Gaps
No hard blockers. The on-call program gap is soft — the JD frames it as a project to drive, not a baseline credential. Strong overall fit.
Generate Resume
Once the automatic analysis is complete, the Generate Resume action is available in the Actions panel.
The generated PDF is the same resume you uploaded, re-emphasized for this specific posting — the same accomplishments, re-framed around what this hiring manager is scanning for.
Download the PDF and apply directly.
Updated your CV or profile and want this resume rebuilt? Open the resume and click Re-generate resume in the header. It rebuilds just this one PDF (and its “What we tailored for this role” change log) from your latest details — nothing else re-runs, and it doesn’t change whether the role is marked applied. Give it about a minute, then refresh the page to see the new version.
Produces a PDF tailored to this posting · Usually ready in under a minute.
Along with the PDF, INAJ shows you a change log explaining every edit it made and why — so you know exactly what was re-framed and what the risk is if you revert it:
What we tailored for this role
| Section | Original | Tailored | Why | Risk if you reverse it |
|---|---|---|---|---|
| Summary | ‘Led platform migration from monolith to distributed system across Acme Corp’s infrastructure…’ | ‘Staff Platform Engineer with 7 years leading reliability and migration programs for distributed systems at scale…shifting teams from ad-hoc deployments to SLO-driven, automated delivery…’ | The JD’s first requirement is SLO ownership; adds that vocabulary and the reactive→proactive narrative that appears verbatim in the key responsibilities section. | Generic framing applies to a wider range of roles; reverting keeps you competitive for non-SLO-focused infrastructure positions. |
| Skills section | Not present in original | Added 6 keyword-dense phrases: SLO & Error Budget Design, Kubernetes (EKS) Ownership, CI/CD Consolidation, Platform Migration, On-Call Program Design, RFC Authorship. | ATS keyword density and hiring panel scanability; all 6 map directly to named sections in the JD. | These phrases are tuned to this platform/SRE role; a broader skills list performs better for general software engineering applications. |
| Acme Corp bullet 1 | ‘Responsible for the installation, configuration, and maintenance of the platform infrastructure’ | ‘Owned platform reliability for 15 internal product teams; drove monolith→microservices migration over 14 months with zero SLA breaches…’ | Replaces operational/maintenance framing with outcome-ownership language that matches Staff-level scope expectations; Staff is defined as owning results, not executing tasks. | Operational framing is accurate and appropriate for Senior IC or M3-adjacent roles; reverting reads as executor rather than owner. |
| Acme Corp bullet 3 | ‘Reduced deployment incidents by implementing rollback automation’ | ‘Designed automated canary rollback triggers; cut mean time to recovery from 22 min to under 4 min across 15 teams…’ | The posting explicitly names on-call process design; adding MTTR numbers and the canary detail mirrors the key responsibilities language directly. | The original customer-impact framing is broader; reverting preserves applicability to infrastructure roles where MTTR framing is less central. |
Generate a cover letter
Once the automatic analysis is complete, the Generate Cover Letter action is available in the Actions panel — right alongside Generate Resume, so you can run both together. INAJ writes a one-page PDF cover letter tailored to the company and your background, in a natural, human voice you can send as-is or tweak.
When the letter is finished, the row turns green with a View → link, so you can read it right in the page or download the PDF.
Cover letters have their own monthly allowance: you can generate up to 100 per month, and the count resets at the start of each month, the same as your tailored resumes.
One-page PDF tailored to the company and your background · Up to 100 per month.
LinkedIn outreach contacts
When you generate the customized resume, INAJ also looks up the people worth contacting at that company — the hiring manager, a recruiter, and a few people on the team you'd be joining — and adds a LinkedIn Outreach Contacts section to the bottom of the report. For the best target it drafts a ready-to-send LinkedIn connection message (under 300 characters) you can copy, tweak, and send, plus a couple of alternates.
Titles change, so verify each person's current role on LinkedIn before you reach out. If INAJ can't confidently find anyone, the section tells you so and points you at a LinkedIn search to run yourself.
LinkedIn Outreach Contacts
Here are the people worth contacting at Acme Robotics about the Staff Platform Engineer role. Verify each person's current title on LinkedIn before reaching out.
- Dana Reyes — hiring manager (Director, Platform Engineering) · primary target
- Sam Olufemi — recruiter (Technical Recruiter)
- Priya Natarajan — team peer (Senior SRE)
Suggested message to Dana (the hiring manager):
Hi Dana — I saw the Staff Platform Engineer opening on your team. I led a monolith-to-microservices migration with a 99.9% SLA at Acme Corp, which lines up closely with the reliability and migration work in the posting. Would love to connect and learn more about what you're building.
Interview Prep
Once you've generated a resume, the Interview Prep action unlocks in the Actions panel.
INAJ generates a prep brief covering: company background and recent news, the team you'd be joining, likely interview questions for this role, and your strongest answers based on your background.
Generates a prep brief · Covers company research, team background, and likely questions.
Here's what a completed interview prep brief looks like:
Company Deep Dive
Strategy and Product
Acme Robotics is a mid-stage industrial automation company ($180 M ARR, Series D) building warehouse automation systems for e-commerce fulfillment centers. Their core product is an orchestration layer that coordinates fleets of autonomous mobile robots (AMRs) across large facilities. The platform engineering role sits inside the infrastructure org that keeps that orchestration layer running — 99.9 % uptime is a contractual SLA, not an aspiration.
Their stated roadmap priorities are expanding into cold-storage facilities (harder real-time constraints) and building a multi-tenant SaaS offering on top of their existing on-premise platform. The platform migration experience in your background is directly relevant to the second priority.
Recent Moves (last 6 months)
Acme Robotics does not publish engineering-level technology news at the cadence of a software company. The signals below are drawn from job postings, LinkedIn activity, and press releases. Treat anything here as directional and verify against recent news before your interview.
- Kubernetes-first hiring wave: Four of the last six infrastructure hires listed Kubernetes as a primary requirement — consistent with a team standardizing on container orchestration ahead of the SaaS buildout.
- SOC 2 Type II certification announced: Press release from March 2026 cites completion of their first SOC 2 audit. Expect compliance guardrails to be part of the conversation — they've recently learned what "audit-ready infrastructure" costs in practice.
- Parallel VP Engineering hire: LinkedIn shows they posted a VP Engineering (Platform) role alongside this one — a signal that this team is being stood up deliberately, not backfilling an existing org.
Engineering Culture
The JD signals a team that is in the process of building discipline, not one that already has it. Expect inconsistent IaC maturity across services, a mix of handcrafted and automated deployments, and a strong emphasis on reliability over velocity given the SLA commitments. You'd be arriving to create the standards, not enforce ones that already exist.
Tech stack signals from the JD:
- Cloud: AWS primary; some GCP workloads for ML inference.
- Orchestration: Kubernetes (EKS), moving from Docker Compose on-premise deployments.
- CI/CD: GitHub Actions listed; Jenkins implied by legacy references — a heterogeneous mix that is part of what this role is meant to consolidate.
- Observability: Datadog mentioned; some teams still on home-built alerting.
Likely Challenges
- Legacy on-premise install base: Existing customers run on-premise. Any SaaS migration involves parallel maintenance and careful customer migration sequencing — exactly the problem you solved at Acme Corp.
- On-call culture reset: The JD calls out "on-call program overhaul" explicitly. Expect the current rotation to be ad-hoc and pain to be high.
- Cross-team IaC adoption: Standardizing Terraform across teams that have been writing their own CloudFormation is a change management problem as much as a technical one.
Interview Plan
Likely Questions (with your strongest answers)
Q: How would you approach migrating a platform from on-premise to a multi-tenant SaaS architecture?
A: At Acme Corp I led a monolith-to-microservices migration that covered roughly the same set of concerns — decomposing a tightly coupled system, maintaining existing customers during the transition, and building the observability and deployment tooling to operate the new architecture safely. My approach was: first build the shared infrastructure plane (networking, secrets, observability) before moving any workloads, so each migration is a lift-and-shift into a known-good environment rather than discovering infrastructure gaps mid-migration. The mistake I'd avoid is letting the scope creep into feature parity work — the first SaaS milestone should be "operationally equivalent to what customers have today," not "and here are three new features."
Q: Tell me about a time you owned reliability for a system with contractual SLA commitments.
A: The platform at Acme Corp serves internal product teams with a 99.9 % availability commitment. The biggest reliability lesson I took from that was that most SLA breaches trace back to deployment risk, not hardware failure. I drove the team to instrument every deployment with automated rollback triggers — if error rate climbs more than X % within five minutes of a deploy, we roll back automatically without a human decision. That change cut our mean time to recovery from 22 minutes to under 4 because we stopped waiting for an on-call engineer to diagnose before acting.
Q: What's your approach to getting a team that's resistant to IaC adoption on board?
A: Resistance usually comes from one of two places: engineers who feel like IaC is overhead that slows them down, or engineers who've been burned by IaC tooling that was more complex than the problem it was solving. The approach that's worked for me is starting with the infrastructure that already causes the most pain — if provisioning a new environment takes three days of ticket-passing today, automating that first creates a win the skeptics can point to. I've found that the second or third person to use a module you built is more persuasive than anything you can say about best practices.
STAR Stories from Your Resume
Monolith-to-microservices migration at Acme Corp
- Situation: Acme Corp's platform was a monolithic Rails application serving 15 internal product teams. Deployment windows required coordinating across all teams, a single failure could affect the entire platform, and scaling any component meant scaling the whole application.
- Task: Lead the architectural migration to a microservices-based platform while maintaining 99.9 % availability for existing teams and without a feature freeze — product teams continued shipping throughout the migration.
- Action: Defined service boundaries with domain leads, established the shared infrastructure plane (EKS, service mesh, centralized secrets), migrated services in dependency order starting with the least-coupled leaf services, and built automated canary deployments so each migration could be validated before cutover.
- Result: Completed the migration over 14 months. Deployment frequency increased from weekly coordinated releases to per-team continuous delivery. P95 latency for the highest-traffic services dropped 40 % after right-sizing. No SLA breach during the migration period.
- Reflection: The hardest part wasn't technical — it was getting teams to own their own deployment pipelines when they'd always had a central team do it. I would have started the team enablement work earlier rather than treating it as something that would happen naturally once the infrastructure was ready.
Watching progress
When an action is running, the Actions bar carries its live status and a countdown — “1 task in progress · about 1m left”, or a tally and total time when you've started several at once. You stay on the page; the rest of it stays readable, and it refreshes itself with the new results when each job finishes. As each action completes, its row turns green with a View → link to the result. If something gets stuck, run it again from the panel. The queue is shared across every action — analyses, resume and cover-letter generations, and interview preps all go through the same pipeline.