Verified team experience
Worked as a front-end intern at HiWeb, building React and Redux interfaces in a team workflow.
Documented in the public bilingual résumé; it supports React and Redux work in a team workflow.
Open supporting sourceFor recruiters and product teams
Assess role fit through evidence, not a technology checklist.
The public evidence covers front-end work in two team environments and independent Next.js products. The sections below separate verified experience from the working agreement I would bring to a new role.
60-second scan
Recruiter snapshot
The facts currently safe to use for an initial fit decision.
- Professional focus
- Front-end–focused web development
- Public location
- Tehran, Iran
- Portfolio languages
- Persian and English
- Role direction
- Front-end web product engineering
- Engagement shape
- Employment or a defined team contract—confirm directly
- Availability
- Confirm against the role and timeline
- Public code
- DonMohsen on GitHub
Current start date and preferred employment terms are not published as fixed facts; confirm them for the specific role.
Relevant evidence
Evidence for a role-fit decision
Team experience and public source are shown separately so a recruiter or engineering manager can inspect both.
Verified team experience
Worked as a front-end and WordPress developer at Tat Bikeran, integrating React components through the WordPress REST API.
Documented in the public bilingual résumé; it supports React components integrated through WordPress REST API.
Open supporting source
Verified public project
Designed and built this bilingual Next.js portfolio with audience-specific routes, project content, contact flows, and interactive planning tools.
A public bilingual Next.js codebase with audience routes, project narratives, and contact flows.
Open supporting sourceVerified public profile
Maintains public repositories under the DonMohsen GitHub profile.
The DonMohsen profile provides direct access to public repositories.
Open supporting sourceEvidence + behaviour
Engineering fit
Verified experience shows the environments and implementation work already documented. The proposed working agreement explains how I would enter a new team without presenting it as a past result.
Verified experience
React and Redux in a team workflow
Worked as a front-end intern at HiWeb, building React and Redux interfaces in a team workflow.
Open the résumé sourceReact integrated with an existing CMS
Worked at Tat Bikeran on React components integrated through the WordPress REST API.
Open the résumé sourceInspectable independent ownership
Public repositories expose implementation choices across this portfolio, Quaiz, create-mohsen-app, and Thelegroum.
Inspect the GitHub profile
Working agreement for a new role
These are proposed behaviours for the next role, not claims about every previous team.
- 1
Enter through context
Begin with the product goal, repository conventions, review path, and the people who own decisions.
- 2
Own a bounded outcome
Take responsibility for a clearly defined change rather than claiming ownership of an unfamiliar system too early.
- 3
Make change reviewable
Split work into understandable increments and expose blockers or decisions before they become surprises.
- 4
Close the loop
Leave the change, decisions, known gaps, and next owner understandable at handover.
Entry plan
A realistic first 30 days
A starting framework for learning before expanding ownership. The sequence adapts to the product and does not promise a predetermined business result.
Days 1–5
Understand the system
Learn the product goal, users, repository shape, team conventions, and review owners.
Visible output: a context map, open questions, and one candidate first change.
Days 6–14
Deliver a small reviewed change
Take one bounded change through the team's real implementation and review path.
Visible output: a reviewable change plus notes on conventions and unknowns.
Days 15–30
Grow into a defined outcome
Use feedback from the first change to own a larger but still bounded product outcome.
Visible output: the first agreed delivery, decision notes, and a clear next-scope recommendation.
The plan depends on access, team cadence, and the size of the first safe change.
Fit boundary
A useful fit—and an honest no
The boundary is part of the offer. It protects both sides from starting with incompatible expectations.
Good fit
- A front-end software engineering role centered on React and Next.js
- A team that assigns clear product outcomes, not isolated tickets only
- A role with collaboration across design, product, and back end
- A codebase where ownership can grow through reviewable delivery
Not the best fit
- A role whose primary work is outside web product development
- A position with no access to product context or delivery feedback
- A role described only by a long technology checklist
After the CTA
What happens next
No automatic commitment and no mystery call. The context is reviewed before a next step is proposed.
- 1
Share the role
Include the product, responsibility, team shape, location expectations, and hiring timeline.
- 2
Compare role and evidence
I will identify the strongest fit, the meaningful gaps, and anything that needs direct confirmation.
- 3
Choose an evaluation step
If the fit is plausible, the next step can be a focused conversation or an agreed technical review—not a generic project pitch.
Choose one concrete next step
- Relevant evidenceInspect create-mohsen-app
- Useful toolCompare stack trade-offs
- Your contextShare the role
