Mohsen Khojasteh Nezhad · Software Engineer · Front-end focused
Software Engineer with Deep Frontend Expertise
Responsibility
What I take responsibility for
Once the user, first useful outcome, and delivery boundary are clear, I can own a small web product end to end or a defined capability inside an existing product.
01
Turn the agreed requirement into a bounded implementation plan.
02
Build the interface and the connected application logic within that boundary.
03
Keep consequential decisions, dependencies, and blockers visible.
04
Hand over source, implementation context, and known limitations.
Documented experience
A short, evidence-backed timeline
These roles, dates, and education come from the public résumé. I describe only the responsibilities documented there and leave unverified results out.
Experience
2024–2025 (1403/08–1404/05)
Front-end Developer
Tat Bikeran Co.
Built and maintained React product components integrated with WordPress through the WP REST API.
View in the public résuméExperience
2024 (1403/01–1403/06)
Front-end Intern
HiWeb Holding
Built React and Redux interfaces within a team delivery workflow.
View in the public résuméEducation
Documented study period: 2020–2025
Computer software engineering education
Enghelab Eslami and Shahid Babaei National Universities of Skills
Associate and bachelor's-level study documented in the public résumé.
View in the public résumé
Three working principles
Each principle points to inspectable evidence
PRINCIPLE 01
Make the work inspectable
A working surface, visible source, and named limitations are more useful than a broad capability claim.
Related evidence
The bilingual portfolio and its delivery decisions are available in a public repository.
Inspect the portfolio sourcePRINCIPLE 02
Explain the decision, not only the stack
A technical choice is useful to an evaluator when its situation, alternatives, reason, and cost are visible.
Related evidence
The case study connects implementation choices to public source files and explicit trade-offs.
Read the Quaiz decision trailPRINCIPLE 03
Keep ownership and boundaries explicit
The useful promise is the part I can own and hand over—not an implication that every adjacent discipline is included.
Related evidence
The create-mohsen-app case separates the delivered workflow, public artifacts, and current limitations.
Review a bounded delivery story
Expectation contract
A clear working agreement
Good collaboration is two-sided. I make delivery visible and state limits early; the project supplies the context and decisions needed to keep that delivery useful.
See the four-stage collaboration processWhat you can expect from me
- An explicit delivery boundary before implementation starts.
- Early communication about decisions, dependencies, and blockers.
- Reviewable increments instead of a long invisible build.
- Source, relevant context, and known limitations at handoff.
What I expect from a project
- A named user, problem, and first useful outcome.
- Access to the context, assets, and systems needed for the agreed scope.
- A clear decision owner and feedback at agreed review points.
- Room to surface unknowns and adjust scope before they become surprises.
Now
Current focus
My current focus is product implementation for the web: a complete small build or a clearly owned capability inside an existing React or Next.js product.
- React, Next.js, and TypeScript product interfaces
- Connected application logic, data, and API integration
- Persian RTL and English LTR implementation
Language and credentials
Language and résumé
This portfolio and its project material are maintained in Persian and English. No formal spoken-language proficiency score is claimed here.
Start with the actual context
Share the product, role, or defined delivery you want to discuss. The first response should clarify fit and the next useful step.
