knorish Frontend Engineer Interview: Questions, Experience & Prep (2026)

Knorish is an Indian EdTech SaaS platform built for course creators who want to launch and sell online learning products. Frontend Engineers there work on the course player, the creator dashboard, enrollment flows, and checkout UIs. The product is React-heavy, with real demands around performance on video-rich pages and responsive design for mobile learners. Understanding both the creator side and the student side of the platform matters in interviews.

Knorish currently has 7 open Frontend Engineer roles (data: knok jobradar, July 2026). In the wider market, there are 405 active Frontend Engineer openings across India right now. Bangalore leads with 102 listings, followed by Delhi (36), Pune (11), Mumbai (6), Hyderabad (5), and Chennai (3).

Salary context based on knok jobradar data for Frontend Engineers in India:

Candidates report the Knorish interview process typically spans a few rounds covering a coding assignment, frontend fundamentals, and a product-focused discussion. The emphasis tends to be on practical, product-relevant problems rather than purely algorithmic puzzles.

Based on candidate reports and the nature of Knorish's product, these are the questions that come up most often:

1. Walk us through a complex React component you built. How did you manage state and side effects?
2. Knorish serves both course creators and students on the same platform. How would you approach building UI for two very different user types in one codebase?
3. How would you build a custom video player component in React? What edge cases would you need to handle?
4. Our course catalog page loads slowly on mobile. How would you diagnose and fix the performance problem?
5. Explain how you would implement lazy loading and code splitting in a React single-page application.
6. Describe a time you integrated a third-party payment gateway (like Razorpay) in the frontend. What challenges came up?
7. How do you handle API error states in a way that keeps the UI clear and user-friendly?
8. What does accessibility mean to you in an EdTech product? What specific things do you check for?
9. Have you worked with video streaming or media APIs? What did that experience teach you?
10. How would you design a reusable component library for a product with multiple portals (creator, student, admin)?
11. Tell us about a time you had to balance a designer's vision against technical constraints. How did you handle it?
12. How do you test frontend components? Walk us through your testing approach for a feature you shipped.

Q: Walk us through a complex React component you built.

*Situation:* At my previous company, we had a data table component used across several product pages, each with different sorting, filtering, and pagination needs.

*Task:* I was asked to refactor it into a reusable, composable component that different teams could configure without touching the core code.

*Action:* I broke the component into smaller pieces using a compound component pattern. I used React Context to share state like sort order and page index between the parent and child components. I moved server-state to React Query so each instance could fetch its own data independently, and I used useReducer for the complex local state transitions.

*Result:* The refactored component reduced duplication across the codebase. Other teams adopted it within a couple of sprints and the QA team reported fewer UI bugs tied to table interactions.

---

Q: Our course catalog page loads slowly on mobile. How would you diagnose and fix it?

*Situation:* I faced a similar problem at a startup where the homepage was taking several seconds to become interactive on mid-range Android phones.

*Task:* My task was to reduce Time to Interactive without changing the visual design.

*Action:* I started with Lighthouse and Chrome DevTools to identify the bottlenecks. The main issues were unoptimized images (no WebP, no lazy loading), a large third-party chat widget loaded eagerly, and unused CSS. I added next/image for automatic optimization, deferred the chat widget load, used dynamic imports for below-the-fold sections, and removed unused Tailwind classes with PurgeCSS.

*Result:* Time to Interactive improved noticeably. The product manager confirmed the improvement in the next user testing session, and our analytics showed a drop in mobile bounce rates.

---

Q: Describe a time you integrated a third-party payment gateway in the frontend.

*Situation:* My team was building a subscription flow for a SaaS product and needed to integrate Razorpay.

*Task:* I owned the frontend integration, including success, failure, and webhook-triggered status updates in the UI.

*Action:* I wrapped the Razorpay checkout in a custom hook that managed the loading state, error handling, and order creation API calls. I used optimistic UI for the success state but verified with the backend before unlocking features. I also wrote clear error messages for common failure cases (card declined, bank timeout) so users knew exactly what to do next.

*Result:* The integration shipped on time. Customer support tickets related to payment confusion dropped in the first month after launch.

For behavioral questions, use the STAR structure: Situation (brief context), Task (your specific role), Action (what you actually did, step by step), Result (the outcome, ideally something observable). Keep Situation and Task short. Spend most of your time on Action.

For technical 'how would you' questions, use a Problem-Approach-Tradeoffs structure. State the problem in your own words first (this shows you understood it), walk through your approach step by step, then name one or two tradeoffs you considered. Interviewers want your reasoning, not just the answer.

For component or system design questions, start with requirements: who uses it, what are the constraints, what does 'done' look like? Then move to structure, then edge cases. For Knorish specifically, always consider both the creator and the student as potential users when scoping a design problem.

Product empathy. Knorish builds for two audiences at once: creators who want powerful tools and students who want a smooth learning experience. Candidates who think about both users when answering design questions stand out.

React depth. Not just hooks syntax but when and why to use useMemo vs useCallback, how to avoid unnecessary re-renders, and how to structure state for maintainability over time.

Performance instinct. Video-heavy EdTech products live and die on load times, especially on mobile. Interviewers want to see that you treat performance as a default, not an afterthought.

Ownership mindset. Can you think beyond your ticket? Candidates who mention error handling, edge cases, and testing without being prompted show real product ownership.

Clear communication. Knorish teams are cross-functional. Being able to explain a technical tradeoff to a non-technical product manager is as important as the technical answer itself.

Step 1: Use the product. Spend time on Knorish as a student. Go through course browsing, enrollment, and video playback. Note what feels fast or slow, where the UX is strong, and where you would improve something. This is the single most effective preparation you can do.

Step 2: Build or review a relevant project. Have a React project ready that includes video playback, a complex form, and a responsive layout. Be prepared to walk through your state management decisions in detail.

Step 3: Practice Lighthouse audits. Run one or two audits on public pages. Know what each metric (FCP, LCP, TTI, CLS) means and how to improve it.

Step 4: Revise React fundamentals. Focus on useEffect, useCallback, useMemo, React.memo, context vs props drilling, and controlled vs uncontrolled components. These come up constantly.

Step 5: Review payment gateway flows. Know the basic frontend flow for Razorpay from button click to confirmation, including how to handle error states gracefully.

Step 6: Prepare your STAR stories. Have at least one story each for a performance fix, a cross-functional collaboration, and a technical tradeoff decision.

If you are actively applying, knok checks 150+ job sites nightly, applies to roles matching your resume, and messages HR for you, so you can focus on interview prep while it handles the search.

Describing React in theory without a real example. Saying 'I use useCallback for performance' means nothing without an example of where it actually helped. Always ground your answers in your own work.

Skipping the 'why.' Saying you chose a particular state management library without explaining why sounds hollow. Interviewers want your reasoning, not just the outcome.

Forgetting mobile. Knorish has a large mobile learner base. Any performance or design answer that does not mention mobile will feel incomplete to the team.

Vague testing answers. 'I write unit tests' is not enough. Say what you test (component behavior, not implementation details), which tools you use, and how you decide what is worth testing.

Not asking any questions. Candidates who ask nothing at the end signal low interest. One or two genuine questions about the product roadmap or team structure show you are evaluating them as much as they are evaluating you.