FRONT-End ENGINEER

Front-End Engineer (Next.js & Performance)

Company: Gradientflo Location: Remote Type: Full-Time / Contract Reporting to: Engineering Lead

About the Role

You will own the front-end architecture for Gradientflo's core web applications. This is not a role for someone who just "makes things look good." We need an engineer who understands the React reconciliation process, cares deeply about Core Web Vitals, and writes self-documenting code.

You have roughly 3 years of experience. You have moved past "making it work" and now focus on "making it scale." You will be working with server-side rendering, complex global state, and SEO critical implementations. We value clear writing, clean architecture, and strong debugging skills above all else.

Core Responsibilities

• Architect high-performance pages using Next.js (App Router).
• Manage complex application state using Redux Toolkit (RTK).
• Audit and optimize application performance (LCP, CLS, FID) using React Profiler and Lighthouse.
• Refactor legacy components into reusable, strict SOLID compliant UI patterns.
• Design custom hooks that abstract logic cleanly without causing "dependency hell."
• Implement SEO best practices (Structured Data, Dynamic Metadata, sitemaps).
• Debug complex race conditions and rendering issues using Chrome DevTools.
• Write strict TypeScript to eliminate runtime errors.
• Conduct code reviews focusing on performance impacts and maintainability.

Technical Requirements

Must-Have Skills

• React.js & Next.js (3+ years experience)
• Redux Toolkit (Slices, Thunks, Selectors)
• Performance Optimization (Memoization, Lazy Loading, Code Splitting)
• TypeScript (Generics, Utility Types)
• Deep understanding of React Hooks (useCallback, useMemo, useReducer)
• Strong Debugging skills (knowing why a component re-rendered)
• SEO Expertise (Next-SEO, JSON-LD, Open Graph tags)

Strong Pluses

• Experience with Headless CMS integration
• Experience writing unit tests (Jest / React Testing Library)
• Knowledge of Web Accessibility (WCAG)

Technical Task (Mandatory Assessment)

Project: Real-Time Asset Tracker (Simulated) Objective: Build a widget that tracks asset prices via simulated polling. This task is designed to expose how you handle complex effect dependencies, stale closures, and memory leaks when a component unmounts.

Data Source Note: Do not use a real external API. You must use Static JSON Data stored locally (e.g., data.json) and simulate network latency/random price fluctuations using setTimeout.

Functional Requirements

1. The "High-Dependency" Hook (useAssetTracker) You must implement a custom hook that manages data polling. It must accept all of the following dependencies in its arguments:

1. assetID (string, e.g., "BTC")
2. currency (string, e.g., "USD")
3. pollInterval (number, e.g., 3000ms)
4. alertThreshold (number, user-defined price alert)
5. isAutoRefreshEnabled (boolean)
6. userTier (string, affects polling speed)
7. onAlertTriggered (function, callback to parent)

The Logic Challenge:

• Simulation: The hook should "fetch" data from your static JSON, adding a random delay (500ms to 1500ms) to simulate a network request.
• Polling: When isAutoRefreshEnabled is true, fetch new data every pollInterval.
• The Trap: If the user types in the alertThreshold input (updating the dependency), it must not reset the polling timer.
• The Constraint: You are forbidden from using eslint-disable-next-line react-hooks/exhaustive-deps. You must solve the dependency array stability using useRef or split effects.

2. Mandatory Lifecycle Cleanup

Your implementation must handle the "Unmount" event gracefully:

• Async Cancellation: Since you are using setTimeout to simulate an API, you must ensure that if the component unmounts while the timeout is pending, the state update is cancelled.
• Timer Cleanup: clearInterval must be called immediately if assetID changes or the component unmounts.
• Proof: Add a console.log('Cleaning up resource for:', assetID) in the return statement of your effect.

3. Redux Toolkit & State

• Store the fetched price history in a Redux Slice.
• Use a Memoized Selector to calculate the "High/Low" of the session.
• Performance: Ensure that updating the price history only re-renders the Chart/Price component, not the entire Page Layout.

4. SEO Implementation

• Create a dynamic route: /market/[assetID].
• Inject dynamic Metadata (Title/Description) based on the assetID.
• The page must be indexable by bots (Use Server Components for the shell, Client Components for the tracker).

5. Clean Code Requirements Mandatory rules:

• No useEffect for derived state (use useMemo).
• Strict SOLID alignment (Single Responsibility components).
• No any types in TypeScript.
• Proper separation of container logic vs. presentational components.

Submission Requirements

1. GitHub Public Repository

Your repo must include:

• README explaining how you solved the "Timer Reset" issue when the alertThreshold changed.
• Architecture Diagram: A simple diagram showing how data flows from your Static JSON -> Hook -> Redux -> UI.
• Local run instructions.

2. Pull Requests to Raise (The "3-PR Rule")

You must create 3 distinct PRs to simulate a real workflow:

• PR 1: Project Setup

  • Next.js scaffold, TypeScript config, Redux Store setup, Static JSON file creation.

• PR 2: The Core Logic

  • The useAssetTracker hook with all 7 dependencies.
  • The "Simulated API" service layer.
  • Redux Slices.

• PR 3: Performance

  • UI Polish.
  • React.memo optimizations.

3. Loom Video (Mandatory)

Record a 5 to 10 minute Loom video covering:

• The Cleanup Demo:

  1. Open Chrome DevTools Console.
  2. Start the tracker.
  3. Navigate away from the page while it is waiting for the "simulated" data.
  4. Show that your cleanup log appeared and no React warnings (e.g., "update on unmounted component") occurred.

• Code Walkthrough: Explain how you used useRef (or your chosen method) to handle the alertThreshold dependency without breaking the linter rules.

• SEO Check: Inspect the page source to show the generated Metadata tags.

Evaluation Criteria

• The Dependency Array: Did you list all 7 dependencies? (Omitting one is a fail).
• Stability: Does changing the Alert Threshold cause the timer to jitter/reset? (It shouldn't).
• Cleanup: Is the setTimeout or setInterval actually cleared on unmount?
• Code Clarity: Is the code clean, readable, and formatted?
• SEO: Is the metadata correctly generated server-side?
• Process: Did you follow the 3-PR structure?