This challenge is about building real software: clean architecture, predictable data flow, solid API interaction, and a UI that feels intentional. You’ll start with a simple leads table in a Next.js app and turn it into something that feels like it belongs in a production environment.
We care just as much about how you build as what you build.
Update the existing weird looking and raw leads table at /leads make it into a high-quality production-ready data table.
You’re taking the barebones leads table and turning it into something that feels genuinely usable. Here’s what we expect:
-
Interaction Layer
A proper table experience: a toolbar that shows up when rows are selected, bulk actions, real filtering options, multi-column sorting, inline edits, and interactions that don’t feel clunky. -
Data Model & API
Extend the Lead type with useful fields (status, priority, timestamps, tags, etc.). Wire up full CRUD against your MockAPI backend. The request flow should be predictable and not a mystery box. -
State & Logic
Handle loading, errors, and edge cases cleanly. Add caching so the table doesn’t refetch unnecessarily. Add a refresh mechanism. Use optimistic updates only if they actually improve the experience. -
Performance
Virtualize the rows so the table holds up with thousands of items. Keep renders efficient. Use memoization where it helps, not everywhere out of habit. -
UX Polish
Make it pleasant. Good spacing, readable columns, intuitive controls, clear feedback when things change, and no awkward flickers or jumps. -
Code Quality
Keep the components small and understandable. Write real TypeScript, notany-driven chaos. Structure things so another developer could jump in without crying.
- TanStack Table: https://tanstack.com/table/latest
- TanStack Virtual: https://tanstack.com/virtual/latest
- shadcn/ui Data Table example: https://ui.shadcn.com/docs/components/data-table
- tablecn (for inspiration around filtering, toolbars, etc.): https://github.com/sadmann7/tablecn
We want to see how you think and how you build. Can you break a messy problem into clean pieces, choose an architecture that actually makes sense, and know when performance matters instead of randomly over-engineering? Can you design something that works end to end, handles real-world edge cases, and feels good for actual users? Most importantly, can you explain your decisions clearly instead of hiding behind buzzwords.
Create your own fork of the project on GitHub.
git clone https://github.com/asentapp/grids.git
cd grids
npm install
# or
pnpm install
# or
bun installCreate a leads resource with at least:
interface Lead {
id: string;
company: string;
email: string;
website: string;
address: string;
phone: string;
// Add your extended fields here
}Take a look at .env.example and add your endpoint to .env.development.local
MOCKAPI_URL=https://YOUR_PROJECT_ID.mockapi.io/leads
npm run dev
# or
pnpm run dev
# or
bun run devKeep it simple:
- Fork the repo
- Build your solution directly on your fork
- Record a 5–10 minute walkthrough video explaining:
- Your architecture decisions
- How your system works
- Any trade-offs or limitations
- A demo of the finished features
- Push all your code to your fork
- Go to tally.so/r and submit your repo and video
No branches, no PRs. Your fork is your submission.