Anjana - AI & Tech

🚀 Follow this roadmap to become a Machine Learning Engineer in 2026👇 https://www.instagram.com/reel/Des_6UOSplh/?exln=MWJvaXoxY2wxY3VpdA==

Asked in a CRED AI Engineer interview 👇 A payment platform processes millions of transactions every minute. How would you design an AI system that detects potentially fraudulent transactions in real time while minimizing false positives? Do the arithmetic on the false positives. At a million transactions a minute, a 0.1% false-positive rate blocks a thousand genuine payments a minute. Accuracy is not the objective here — cost is. 1. Fix the latency budget first - The decision sits inline with authorisation: 50-100ms - Features precomputed in a feature store and read by key, never joined at request time - Streaming aggregates (Flink, Kafka) keep the counters fresh 2. Two models, not one - A gradient-boosted tree on tabular features scores every transaction in single-digit ms - The expensive graph or sequence model runs only on the risky slice 3. Features carry the signal - Velocity: count and amount over 1 minute, 1 hour and 24 hours per card and device - Deviation from this user's own baseline, not the population average - Device fingerprint, IP, and geo-velocity — impossible travel is a gift 4. Score the network, not the transaction - Shared devices, accounts and payout targets expose rings a per-transaction model never sees - Graph features (component size, distance to a known bad node) move precision the most 5. Minimise false positives by acting in bands - One threshold is a blunt instrument: approve, step up to OTP or 3DS, then block - A step-up turns a would-be false positive into a little friction - Tune for precision at a fixed recall, and price both errors in rupees 6. Design for labels that arrive late - Chargebacks land 30-90 days later, so retraining always trails the fraudster - Keep a small unblocked holdout to measure what you missed - Shadow-score challengers on live traffic before promoting them

Asked in a Swiggy AI/ML Engineer interview 👇 You have a vector database containing 10 million documents. How would you retrieve the 5 most relevant documents without comparing the query against all 10 million documents? The interviewer is checking one thing: do you know exact search does not scale, and can you name what replaces it? The answer is approximate nearest neighbour search — you trade a sliver of recall for a thousandfold speedup. 1. Say the cost of brute force out loud - 10M vectors × 768 dimensions is a full scan on every single query - Exactly correct, and unusable at any real QPS 2. HNSW — the default - A layered graph: sparse top layers for long jumps, a dense bottom layer for precision - Enter at the top, greedily walk towards the query, drop a layer, repeat - Visits a few thousand nodes instead of 10 million - efSearch is your recall-versus-latency dial at query time 3. IVF — partition and prune - Cluster the vectors into centroids; search only the nprobe nearest cells - Faster to build and lighter in memory than HNSW, at slightly lower recall 4. Compress so it fits in RAM - Product quantisation shrinks a vector 10-30x; disk lookups are what actually kill latency - IVF-PQ for huge corpora, then rescore the shortlist with full-precision vectors 5. Filter inside the search, not after it - Tenant, date and language as pre-filters on the index - Post-filtering silently hands back fewer than 5 results 6. Over-fetch, then rerank - Pull top-50 with ANN, rerank with a cross-encoder, return 5 - Recovers most of the accuracy the approximation gave away The principle: nobody searches 10 million vectors. You search a structure built over them, and you choose how much recall to trade for latency. 💬 HNSW or IVF-PQ for your workload — and what made you pick it?

Asked in a Spotify AI/ML Engineer interview 👇 A user tells Spotify, “Play something relaxing for my evening commute.” How would you design an AI system that understands the request and creates a personalized playlist based on mood, history, and context? There are three requests hidden in that sentence: a mood, a duration and a setting. Translate it into constraints, then let retrieval and sequencing do the work. 1. Parse the request into constraints, not keywords - "Relaxing" maps to audio features: low energy, moderate tempo, acoustic, low speechiness - "Commute" implies a length — build to roughly 35 minutes, not an endless queue - "Evening" narrows the listening history you should trust 2. Let the LLM interpret, never invent - The model turns language into filters and weights; the catalogue supplies the tracks - A hallucinated song title is unplayable, and users notice immediately 3. Ground everything in this listener - Blend familiar tracks from their own library with new ones, and tune that ratio per user - Their "relaxing" is learned from what they actually played on past evenings, not from a genre tag 4. Sequence the playlist, do not just select it - Order is the product: ease in, hold the mood, land softly before the commute ends - No abrupt tempo or key jumps, and a cap on tracks per artist 5. Fill the gaps with sensible defaults - Nothing stated about genre? Use what they played at this hour on this weekday - Cold start falls back to editorial seeds for the mood, then adapts within minutes 6. Learn from the skips - A skip inside 30 seconds is a strong negative; completions and saves are positives - Re-rank the unplayed tail mid-session rather than waiting for the next request

15 Machine Learning Projects (Step by Step Guide) along with Source Code👇 https://www.instagram.com/reel/DegGsclyJJU/?xtok=MWFvazJseHk1ZXRzMA==

Asked in a Meta AI Engineer interview 👇 How would you design a GenAI system capable of generating 50 million personalized ad copies every day? How would you ensure each copy feels handcrafted and does not appear AI-generated? Do the arithmetic first. 50 million a day is about 580 copies every second, forever. Nobody calls a frontier model 580 times a second and survives the bill. 1. Generate templates, not copies - The model produces a few thousand reusable skeletons per campaign, offline - Serving fills the slots from user features: city, last purchase, price band - Generation becomes a batch job; the request path is a lookup 2. Segment instead of personalising per user - Cluster users into a few thousand behavioural cohorts - One creative set per cohort × product × placement - 50 million impressions, far fewer distinct creatives 3. Kill the AI tells - Ban the tics: "unlock", "elevate", "in today's fast-paced world" - Vary sentence length deliberately — uniform rhythm is the giveaway - Sample with temperature and a per-copy style seed, never greedy decoding 4. Get voice from retrieval, not adjectives - Retrieve the brand's best human-written ads as few-shot examples - "Write in a friendly tone" produces the same beige copy for every brand 5. Filter before anything ships - Near-duplicate detection over the whole day's output with embeddings and MinHash - Claim and compliance checks: prices, guarantees, regulated categories - A classifier trained on your own human copy scores "does this sound like us" 6. Let the market judge - Multi-armed bandits on live CTR; kill losers in hours, not weeks - Winners re-enter the few-shot pool, so the system compounds The principle: at 50 million a day you are not generating copy, you are generating a distribution. Handcrafted means varied, on-voice and evaluated — not expensive. 💬 Templates plus slots, or per-user generation — which way would you go?