Mercor Software Engineering Roles: A Fit and Portfolio Checklist
Compare engineering role types on Mercor, check location and workload requirements, and prepare a portfolio that shows your actual contribution.
Before applying to a software-engineering role on Mercor, check three things: whether the location and time commitment work for you, whether the actual tasks match your experience, and whether you can show evidence of that experience. A familiar job title is only a starting point.
This is an independent preparation guide for opportunities listed on Mercor Explore, not a Mercor job advertisement or an official assessment guide. The examples below were checked on 10 November 2026. Listings can change or close, and a visible listing does not establish that a place is available for you. Open the original page before spending time on an application.
Three engineering roles, three different kinds of evidence
The selected listings illustrate why a single generic application can miss the point. These are examples, not a complete list of opportunities or a promise of eligibility.
| Listing checked | Important constraints in the listing | Portfolio evidence worth preparing |
|---|---|---|
| Senior Backend Engineer: Node.js, TypeScript, Rust | United States; 40 hours each week; W-2 employment through Cincinnatus LLC | A service you owned, a difficult integration, and an explanation of failure handling |
| Open Source Maintainer / Core Contributor | Sustained, verifiable open-source work; 30–40 hours weekly; restrictions on other AI engagements | Merged contributions, meaningful reviews, and proof that you can build and test the repository |
| MLOps Engineer: LLM Performance | The body says worldwide; 40-hour full-time engagement; no other engagements; ML systems rather than general data science | A reproducible profiling, kernel, distributed-debugging, or inference-serving investigation |
The final column is our preparation advice, not an extra Mercor requirement or a description of its scoring system.
There are details to clarify rather than guess. The open-source page's header says US, Canada and Europe, but its location field says USA. Its staffing description and independent-contractor section also warrant clarification about the actual arrangement. The MLOps page combines a full-time weekday commitment with general flexible-schedule language. Ask Mercor to confirm the country, contracting arrangement, hours and exclusivity that apply to your offer. Do not choose whichever sentence is more convenient.
Start with constraints before polishing a resume
Make a short decision sheet for the exact listing:
- Location: Which countries or regions are explicitly eligible? Does your location match? Remote describes where work happens, not necessarily who can be engaged.
- Availability: Can you meet the weekly commitment, required overlap and any exclusivity condition alongside your existing obligations?
- Work: Will you build production software, evaluate code, write tasks, review outputs, or investigate performance? Which have you actually done?
- Engagement: Who contracts with you? What does the final offer say about duration, equipment, payment and ending the engagement?
- Uncertainty: Which details are missing or inconsistent? Resolve those with Mercor before relying on the opportunity.
Mercor's referral FAQ says regional restrictions in a listing apply, and otherwise engagement depends on whether Mercor can contract and pay the person in their country. Check the current payment-country guidance as well as the individual listing. Neither a broad “remote” label nor this guide establishes your eligibility.
If a hard requirement does not fit, keep looking. Spending an evening tailoring evidence will not fix an incompatible location or a full-time commitment you cannot make. If a requirement is ambiguous, record the question rather than presenting an assumption as fact.
Build a compact evidence pack
A useful portfolio makes a claim easy to inspect. Choose one or two strong examples and explain your contribution precisely. Ten unexplained repository links leave the reader to do the matching themselves.
For each example, write six short sections:
- Problem: What needed to change, and what constraint made it difficult?
- Your contribution: What did you personally design, implement, debug or review? Distinguish your work from the team's.
- Decision: Which alternatives did you consider, and why did you choose this one?
- Evidence: Link the public change, review, test or documentation you are entitled to share.
- Reproduction: Give the version, setup and command needed to check the result.
- Limits: Explain what the example does not establish and what still needs improvement.
For a backend example, explain what happens when a dependency times out or a request is retried. For an open-source contribution, explain the maintenance consequences and reviewer feedback. For ML infrastructure, state the hardware, workload and measurement conditions alongside any performance claim. These are ways to demonstrate engineering judgment, not secret hiring criteria.
You can use a small personal project if it demonstrates the relevant skill, but label it honestly. A demonstration is not production experience. Similarly, contributing to an established repository is different from creating a repository yesterday. Do not imply that one satisfies a listing's requirement for the other.
A worked example: an unreliable background job
Here is an original portfolio exercise, not a Mercor task or an interview question. Imagine a small service that sends a notification after a job completes. Sometimes the notification provider receives a request but your service times out before it receives the response. A retry can then send the notification twice.
A weak description would be: “Built a scalable notification API with retries.” It names technologies and an intention without explaining correctness.
A stronger write-up would show the investigation:
| Part of the write-up | What the reader should be able to inspect |
|---|---|
| Failure scenario | A fake provider records delivery but deliberately times out before responding |
| Reproduction | A test sends the same logical job again and demonstrates the duplicate |
| Proposed change | A stable operation identifier and a clear explanation of where duplicate suppression happens |
| Verification | Tests for repeated requests, concurrent attempts, worker restarts and failed delivery |
| Remaining limitation | If the provider cannot deduplicate requests, explain what uncertainty remains after a timeout |
Do not claim exactly-once delivery merely because the happy-path test passes. If you only mark a job complete after sending, a crash between those steps can still cause a duplicate. If you mark it complete before sending, a crash can lose the notification. Explain the tradeoff and what support your chosen design needs from the provider.
The value of this example is the reasoning. Include a short README, a deterministic test and a clear account of the remaining failure mode. Avoid invented latency reductions or impressive-looking traffic figures. If you measured something, show the setup and the result you actually obtained.
For a portfolio that includes deployment, our Next.js deployment guide explains why a successful build and a safe release are separate checks. Our Nginx streaming guide is another example of describing a specific failure and testing the affected behavior.
Prepare to explain your own work
Revisit the example without reading your summary. Can you explain why the first approach failed, which evidence changed your mind, and what you would do with another day? Can you separate a measured result from an assumption?
Practice answering those questions in your own words. Follow the assessment's actual rules, including any restrictions on outside tools or assistance. This guide does not provide assessment answers or imply that practice questions will appear in a Mercor interview.
Keep confidential material out of the portfolio. Use public contributions, your own demonstrations or material you have explicit permission to share. Mercor's internet-use policy prohibits publishing client-specific work, completed-task content and other protected project material. Do not turn work from a previous Mercor engagement into a public application sample.
When to skip a role
Skip or postpone an application when the work is outside your experience, an explicit eligibility requirement does not fit, or you cannot meet the commitment. Ask for clarification when the listing contradicts itself. If the page is closed, a standing expression of interest or a future-opportunity listing, treat it that way rather than assuming an immediate opening.
Also separate an advertised rate from expected income. A listing does not tell you how many paid hours you will receive, whether you will be selected or how long a project will last. Read the actual offer and applicable terms before making plans around the work.
What the referral link does
The optional link below is Anup Bhandari's personal talent-referral link. It is not an application to Novastack, a hiring guarantee or a way to bypass Mercor's assessment.
Mercor's referral terms set eligibility and attribution conditions, exclude some work and candidates, and allow candidates to opt out. A click alone does not establish a payable referral. If a referral is disputed, Mercor can require written evidence of the candidate's acknowledgement. Review the name shown in Mercor's flow and confirm only a referral you recognize.
Apply only if the current opportunity fits. You can use the direct, non-referral Explore link below instead, and all of the preparation advice still applies.
