Finding a job is already a full-time job. Offer Max makes it a lot less painful. The Chrome extension captures any Job Description in one click. AI tells you how good your fit is before you commit to applying, rewrites your résumé in the recruiter's language, drafts the cover letter, autofills the tedious application forms, and preps you with the interview questions this team is likely to ask. Build your master profile once. Show up more prepared than everyone else.
How does the résumé rewrite actually handle specialized fields like engineering or academic roles where the jargon matters a lot, and does it need ATS-friendly templates or can you upload your own format?
@eymen4ufh
Great questions — two-part answer.
On jargon in specialized fields: The AI doesn't invent terminology — your profile is the source of truth. If you're a compiler engineer, phrases like "LLVM IR" or "loop unrolling" only appear in the tailored resume if you put them in your profile. When targeting a specific JD, the model anchors on the JD's exact wording and selects / rephrases from your existing bullets to bridge the two — it doesn't hallucinate a whole new domain. For academic roles specifically, we treat Publications, Patents, Awards, and Test Scores as first-class profile sections, so citations, PI names, conference venues, etc. get preserved exactly as you enter them.
Two honest caveats worth mentioning: (1) for very niche fields (specific semiconductor process nodes, regulated medical-device terminology, etc.) we recommend a bullet-by-bullet review before submitting — the AI is a strong reorganizer, not a domain expert. (2) Spending 2-3 minutes tweaking one bullet manually the first time usually pays off — the model picks up on your tone for future generations.
On templates: Four built-in templates (Modern, Classic, Minimal, Creative) — all deliberately ATS-parseable: single column, standard section headings, no tables / images / text-boxes. The PDF export is vector (not rasterized), so ATS text extraction is clean.
You can't upload your own template today — that's on the roadmap. What you can do: after generation you get the full editable markdown source — tweak it in the in-app editor, or copy it out into Overleaf / Word / any format your target company expects. A few users generate with us, then paste the content into a Word template their recruiter shared with them. It's a fine bridge until custom templates ship.
Happy to answer follow-ups!
I like that you're optimizing for the decision of "should I even apply?" instead of only making applications faster.
One thing I'm curious about: how do you prevent the match score from becoming overconfident? Great candidates often look like weak matches on paper because their experience doesn't fit the keywords, but that's exactly where the best opportunities can be.
Congrats on the launch! 🚀
@aryan787544 You're pointing at the hardest case for any keyword-based scoring — lateral pivots and career jumpers who look weak on paper but crush the interview. Nobody's fully solved this, us included.
A few things we lean on. First, matching is phrase-level, not literal — "microservices at Stripe" registers against a JD asking for "distributed systems" even when the words don't overlap. On top of that, when the model supports thinking mode (Google, Anthropic), we let it reason beyond keyword hits before it commits to a number. And finally the output isn't just the score — there's a "strategy" section next to it that surfaces transferable strengths the number alone can't capture.
But honestly the score is meant as signal, not verdict — we don't gate applications on it. A 40/100 with strategy notes saying "your payments experience translates directly to this fintech role, lead with the $4B/month figure" is often way more actionable than a 90/100 for a role you're overqualified for. Great candidates just have to trust the strategy more than the number.
Thanks for the 🚀 — this is exactly the question I wish more people asked about scoring systems.
@zzhao495 That's the part that caught my attention too.
I think treating the score as a signal instead of a verdict creates a strategic tradeoff that most AI recommendation products eventually run into. If it isn't handled deliberately, users gradually start trusting the explanation more than the outcome itself.
the resume-rewriting-per-JD part is the piece I'd worry about most - a lot of ATS systems and recruiters now specifically look for phrasing that's too perfectly matched to the job description, it reads as templated. curious how you're tuning that so it doesn't just produce keyword-stuffed resumes that get flagged instead of helping
@omri_ben_shoham1 This is a topic I’ve spent a lot of time thinking about over the past couple of months — probably more than is healthy for dinner-table conversation.
The main thing we do: the AI is never allowed to invent keywords. Everything in the tailored resume has to trace back to something in your actual profile. So if the JD wants "distributed systems" and you wrote "microservices at Stripe" — we bridge those two phrasings. If you never touched distributed systems, "distributed systems" doesn't magically appear. That's the failure mode you're describing, and it's the exact thing I've been trained (by dinner-table lectures) to prevent.
Add to that: hard word cap per bullet, quantification pressure, and the match-score panel exposes which JD requirements didn't match instead of trying to fake them. If the JD wants a PhD and you don't have one, we say "PhD requirement — not met" instead of writing "PhD-level research experience" 🙃
the autofill piece is the part I'd want to understand before trusting it with a real job hunt - a lot of the big boards (workday, greenhouse, some linkedin flows) actively try to detect and block automated form-filling, sometimes flagging the application itself. does offer max ever run into that, or is autofill scoped conservatively enough (just EEO/contact fields like you said) that it stays under whatever bot-detection these platforms run?
@galdayan Fair concern. Based on our research and conversations with people familiar with recruiting platforms, anti-automation systems generally seem to focus on high-volume, unattended application behavior rather than a user saving time on a few repetitive fields. They're not built to catch individual job-seekers using a browser tool to shave 30 seconds off tedious EEO forms. That's why something like Simplify has been around for years, has hundreds of thousands of users, and hasn't been blanket-banned by any major ATS — it's within the norm of "power user tooling", not adversarial behavior.
And honestly, Offer Max does even less than Simplify (we are still catching). Simplify actually tries to fill the whole application — cover letters, custom essay questions, everything. We deliberately don't. Ours is scoped to EEO/demographic and boilerplate contact stuff — the fields that are literally the same across every application you'll ever submit. From an ATS perspective there's just nothing to fingerprint: a radio button click is a radio button click, whether you tap it or the extension does.
So both technically (native events, user's own session, no bulk pattern) and philosophically (individual friction removal, not application farming), we sit comfortably on the safe side of what these detection systems are actually watching for.
@zzhao495 that all makes sense for the fields themselves, but I was thinking more about the wrapper - the extension has to detect it's on a job application page, find the right fields, and click them programmatically, which is a different fingerprint surface than the click itself. does the detection risk (if any) live more in that "recognize and locate" layer than in the actual fill? genuinely trying to understand where the line is, not being difficult about it.
@galdayan Really good distinction — and honestly the layer where I've spent the most time thinking. Let me walk through the three phases separately because they have very different detection surfaces.
Detecting we're on a job app page: This one's essentially invisible to the site. Chrome content scripts inject silently — the page can't enumerate which extensions the browser has installed (that's a browser security guarantee, not something we chose). Our manifest scopes us to specific hostnames (LinkedIn, Workday, Greenhouse, etc.), we're not sniffing every page you visit. No fingerprint here unless we add visible DOM markers to the page, which we don't.
Locating fields: Read-only DOM traversal — CSS selectors, label matching, ARIA attributes. This is identical to what every password manager and translation extension does. There's no observable difference between "extension is looking at the DOM" and "extension is doing nothing" from the page's perspective. Actually undetectable in any practical sense.
Filling: This is the layer where fingerprint COULD live, and where the honest tradeoffs are. Two specific risks worth naming:
Timing: filling 12 fields in 40ms is obviously mechanical. Real humans take seconds. We currently don't add artificial pauses — we probably should for Workday-tier detection, and it's on the near-term list.
Event sequencing: A real user's keystroke fires focus → keydown → input → keyup → blur. We dispatch input+change but skip the pointer/keyboard events. React-based ATSs (Workday, some Greenhouse) can inspect their internal state after a value= assignment and notice the property setter didn't come from a real user gesture.
So the honest answer: the fingerprint isn't in "recognize and locate" — that's essentially free. It's in the shape of the filling itself. What we lean on is (a) the fields we touch have few possible values (EEO is like 5 dropdown options), so even a suspicious fill still resolves to a legit-looking submission, and (b) the tight scope means the total fingerprint surface is small — we're not filling 40 fields, we're filling 5-8.
Genuinely appreciate the question being specific like this, it's making me think about what would tighten this further. Timing jitter is probably the highest-value next iteration.
I hate rewriting the same information for every single application, rewriting the same resume again and again for different jobs is tiring. How do you prevent that your resume rewrites from sounding similar to everyone else ?
@reda_roqai_chaoui Totally hear you on the "same info 50 times" pain — that's literally the reason the profile-based approach exists. You fill your profile once, we handle the rewrite per JD, and that alone kills most of the fatigue.
On the "everyone sounds the same" concern — the trick is we don't rewrite from a generic template. We rewrite from your actual bullets. If your profile says "Rebuilt Stripe's dispute-handling pipeline to hit 99.97% uptime during a 3× traffic spike", that specific wording, that specific number, that specific voice is what gets tailored. Two candidates targeting the same JD would still produce very different resumes because their profile inputs differ — the AI is selecting and reshaping, not writing from scratch. Generic-AI-voice only shows up when the profile itself is generic (which is a separate problem no tool can fix for you).
Two things help further: the AI is deliberately not templated — no "led X by doing Y resulting in Z%" scaffolding — and we picked Claude Sonnet 4.6 as the writer specifically because it has the best sense of tone across current mid-tier models. GPT-4o-mini would produce noticeably more formulaic output; it's cheaper but the difference in feel is real. Also, if you tweak one bullet manually the first time, the model tends to pick up on your voice for the rest — worth spending 2-3 minutes on your first generation.
How does it handle situations where the job description is vague or buried behind an apply button, like LinkedIn Easy Apply?
@ceylan1dzf
Two different problems packed into one question, both worth answering honestly.
Easy Apply specifically: The JD is actually visible on the LinkedIn job page itself — the "Easy Apply" button just triggers the form, it doesn't hide the description. Our Chrome extension scrapes whatever's currently rendered in the DOM. One gotcha: LinkedIn often collapses long JDs with a "See more" link — if the user hasn't expanded that, we only get the truncated version. So the practical advice is click "See more" first, then hit Import. We're looking at auto-expanding it in the next extension update.
Genuinely hidden JDs (some ATS redirects, some career pages that gate the description behind login) are the harder case. There's no scraping around content that isn't in the DOM. For those, the fallback is: paste the JD text directly into Offer Max's /generate page — same output, just skips the auto-scrape step.
Vague / thin JDs (the "seeking a passionate individual to drive impact" variety, all vibes no specifics): the tool doesn't invent detail that isn't there. What it does instead:
The score-match becomes low-confidence — we surface fewer keyword-match chips, which is itself a signal: "this JD doesn't tell us much."
The tailored resume falls back to profile-driven writing — pulling from what you did, in your voice, without over-fitting to weak JD signal.
We have a separate "Research Job" feature that pulls in company / role context to backfill some of what a vague JD leaves out.
Honest limitation: with a truly generic JD, tailoring degrades to "polished but generic" — which is still better than the base resume, but not as sharp as when the JD is specific. In that scenario I'd tell users to spend 30 seconds writing 3-4 bullet points about what they think the role probably wants (e.g. based on the company or team page) and paste that into the JD field. The AI turns manual signal into tailored output remarkably well.