Skip to main content
Career10 min read

तकनीकी साक्षात्कार: मेज के दोनों ओर से

मैं सिस्टम डिज़ाइन के सवालों पर पसीना बहाने वाला उम्मीदवार और उनका मूल्यांकन करने वाला साक्षात्कारकर्ता दोनों रहा हूँ। साक्षात्कारकर्ता जो खोजते हैं और उम्मीदवार जो तैयारी करते हैं, उनके बीच का अंतर बहुत बड़ा है।

Part ofSolo Studio Operating System->
By Jason TeixeiraSeptember 15, 2025
InterviewingCareerSystem DesignTechnical Interview
Share:
On this page

मैं मेज के दोनों ओर बैठा हूँ। मैंने व्हाइटबोर्ड पर सिस्टम डिज़ाइन बनाए हैं जबकि एक साक्षात्कारकर्ता चुपचाप सिर हिलाता रहा। मैं वह भी रहा हूँ जो सिर हिलाता है, एक उम्मीदवार को व्हाइटबोर्ड पर नोटिफिकेशन सिस्टम डिज़ाइन करते देखता है।

उम्मीदवार जो तैयारी करते हैं और साक्षात्कारकर्ता वास्तव में जो मूल्यांकन करते हैं, उनके बीच का अंतर चौंकाने वाला है।

उम्मीदवार किसकी तैयारी करते हैं

  • LeetCode के कठिन प्रश्न
  • अस्पष्ट एल्गोरिदम ट्रिविया
  • "मुझे एक ऐसे समय के बारे में बताएं जब..."
  • रटे हुए सिस्टम डिज़ाइन उत्तर

साक्षात्कारकर्ता वास्तव में क्या मूल्यांकन करते हैं

  • आप अस्पष्टता को कैसे संभालते हैं। जब मुझे कोई सिस्टम डिज़ाइन समस्या दी जाती है, तो सबसे पहले मैं स्पष्ट करने वाले प्रश्न पूछता हूँ। "कितने उपयोगकर्ता? लेटेंसी की क्या आवश्यकता है? बजट क्या है?" जो उम्मीदवार प्रश्न पूछने से पहले बक्से बनाना शुरू कर देते हैं, वे एक लाल झंडा हैं। वे आवश्यकताओं को समझे बिना निर्माण करते हैं — और वे नौकरी पर भी ऐसा ही करेंगे।

  • ट्रेड-ऑफ़ जागरूकता। कोई सही आर्किटेक्चर नहीं है। हर विकल्प की एक लागत होती है। जब कोई उम्मीदवार कहता है "हमें मैसेज क्यू के लिए Kafka का उपयोग करना चाहिए," तो मैं पूछता हूँ "SQS क्यों नहीं?" यदि वे ट्रेड-ऑफ़ स्पष्ट कर सकते हैं (Kafka: अधिक थ्रूपुट, अधिक ऑपरेशनल ओवरहेड, बेहतर रीप्ले; SQS: सरल, प्रबंधित, अधिकांश मामलों के लिए पर्याप्त), तो वे इंजीनियरिंग समझते हैं। यदि वे कहते हैं "Kafka उद्योग मानक है," तो वे कार्गो कल्टिंग कर रहे हैं।

  • फेलियर मोड सोच। "जब यह सेवा डाउन हो जाएगी तो क्या होगा?" यदि उत्तर है "यह डाउन नहीं होगी," तो मुझे पता चल जाता है कि उन्होंने कभी प्रोडक्शन में सिस्टम संचालित नहीं किया है। सब कुछ डाउन होता है। सवाल यह है कि क्या आपने इसके लिए डिज़ाइन किया है।

  • संचार स्पष्टता। क्या आप अपने डिज़ाइन को कमरे में बैठे एक गैर-तकनीकी व्यक्ति को समझा सकते हैं? वरिष्ठ भूमिकाओं में प्रोडक्ट मैनेजरों, डिज़ाइनरों और कार्यकारियों के साथ संवाद करना शामिल है। यदि आप अपने सिस्टम को केवल अन्य इंजीनियरों को समझा सकते हैं, तो आप अपनी सीमा पर पहुँच गए हैं।

मैं जो प्रश्न पूछता हूँ (और वास्तव में क्या परीक्षण कर रहा हूँ)

"मुझे एक हालिया प्रोजेक्ट के बारे में बताएं जिस पर आपको गर्व है।"

मैं परीक्षण कर रहा हूँ: क्या आप एक सुसंगत कहानी बता सकते हैं? क्या आप बाधाओं का उल्लेख करते हैं, न कि केवल तकनीक? क्या आप अपनी टीम को श्रेय देते हैं या सारा श्रेय लेते हैं? क्या आप उल्लेख करते हैं कि आप क्या अलग करते?

"आपको प्रोडक्शन में 500 एरर मिल रहे हैं। मुझे अपनी डीबगिंग प्रक्रिया के बारे में बताएं।"

मैं परीक्षण कर रहा हूँ: क्या आपके पास एक व्यवस्थित दृष्टिकोण है, या क्या आप अनुमान लगाते हैं? क्या आप पहले लॉग और मेट्रिक्स जांचते हैं, या क्या आप कोड बदलना शुरू करते हैं? क्या आप ब्लास्ट रेडियस के बारे में सोचते हैं?

"[X] के लिए एक सिस्टम डिज़ाइन करें। आपके पास 45 मिनट हैं।"

मैं परीक्षण कर रहा हूँ: क्या आप पहले प्रश्न पूछते हैं? क्या आप आवश्यकताओं से शुरू करते हैं या तकनीक से? क्या आप मॉनिटरिंग, एरर हैंडलिंग और स्केलिंग का उल्लेख करते हैं — या केवल हैप्पी पाथ?

जब मैंने साक्षात्कार लेना शुरू किया तो क्या बदला

एक उम्मीदवार के रूप में, मैंने सोचा कि साक्षात्कारकर्ता "सही उत्तर" चाहता है। एक साक्षात्कारकर्ता के रूप में, मैंने सीखा कि कोई सही उत्तर नहीं है। मैं आपकी सोच प्रक्रिया का मूल्यांकन कर रहा हूँ।

जो उम्मीदवार एक सरल सिस्टम डिज़ाइन करता है, उसकी सीमाओं को स्वीकार करता है, और बताता है कि वे कब जटिलता जोड़ेंगे, वह उस उम्मीदवार से अधिक मजबूत है जो एक जटिल सिस्टम डिज़ाइन करता है जिसे वे समझा नहीं सकते।

मेरी सलाह (दोनों ओर से)

उम्मीदवारों के लिए:

  1. कुछ भी डिज़ाइन करने से पहले 3-5 स्पष्ट करने वाले प्रश्न पूछें
  2. सरल शुरू करें और पूछे जाने पर जटिलता जोड़ें
  3. बिना पूछे फेलियर मोड का उल्लेख करें ("यदि यह सेवा डाउन हो जाती है, तो यहाँ बताया गया है कि क्या होता है")
  4. हर बड़े निर्णय के लिए ट्रेड-ऑफ़ समझाएँ
  5. जो आप नहीं जानते उसके बारे में ईमानदार रहें — "मैंने बड़े पैमाने पर Kafka का उपयोग नहीं किया है, लेकिन मैं थ्रूपुट लाभों को समझता हूँ। इस उपयोग के मामले के लिए, मैं SQS से शुरू करूँगा और यदि हमें रीप्ले की आवश्यकता हो तो माइग्रेट करूँगा"

साक्षात्कारकर्ताओं के लिए:

  1. विशिष्ट तकनीकी ज्ञान का परीक्षण न करें — इंजीनियरिंग निर्णय का परीक्षण करें
  2. पूछें "आप क्या अलग करेंगे?" — सबसे अच्छे इंजीनियरों की अपने काम के बारे में मजबूत राय होती है
  3. उम्मीदवारों को गलतियों से उबरने का अवसर दें — वे गलत होने को कैसे संभालते हैं, यह आपको सही होने से अधिक बताता है

सबसे अच्छे साक्षात्कार कार्य सत्रों की तरह लगते हैं। सबसे बुरे पूछताछ की तरह लगते हैं। पहले वाले के लिए डिज़ाइन करें।

Reader route

article -> proof -> offer

ReadClusterProofScope

cluster

Solo Studio Operating System

intent

Career

route

next step

What to do with this

Turn the note into a build path.

If this topic maps to a real business problem, keep reading the cluster, study the academy path, or route the work into a scoped engagement.

Jason Teixeira
Written by
Jason Teixeira
Founder, Sage Ideas Studio · Principal Engineer
livebuild 5d6c8652026-08-05 06:00Z
// solo studio// no analytics resold// every commit human-reviewed