UPTIQ SDE Interview Experience
1. Company and Role
Company: UPTIQ
Role: SDE
Batch/Year of Graduation: 2027
Branch: Artificial Intelligence and Data Science
2. Interview Rounds
Round 1: Online Assessment (2hrs)
The OA consisted of 2 DSA Questions (medium level)
And
84 MCQS covering:
1. Full Stack knowledge
2. SQL
3. OOPS
4. Computer Networks
5. Operating Systems
Round 2: L1 Technical
The L1 Technical Interview lasted around 65-70 minutes and was primarily focused on my resume, internship experience, technical projects, system design decisions, authentication, database choices, caching, deployment, and rollback strategies.
The interviewer did not focus much on theoretical definitions. Instead, most questions were based on why I had made certain technical decisions while building my projects and how I would handle different real-world scenarios.
A major part of the discussion revolved around my RoomMet project.
Project Architecture and User Journey
I was first asked to explain the overall architecture and flow of the project.
The interviewer asked me to draw the complete user journey/scenario diagram of the system, explaining how a user interacts with the application from beginning to end.
This included areas such as:
User registration/login
Authentication flow
User interaction with the frontend
Backend/API communication
Database interaction
Accessing protected routes
Different user roles
Major application workflows
The interviewer also asked questions related to:
ER diagrams
Database relationships
Overall database design
Architecture/flow diagrams
Why MongoDB?
The interviewer thoroughly questioned me about why MongoDB was used in RoomMet.
The discussion was based around a scenario where:
The application could experience relatively high traffic
Documents were comparatively small
Some entities still had relational characteristics
I was asked to justify why MongoDB was chosen instead of a relational database.
The discussion focused on:
Flexible schema
Handling changing application requirements
Scalability
Read/write performance
Document-oriented data
Situations where MongoDB is suitable
Trade-offs of using MongoDB when relationships exist between entities
JWT Authentication and Token Security
The interviewer then asked me to explain the complete JWT authentication flow implemented in the project.
I explained how:
The user logs in.
The backend verifies the credentials.
A JWT token is generated.
The token contains information related to the authenticated user.
Protected routes verify the token through middleware.
Authorization is performed based on the user's role.
The interviewer then introduced a security scenario:
What happens if a user's JWT token gets stolen?
Initially, I explained that Role-Based Access Control (RBAC) could be used so that users would only be able to access routes permitted for their assigned roles.
I also mentioned having different authorization privileges for administrators and normal users.
The interviewer then extended the scenario:
What if the stolen token belongs to an admin?
This led to a deeper discussion around authentication and authorization security.
I proposed multiple possible safeguards, including:
Additional authentication mechanisms similar to Microsoft Authenticator / MFA
RBAC-based authorization
Middleware guards before accessing sensitive routes
Restricting access to private routes
Additional verification before performing sensitive actions
The interviewer continued challenging these approaches by asking what would happen if even the higher-privilege authentication credentials were compromised.
This became more of a security-design discussion rather than a simple JWT question, where the interviewer wanted to understand how I thought about protecting privileged users and sensitive routes.
Redis and Caching
The discussion then moved towards Redis.
I was asked:
Whether Redis was being used as in-memory caching or server-side caching
Why caching was required
What problem Redis solved in the application
How caching affected application performance
I explained that Redis was introduced to reduce repeated API/database calls and improve response times.
Without caching, frequently requested data would require the backend to repeatedly fetch the same information from the database or process the same API request.
Using Redis allowed frequently accessed data to be stored temporarily in memory, which helped:
Reduce API response latency
Reduce database load
Improve page load time
Improve overall application performance
Why Next.js?
I was also questioned about why Next.js was selected for the project.
The discussion included the benefits it provided over a traditional React application, such as:
Routing
Server-side capabilities
Better application structure
Performance optimizations
SEO-related advantages
Easier production deployment and full-stack integration
Deployment and DevOps
The interviewer then moved towards deployment and DevOps.
I was asked how the application had been deployed.
I explained that we used a server provided through BigRock.
The deployment setup involved:
Hosting the application on the server
Using PM2 for process management
Purchasing and managing the domain through BigRock
Performing the necessary DNS mapping
Mapping the domain to the deployed application
The interviewer also asked about how we managed application processes and deployments on the server.
Versioning and Rollback Scenario
The interviewer then gave me a practical versioning/database scenario.
The scenario was approximately:
Suppose a developer deploys a new feature and introduces an additional column/field in the database. Later, the feature is found to be incorrect and needs to be rolled back. What would your approach be?
Since the application currently had a relatively small user base, I initially proposed a simpler approach where we could temporarily log users out or restrict access, restore the required application/database state, and then redeploy the corrected version.
I also explained that this approach was suitable for the current scale of the application, although it would not be the ideal approach for a large-scale production system.
The discussion was mainly intended to understand my knowledge of:
Version control
Deployment rollback
Database schema changes
Handling backward compatibility
Production recovery strategies
Internship Discussion
A significant portion of the interview was also focused on my internship experience.
The interviewer asked detailed questions about:
Projects I worked on
My individual contribution
Technical decisions I made
Why specific technologies were selected
Implementation choices
Problems encountered during development
How I approached solving those problems
Overall, the interview was highly project-oriented and scenario-based. Instead of asking direct theoretical questions, the interviewer repeatedly took decisions from my projects and asked “Why did you do this?”, followed by additional scenarios to test how deeply I understood the technology and its trade-offs.
Round 3: L2 – Techno-HR Round
The L2 round was conducted by the CTO and was comparatively shorter than the previous technical round. The interview followed more of a techno-HR / rapid-fire format, combining technical discussions with behavioural and personal questions.
A large part of the round focused on my projects, the technologies I had used, and the reasoning behind building them.
Project Introduction and Tech Stack Discussion
The interviewer first asked me to introduce all of my projects along with the complete technology stack used in each of them.
I explained:
Three college-level projects
One production-level project
For each project, I briefly covered:
The problem statement
Why the project was built
The technology stack
My individual contribution
The overall implementation approach
The discussion then became deeper for selected projects.
Pragmatix – NLP Project
One of the projects discussed in detail was Pragmatix, which was primarily an NLP-based project.
The interviewer first asked:
What was the need to develop this project?
I explained that one of the motivations was the dialect mismatch and variation in the way different users express the same intent, and the project was designed to interpret such variations more effectively.
The interviewer then asked which NLP concepts were used in the project.
I explained concepts such as:
Tokenization
TF-IDF scoring
Pattern-based matching
Text preprocessing
Intent/pattern identification
I also explained that we had created a pipeline containing approximately 5,000 patterns.
The system supported multiple matching approaches, including:
Rule-based matching
A model-based matching approach
Since I was considering taking the project towards a more production-oriented implementation, I did not disclose all implementation details, but I explained the overall flow of how user input was processed and matched against the appropriate patterns.
RoomMet – ER Diagram and Database Discussion
The discussion then moved back to my production-level project, RoomMet.
The interviewer asked me to draw an ER diagram focused on the different types of users and their respective attributes.
The discussion involved identifying:
Different user types
User attributes
Relationships between users and other entities
How user-related information was represented in the database
The interviewer then asked several database-related questions, including:
How MongoDB works
How MongoDB stores data
How it differs from SQL databases
Advantages and disadvantages of MongoDB
Situations where MongoDB would be preferred over a relational database
I explained that MongoDB stores data in document-based structures, similar to objects, rather than traditional rows and columns.
I also compared MongoDB with relational databases and discussed areas such as:
Flexible schema
Document-oriented storage
Relationships
Scalability
Querying
Data consistency
Drawbacks of using MongoDB for highly relational data
RoomMet Functionality and Chat Guard
The interviewer also asked me to explain the overall functioning of RoomMet.
During this discussion, we spoke in detail about a feature we had implemented called Chat Guard.
The purpose of Chat Guard was to prevent users from bypassing the platform by sharing personal contact information or social media handles directly through the chat.
The system was designed to detect content such as:
Phone numbers
Social media handles
Other contact-sharing attempts
Users would receive warnings when such content was detected. After repeated violations, the system could take stricter actions, including deleting the chat and applying restrictions or penalties according to the platform's rules.
I explained that the initial implementation started with manual pattern matching.
Later, we moved towards a more intelligent moderation approach using Jev-Chat for identifying restricted content more effectively.
This led to a short discussion about how similar systems are implemented in other industries, particularly how fintech platforms and AI-based chatbots perform message filtering, moderation, and policy enforcement.
Behavioural and Personal Questions
The latter part of the interview consisted of behavioural and personal questions.
These included topics such as:
How I manage stress
How I approach difficult situations
How I solve problems
How I react when something does not go according to plan
My experiences working on different projects
General questions about my working style and mindset
The round was much faster-paced than the previous technical interview, with the interviewer frequently switching between technical and behavioural topics.
Overall, the L2 round was focused on evaluating both technical understanding and communication ability. The CTO was particularly interested in whether I genuinely understood the projects I had built, why certain technologies were used, and whether I could clearly explain the reasoning behind my implementation decisions.
Result : Selected for SDE (Internship + PPO)
Overall experience and suggestions:
The interview process was largely focused on practical understanding. For the interview rounds, I would strongly recommend knowing everything mentioned on your resume in depth. DO NOT BLUFF IF YOU HAVEN’T ACTUALLY IMPLEMENTED THAT BECAUSE YOUR WHOLE RESUME GETS SCANNED BY THE INTERVIEWER AND HE CAN STOP AT ANY POINT
Be prepared to explain not just what you built, but why you built it and how you implemented the same
Also keep practicing on platforms like Leetcode, Codeforces for better results (ps: I was just solving questions on my own at my own pace without caring about rating and other stuff. Just maintain a balance between DSA and Dev and you’re unstoppable :) )
