Top Products and Slow Endpoint Coding Challenge
سؤال انترفيو في رابيت (مصر) · المرحلة: تاسك في البيت · المجال: تصميم الأنظمة وSQL وقواعد البيانات · الوظيفة: مهندس باك إند · الصعوبة: متوسط · اتسأل 3 مرات، آخرها يناير 2025
What they ask
Backend candidates receive a coding challenge sized at three to four hours, delivered as a repository from the company's own GitHub organisation: a NestJS project with Prisma, a seed script, and a package.json you are told to read carefully because some of the installed libraries are there to help you. You bring any SQL database (Postgres or MySQL). Two requirements:
- Top 10 most ordered products in an area. A new endpoint for the app's home screen that returns the ten products ordered most often in a given area or region. It will be hit millions of times, so design it for that.
- Fix the slow products listing. The existing
GET /productsis deliberately badly written: inefficient queries and poor practices. Review it, refactor it, and you may change the request and response contracts (DTOs, filters) if that makes it faster and more reliable.
Plus tests that prove the top-10 endpoint is correct, documentation of your assumptions, and a note on what you would do with more time. Optional bonus: send a push notification (Pushover is suggested) when a new order is created. Submit as a public GitHub or GitLab link. The business framing in the brief: multiple stores across the region, thousands of orders a day.
The challenge is announced after the HR call. One senior candidate's "coding challenge" slot turned out to be a system design conversation instead, so confirm which one you are getting.
What they look for
- The top-10 query done with an aggregate and an index (or a precomputed table) rather than loading orders into memory, and cached, since the data changes slowly and the traffic is huge; Redis through the cache manager already listed in
package.jsonis the expected move. - The products endpoint fixed at the root: pagination, selecting only the needed columns, no N+1, filters pushed into the query, cursor or offset chosen and justified.
- Tests on the ranking itself: ties, areas with fewer than ten products, cancelled orders.
- An assumptions section that says what "area" means in your model and how stale the cached top-10 is allowed to be.