Assessment tips
- Confirm the current Intuit pattern from the drive mail before practising old papers
- Finish one problem or section fully before starting the next
- Revise the fundamentals listed in the round table on this page
Intuit’s loop mixes a Glider-based online assessment with standard technical rounds, then adds a live Craft Demo where SDE-2+ candidates extend a real codebase instead of solving a fresh whiteboard problem.
| Round | Duration | What it tests |
|---|---|---|
| Recruiter screen | 30-40 min | Background, motivation, location/comp, logistics |
| Online Assessment | 60-90 min | 2-4 DSA problems on the Glider platform |
| Technical interview(s) | 30-60 min each | Coding, OOPs/DBMS/OS fundamentals, project deep-dive |
| Craft Demo (SDE-2+ / senior) | ~90 min | Live coding on a shared codebase - tests, error handling, communication |
| System design (SDE-2+) | 45-60 min | Scalable design and trade-offs (storage, notifications, etc.) |
| Hiring manager / HR | 20-30 min | Values fit, Design for Delight thinking, closing logistics |
Profile: B.Tech CSE, ~4 years experience, applied off-campus after a referral, comfortable with mid-level DSA
Recruiter screen
Online Assessment
Technical rounds
Craft Demo
Hiring manager / HR
Result: Selected What helped: Narrating trade-offs out loud during the Craft Demo instead of coding in silence, and tying the follow-up answer explicitly to Design for Delight.
Takeaways
Profile: B.Tech IT, Bengaluru-based early-career program, one internship, average contest rating
What differed
Mistakes that hurt other candidates in the same cycle
Result: Selected after HR Takeaway: At Intuit, a clean OA plus a values-specific HR story usually beat strong DSA with a generic “why us” answer.
Takeaways
Profile: ~4+ YOE, recruiter outreach on LinkedIn, strong OA score (~94% reported)
Online Assessment
Phone / onsite Craft loop
Result: Rejected - feedback emphasized wrong HTTP status codes and weak exception handling on APIs, not algorithm failure.
Takeaway: Intuit’s Craft loop treats API robustness as binary signal; practise @ControllerAdvice, validation errors, and idempotent retries before the onsite.
Profile: Lateral with competing offer; four back-to-back craft interviews after eliminator OA
Craft Demo (90 min)
Result: Offer received (declined for remote preference) - recruiter noted strong craft round when tests and Postman demo were crisp.
Takeaway: Requirements discussion and scalability talk are part of the score; silent coding after a vague prompt is risky.
Profile: Referral, phone screen then two-week craft project prep
Phone screen (60 min)
Craft round (60 min, four-person panel)
Team member rounds
Result: Rejected after team rounds - craft presentation strong but behavioral/team fit did not clear.
Takeaway: Intuit referral loops still demand concise HLD narration and production-debug stories, not only the craft repo.
After technical rounds, Intuit closes with a hiring-manager/HR conversation that checks fit against its five operating values - Integrity without Compromise, Courage, Customer Obsession, Stronger Together, and We Care and Give Back - alongside location, compensation, and notice period. Prepare those answers on the dedicated page rather than cramming them into this hub.
Use these as frames, not scripts - interviewers probe follow-ups.
Q. Design a data structure supporting insert, delete, and getRandom in O(1).
A. Combine a dynamic array with a hash map from value to that value’s index in the array. Insert appends to the array and records the index in the map. getRandom picks a uniformly random index into the array, which is O(1) precisely because the array is dense with no holes. The trick is delete: instead of removing from the middle and shifting, look up the index of the target, swap in the last element of the array, update that moved element’s index in the map, then pop the last slot and erase the target from the map. All three operations are O(1) average and the structure uses O(n) space. The follow-up variant that allows duplicates replaces the map value with a set of indices per value.
Q. Given a binary tree and a list of values to delete, return the remaining forest.
A. Do a post-order traversal so children are processed before their parent, carrying the deletion values in a hash set for O(1) membership checks. At each node, recurse left and right first, then check whether the node itself is to be deleted: if it is, add its surviving children to the result list as new roots and return null to its parent so the parent unlinks it; if it is not, return the node unchanged. After the traversal, add the original root to the result only if it was not itself deleted. This is O(n) time and O(h) space for the recursion stack. Post-order matters because you must know whether a child survived before you can decide whether it becomes a new root.
Q. Implement decode string - for example, 3[a2[c]] returns accaccacc.
A. Use two stacks, one for repeat counts and one for partial strings, walking the input once. On a digit, accumulate the full multi-digit number. On an opening bracket, push the current count and the current partial string, then reset both. On a closing bracket, pop the count and the previous string, and set the current string to the previous string plus the current string repeated count times. On a letter, append it to the current string. This runs in O(total output length) time and O(depth) stack space. The two details interviewers probe are multi-digit numbers such as 12[ab], and nested brackets, both of which the two-stack approach handles naturally.
Q. What is the difference between compile-time and runtime polymorphism?
A. Compile-time polymorphism, also called static binding, is method overloading and operator overloading: several methods share a name but differ in their parameter lists, and the compiler picks one from the declared argument types. Runtime polymorphism, or dynamic binding, is method overriding: a subclass redefines a parent method with the same signature, and the decision of which implementation runs is deferred to run time based on the object’s actual type, dispatched through a vtable in C++ or by the JVM in Java. The practical consequence Intuit interviewers look for is extensibility - runtime polymorphism lets you add a new subclass without touching the calling code, whereas overloading is only a convenience for the caller. Note that in Java, static, private, and final methods are bound at compile time and therefore cannot be overridden.
Q. Explain normalization, and when would you deliberately denormalize?
A. Normalization decomposes tables so each fact is stored exactly once: 1NF requires atomic columns, 2NF removes partial dependencies on part of a composite key, and 3NF removes transitive dependencies between non-key columns. The payoff is that an update touches one row, so update, insert, and delete anomalies disappear. You denormalize when read performance under a known access pattern matters more than write simplicity - for example, storing a precomputed comment_count on a post rather than running a COUNT join on every page load, or duplicating a product name into an order-line row so historical orders do not change when the catalogue does. The cost is that you now own the consistency: every write path must update both copies, usually via a transaction, a trigger, or an asynchronous job that you must then monitor for drift.
Assessment tips
Interview tips
HR tips
These links are research inputs used to map Intuit Glider OA and Craft Demo loops - not copied page mirrors. We reorganized reports into process tables, outcome notes, and prep takeaways.
Confirm SDE-1 vs SDE-2 Craft expectations against the recruiter screen.