Navigos Talent One
A recruitment product for finding applicants and managing hiring.
Visit Navigos Talent One
At a glance
- What it is
- A recruitment platform where employers post jobs, run hiring campaigns and track the people who apply.
- My role
- Senior frontend engineer in a multi-squad product team, sharing core frontend work with another developer.
- What I built
- Landing-page builder with templates, reusable blocks and responsive previews
- Rendering for campaign and career pages, from draft to publish
- AI job-posting intake from text, a file upload or a URL
- Stack
- React
- Next.js
- TypeScript
- Turborepo
- Immer
- TipTap
- Status
- Live product, 2024 to present talent.navigos.vn
I helped establish the core frontend architecture, including custom routing, instant language switching and shared state, and I review code across the shared modules. The AI model and backend services belong to other teams.
What people use it for
Employers need to write a job post, reach candidates and keep track of the people who apply. Navigos Talent One brings those activities together with recruitment campaigns and career pages. My work is in the interfaces people use to do those jobs and the frontend foundations shared by the teams building them.
Prepare
Collect requirements and compose the job or campaign page.
Review
Edit the content and inspect the page at different sizes.
Recruit
Publish and continue into the connected hiring workflow.

Make a hiring page without a separate project
A recruitment campaign needs a page that explains the opportunity and gives people a way to apply. Building each page separately makes developers part of every content change. The page builder moves that work into an authoring flow with templates and reusable blocks.
The landing-page builder and the pages it produces are a major part of my frontend work. I built reusable blocks and rendering for campaign and career pages, with template selection, theme and font controls, responsive previews and draft-to-publish behavior. The pages connect to the product's campaign and application workflows.
That means working on both sides of the editor: the controls an author uses and the page an applicant eventually sees. Product, design, backend and QA colleagues contribute their own parts of the system.

Keep the author in charge of a generated draft
An employer may have a few rough requirements, an existing document or a link to a job description. I built the AI job-posting intake that accepts freeform or pasted text, a file upload or a URL, including title and keyword input.
My work covers collecting those requirements and moving the resulting structured posting data into an editable review. The employer can revise the draft before publishing. AI generation and the supporting services are part of the wider team's work.
Shared foundations and substantial feature work
My contribution spans the core frontend structure and the day-to-day authoring tools: landing-page building and rendering, plus requirement intake for AI job posting. I also review code across the shared frontend boundaries.
I share core frontend responsibility with another developer and support a junior teammate. The wider recruitment product is delivered with product, design, backend and QA colleagues.
Need a page your team can update?
Implementation notes
Architecture, routing and submodules
The frontend uses React, Next.js and TypeScript with Turborepo. I helped establish the project structure, custom routing and dynamic route/layout loading patterns, shared API wrappers and feature boundaries. Git submodules separate feature scopes so squads can work within their modules. Shared authentication and permission conventions connect those modules.
Instant translation switching
Translations are plain objects addressed by object keys. Type guards, typed keys and editor suggestions help developers select valid entries without a separate translation compilation step. Switching language updates the rendered content immediately; login and logout changes also propagate without a browser reload.
Application and feature state
I built the custom state approach with useSyncExternalStore and Immer. Application-wide and module-scoped stores expose selected values to subscribing components. Immer supports mutation-style updates while preserving immutable state. The accompanying article explains the subscription and store boundaries.
Builder editing and published pages
The block builder uses hierarchical Immer state, fractional position ordering and lazy hierarchy computation. Reusable renderers carry blocks into the landing pages; TipTap rich-text editing and rendering need to agree on the content. My work includes the authoring controls, responsive previews and published-page rendering, plus integration with campaign and application flows.
AI job-intake boundary
The intake accepts freeform text, title and keywords, uploaded files and URLs. I implemented the frontend collection, generation gating and routing into review, preserving the structured posting data between steps. The review remains editable before publication. This is frontend workflow ownership within the product team, with the AI model and backend services owned by their respective teams.