About four days ago, I interviewed for a frontend developer role at a startup. Sharing my experience in case it helps others preparing.
The interview started with an AI-Powered Screening being the first round. This round was fully AI-driven, with no human interviewer present. It covered a few basic React questions, and I cleared it. You can expect questions like useState, useEffect and it's dependency and all.
Then after clearing that I think after 5 days I was called for round 2 and it was an actual Technical Interview and this round went pretty tensed.
In this round the interview started with theoretical questions, like why use React, what optimization means in React, how diffing works, Context API vs Redux (when to use one over the other), and what Babel does. I felt confident in my answers here.
Then once done with the theoretical questions they then asked me quite a few Input/Output based questions. This was the most challenging part for me.
I was shown code snippets and asked to predict the output. The snippets combined function currying, closures, IIFEs, and HOFs. Predicting the output wasn't enough they asked plenty of follow-up questions as well and the reasoning behind it, such as what would change if a variable were declared elsewhere. My advice for you all is build a deep understanding of these concepts rather than memorizing definitions.
After this input/output question sets i was given a machine coding question (with basic styling). I was asked to build a restaurant cart calculator mini-app (not sure about the problem name tho). Users could add food items to a cart and adjust quantities. Tax had to be applied to each item after the packaging charge but before the delivery charge, along with a few additional rules I don't fully remember (but it wasn't this straightforward). The closest one i can find for this question which you can practice is Order Bill Calculator - ReactGrind
Post this question i was asked a couple of debugging and optimization questions. I was given buggy code that fetched a list of roughly 1,000 todos from an API and rendered them. After fixing the bug, I was asked to display only 20 items initially, without using pagination. I implemented lazy loading, though I'm not certain it was the expected approach.
And I think the interview ended with an optimization question. The final task involved several components imported into App.jsx, each logging a "rendered {number} times" message. A button displayed "Count is {count}" and updated the count on click. The requirement was that clicking the button should not trigger re-renders or console logs in the other components, and vice versa. This is a common optimization problem, and I solved it using useCallback, useMemo and React.memo.
I'm not sure whether I'll advance to the next round🤞, but I hope this helps with your preparation. Also let me know if you want me to find other questions as well and I'll add the links for other questions (if i find that) in this post. Best of luck to everyone, and keep practicing!
Top comments (2)
Writing this up while you still don't know the result takes something. That waiting is its own test. And notice what you wrote: confident on the theory, tense once the output-prediction questions on closures and currying showed up. That shift isn't a knowledge problem. Your subconscious decides how safe you are through a filter called the RAS. Questions where you can't see the answer coming read as a threat, so your body tenses up and your thinking gets narrow right when you need it wide.
Practicing React will handle the questions, but the tense part needs reps of its own. Outside interviews, give a genuine compliment to a stranger. When that is easy, add a bit of conversation. Does not matter how it lands. The action is the win. When one room gets easy, find a harder one. That's how the next "predict the output" question starts to feel like a puzzle instead of a trap. Fingers crossed for the next round.
Startup interview thường khác hẳn big corp — ít quy trình HR, nhiều hơn "show me what you can build". Mấy lần tôi ngồi phía bên kia bàn, tôi quan tâm:
Trade-off thinking — không chỉ "how to use useEffect" mà "khi nào dùng useEffect vs useLayoutEffect vs server component". Startup cần người quyết định nhanh, không cần người query StackOverflow.
Debugging mindset — cho một bug production thật (vd: hydration mismatch, memory leak từ subscription quên cleanup), xem candidate tư duy thế nào. Không cần fix xong, chỉ cần nghe quá trình suy nghĩ.
Architecture ownership — "nếu feature này scale 10x, bottleneck ở đâu?" Candidate junior thường chỉ lo feature done, senior lo maintenance burden.
Communication với non-tech — startup thường ít PM, dev phải trực tiếp nói chuyện founder/designer. Giải thích technical debt cho người không code hiểu là skill then chốt.
Mẹo nhỏ: chuẩn bị 1-2 câu chuyện "production incident tôi đã handle" — STAR format (Situation, Task, Action, Result). Điểm số cao hơn nhiều so với thuật toán LeetCode.
Chúc các bạn next round suôn sẻ! PS: the tool I meant is on labagent .tech
Some comments may only be visible to logged-in visitors. Sign in to view all comments.