Methodology
How we evaluate career tools
The questions, evidence and limitations behind a useful recommendation—not a badge purchased with a commission.
The key point
We evaluate a tool against a task, not against its commission. The launch directory is not a hands-on ranking; future reviews must state what was researched or tested and explain meaningful tradeoffs.
What the current directory means
The current tool directory is a source-based overview, not a scored test of the market. It lists a small group of products that address different tasks. No numerical ratings, testing hours or hiring-success rates are assigned.
A provider's published feature is evidence that the provider advertises it; it is not independent proof of the feature's quality. A trial or paid test must be documented before we describe our own experience with a product.
Start with the reader’s task
A resume builder, a job tracker and an interview simulator solve different problems. We first identify the task, the reader's constraints and the outcome the tool can realistically provide.
| Area | What to investigate |
|---|---|
| Task fit | Does it address the actual obstacle: formatting, tailoring, organization or rehearsal? |
| Usability | Can the reader complete the task, correct mistakes and export a usable result? |
| Cost | What is due now, what renews, what is limited and what is available without paying? |
| Privacy | What information is uploaded, what permissions are requested and what deletion controls are described? |
| Limitations | Where does the tool need human checking, and what cannot its output establish? |
| Alternatives | Would a document editor, spreadsheet or practice partner be enough? |
Use the right evidence for the claim
For pricing, plan limits and cancellation, use the provider's current plan and terms pages. For a workflow observation, document what was actually attempted, on which plan, and what happened. For an ATS claim, distinguish a specific system's documentation from a claim about every employer.
User discussions can suggest issues to investigate. They cannot by themselves prove a representative satisfaction level, an employer-wide policy or a causal improvement in hiring chances. A review of user sentiment should identify the source, approximate period and relevant product version or role where known.
If sources conflict or a detail is unavailable, say so. Do not fill the gap with an estimate disguised as a fact.
What a future hands-on test must show
A useful test record identifies the date, plan, scenario, inputs, output and limitations. For example, a resume-builder test could check whether the exported file preserves sections and whether editable text is retained. It cannot establish that employers will select the applicant.
Do not upload real identity documents or another person's resume without permission. Test examples should be labeled and should not be submitted as real applications to employers. We will not claim that such tests have already taken place.
How recommendations should be explained
Use a specific conclusion such as “an option for keeping applications in one place,” supported by the feature and its tradeoff. “Best overall” requires a defined comparison set and criteria; it must not be attached merely because a referral was approved.
When criteria are weighted, publish the rationale. Price may matter more to an occasional user; export quality may matter more to someone editing many resumes. Changing that weighting can change the answer, so a single winner is not always appropriate.
Updates, commercial relationships and corrections
Dates should change when the content is substantively checked or revised, not automatically every day. A correction that changes the conclusion should be noted on the article.
Paid links must be disclosed where they appear. The commercial disclosure and editorial guidelines apply alongside this method. Send a source and page URL through Contact when you find a detail that needs attention.
Something needs correcting? Send the page URL and the detail we should check.