Texas Instruments

Round 1 — Project Deep Dive + RAG + Backend + DSA Introduction The interview started with both interviewers introducing themselves and briefly explaining their roles. After that, they asked me to introduce myself. The introduction was followed almost immediately by a discussion of my resume, particularly Project 1. The interviewers were clearly focused on the technologies and features I had explicitly mentioned in my resume. Rather than asking only theoretical questions, they actually looked at the working project and started questioning the implementation in detail. Detailed Project Discussion The project discussion started from the most basic question: Why did you choose this particular technology stack? This was followed by questions around almost every major technology mentioned in the project. The important lesson was that anything mentioned in the resume can become an interview question. For every technology, I had to be prepared to explain: What it is Why I selected it What alternative technologies could have been used Why I preferred my choice How it was integrated What role it plays in the architecture What happens if it fails Working Project Demonstration The interviewers actually looked at the project working rather than relying only on the resume description. They explored the features and asked questions based on what they observed. This made the discussion much more implementation-oriented. For example, instead of simply asking: "What is RAG?" they asked questions related to how RAG was actually implemented in my project. This is an important distinction because project interviews often move from: Resume → Feature → Implementation → Technology → Design Decision RAG-Based Loan Application Project A major portion of the discussion was around my RAG-based loan application project. The interviewers were particularly interested in how the system handled different types of documents. Handling Different Types of Documents for Chunking One of the questions was essentially: How are you managing different types of documents for chunking? This tests whether the candidate understands that simply splitting every document into fixed-size chunks is not always ideal. A typical pipeline can be: Different Documents | ------------------------- | | | PDF DOCX Scanned PDF | | | ------ Document Parsing - | Text Extraction | Document Cleaning | Structure Detection | Chunking Strategy | Embeddings | Vector Database Different documents may require different preprocessing. For example: Text-based PDFs → direct text extraction DOCX → paragraph/heading extraction Scanned documents → OCR Tables → table-aware extraction Structured documents → preserve headings and sections The important principle is: Chunking should preserve semantic and structural meaning rather than blindly splitting text after a fixed number of characters. Semantic Search The interviewers asked: What is semantic search? Semantic search retrieves information based on meaning rather than exact keyword matching. For example, suppose the user asks: "Can I get a home loan with a low monthly salary?" A document might contain: "Eligibility criteria based on minimum monthly income." Even though the exact words don't match, semantic search can identify that the two statements are conceptually related. The flow is: User Query ↓ Query Embedding ↓ Vector Similarity Search ↓ Relevant Chunks ↓ Top-K Results This is different from traditional keyword search, where the system primarily looks for matching words. What Do Vector Embeddings Represent? Another important question was: What do vector embeddings actually represent? Embeddings are numerical vector representations of data that capture semantic and contextual relationships. For example: "home loan" ↓ [0.12, -0.43, 0.78, ...] Another semantically related sentence might have a vector relatively close to it. The important point is that the individual dimensions generally do not have simple human-readable meanings. Instead, the position and relationships between vectors in the embedding space encode useful semantic information. Therefore, similar concepts tend to have vectors that are closer according to the chosen similarity metric. Detailed RAG Pipeline The interviewer then went into a detailed discussion of the complete RAG pipeline. A good explanation is: DOCUMENT INGESTION | ↓ Document Parsing | ↓ Text Extraction | ↓ Preprocessing | ↓ Chunking | ↓ Embeddings | ↓ Vector Database | -------------- | | | | USER QUERY | | | ↓ | Query Embedding | | | ↓ | Similarity Search ←- | ↓ Top-K Chunks | ↓ Context Construction | ↓ LLM | ↓ Final Response Step 1 — Document ingestion The system accepts relevant loan documents. Step 2 — Parsing Documents are converted into usable text/structured information. Step 3 — Chunking Large documents are divided into smaller meaningful pieces. Step 4 — Embedding generation Each chunk is converted into a vector representation. Step 5 — Vector storage The embeddings and corresponding chunks are stored in a vector database. Step 6 — Query processing The user's question is converted into an embedding using the same or compatible embedding model. Step 7 — Retrieval The system performs semantic similarity search to retrieve the most relevant chunks. Step 8 — Context construction The retrieved chunks are inserted into the prompt as contextual information. Step 9 — Generation The LLM generates an answer based on the retrieved context. The core idea is: RAG separates knowledge retrieval from language generation. Authorization After the RAG discussion, the interview moved toward some general backend concepts. Authorization was discussed. A good distinction to remember: Authentication Determines: Who is the user? Authorization Determines: What is the user allowed to do? For example: User → Authentication → Successfully logged in ↓ Authorization ↓ Can this user access /admin? Authorization can be implemented through mechanisms such as: Role-Based Access Control Permission-based access Resource ownership checks Access policies Redis The interviewers also asked some general questions about Redis. Important points to cover: Redis is an in-memory key-value data store commonly used for: Caching Sessions Rate limiting Temporary data Counters Frequently accessed information One important interview follow-up is: What happens if Redis goes down? If Redis is being used only as a cache, the application can generally fall back to the database: Request ↓ Redis ↓ Cache unavailable ↓ Database ↓ Response The system becomes slower but should ideally continue functioning. This depends on the role Redis plays in the architecture. Critical persistent information should not exist only in a volatile cache without an appropriate durability/failover strategy. DSA — Minimize Settlement Transactions Only one DSA problem was asked in this round. The problem was essentially: Given transactions where each record contains: who sends money, who receives money, and the amount, design an algorithm to minimize the number of settlement transactions. For example: A → B : 10 B → C : 5 C → A : 5 Instead of blindly executing every original transaction, we can first calculate the net balance of every person. Net Balance Concept For each transaction: sender → balance[sender] -= amount receiver → balance[receiver] += amount After processing all transactions: Positive balance → Person should receive money Negative balance → Person owes money For example: A : +10 B : -5 C : -5 Now the goal is to settle these net balances with the minimum number of transactions. Greedy Two-Pointer Approach I proposed a greedy approach using two pointers. The general idea is: Calculate everyone's net balance. Separate positive and negative balances. Use two pointers: One pointing to a person who owes money. One pointing to a person who should receive money. Transfer the minimum possible amount. Update both balances. Move the pointer whose balance becomes zero. Conceptually: Debtors Creditors A : -10 C : +7 B : -5 D : +8 ↑ pointer Transfer: min(abs(debt), credit) Then update both balances. The process continues until all balances become zero. Complexity If there are N people: Calculating balances: O(T) Settlement after sorting/separating balances: typically O(N log N) if sorting is required Space: O(N) A deeper discussion can arise here because the general minimum cash-flow problem has nuances around guaranteeing the absolute minimum number of transactions. A greedy two-pointer settlement is an efficient and commonly used approach, but if an interviewer explicitly asks for the mathematically minimum number of transactions in the general case, it is worth discussing the distinction and possible subset-based approaches. Interview Conclusion After the DSA problem, the technical discussion ended. The interviewers then asked: Do you have any questions for us? This marked the end of Round 1. Overall Nature of Round 1 This round was predominantly a project deep-dive interview rather than a pure DSA round. The approximate flow was: Introduction ↓ Resume / Project 1 ↓ Working Project ↓ Technology Stack ↓ Feature Discussion ↓ RAG Architecture ↓ Document Chunking ↓ Semantic Search ↓ Vector Embeddings ↓ Authorization ↓ Redis ↓ DSA — Settlement Problem ↓ Candidate Questions