स्टार्टअप जॉब डिस्क्रिप्शन जो वास्तव में हायरिंग में सफलता दिलाएं

एक स्टार्टअप जॉब डिस्क्रिप्शन को प्रभाव बेचना चाहिए, पहले दिन की अपेक्षाओं को स्पष्ट करना चाहिए, और सीधे एक कौशल मूल्यांकन में परिवर्तित होना चाहिए। यही इस दस्तावेज़ का पूरा काम है। यह कोई कानूनी अस्वीकरण या इच्छा-सूची नहीं है। यह एक साथ चलने वाला फ़िल्टर और पिच दोनों है।
कुछ भी प्रकाशित करने से पहले, इस चेकलिस्ट को अपने मसौदे पर लागू करें:
- शीर्षक एक मानक, खोज योग्य जॉब फ़ंक्शन का उपयोग करता है (न कि "Growth Ninja" जैसा)।
- पहला वाक्य एक ठोस परिणाम बताता है जिसका स्वामित्व उस व्यक्ति के पास होगा, न कि कोई मिशन स्टेटमेंट।
- आवश्यकताओं की सूची में पहले दिन के 3 से 5 अनिवार्य तत्व हैं, न कि 15।
- वेतन सीमा मौजूद है और यथार्थवादी है, न कि कोई प्लेसहोल्डर या $40K का फैलाव।
- आवेदन के चरण उम्मीदवारों को ठीक-ठीक बताते हैं कि आगे क्या होगा और कब तक।
इनमें से किसी एक को भी चूक जाएं और आपके सर्वश्रेष्ठ उम्मीदवार या तो पोस्ट छोड़ देंगे, या इससे भी बुरा, आवेदन करेंगे और फिर तीन इंटरव्यू में छोड़ देंगे जब वास्तविकता पिच से मेल नहीं खाती।
मुख्य बातें
सबसे प्रभावी स्टार्टअप जॉब डिस्क्रिप्शन एक ठोस 90 से 180 दिन का परिणाम बेचती है, आवश्यकताओं को तीन से पांच परीक्षण योग्य अनिवार्य तत्वों तक सीमित रखती है, और सीधे एक कौशल मूल्यांकन में परिवर्तित होती है।
| बिंदु | विवरण |
|---|---|
| पहले शीर्षक ठीक करें | एक मानक, खोज योग्य जॉब फ़ंक्शन का उपयोग करें ताकि उम्मीदवार और Google for Jobs पोस्ट ढूंढ सकें। |
| एक परिणाम के साथ शुरू करें | मिशन स्टेटमेंट से शुरू करने के बजाय बताएं कि नियुक्त व्यक्ति 90 से 180 दिनों में क्या स्वामित्व लेगा। |
| आवश्यकताओं को 3 से 5 तक सीमित करें | पूर्वाग्रह और शोर कम करने के लिए टूल सूचियों और प्राथमिकताओं को एक अलग nice-to-haves अनुभाग में रखें। |
| वास्तविक वेतन सीमा प्रकाशित करें | एक संकीर्ण, ईमानदार सीमा विश्वास बनाती है और आवेदन की मात्रा और गुणवत्ता दोनों बढ़ाती है। |
| JD को एक परीक्षण में बदलें | Talent Approved का Magic Create आपकी पूरी जॉब डिस्क्रिप्शन से सीधे एक भूमिका-विशिष्ट कौशल मूल्यांकन बनाता है। |
विषय-सूची
- स्टार्टअप जॉब डिस्क्रिप्शन लेखन सुझाव जो शीर्षक से शुरू होते हैं
- आप एक आकर्षक शुरुआती पैराग्राफ कैसे लिखते हैं?
- उम्मीदवार प्रोफ़ाइल और दैनिक वास्तविकता कैसी होनी चाहिए?
- स्टार्टअप जॉब पोस्टिंग में कितनी आवश्यकताएं होनी चाहिए?
- आप जिम्मेदारियों को स्कैन करने योग्य कैसे बनाते हैं?
- स्टार्टअप को वेतन और इक्विटी के बारे में कितना साझा करना चाहिए?
- आवेदन निर्देशों में क्या होना चाहिए?
- कौन सी भाषा संबंधी गलतियाँ चुपचाप अच्छे उम्मीदवारों को दूर भगाती हैं?
- दो पूर्ण स्टार्टअप जॉब डिस्क्रिप्शन उदाहरण जिन्हें आप अपना सकते हैं
- आप जॉब डिस्क्रिप्शन को कौशल मूल्यांकन में कैसे बदलते हैं?
- स्टार्टअप संस्कृति पोस्टिंग में कैसे दिखनी चाहिए?
- आप लचीलापन और विकास की संभावना को कैसे उजागर करते हैं?
- क्या स्टोरीटेलिंग वास्तव में भर्ती में मदद कर सकती है?
- आप पोस्टिंग में रिमोट और हाइब्रिड विकल्पों को कैसे संभालते हैं?
- स्टार्टअप जॉब डिस्क्रिप्शन को कितनी बार अपडेट करना चाहिए?
- Talent Approved आपके JD को हायरिंग शॉर्टकट में कैसे बदलता है
- स्रोत
- FAQ
स्टार्टअप जॉब डिस्क्रिप्शन लेखन सुझाव जो शीर्षक से शुरू होते हैं
शीर्षक गलत करें और पोस्ट की बाकी कोई भी चीज़ मायने नहीं रखती, क्योंकि इसे कोई देखता ही नहीं। जॉब बोर्ड और Google for Jobs खोज प्रश्नों का मिलान करने के लिए संरचित डेटा पर निर्भर करते हैं, और "Growth Wizard" या "Chief Vibes Officer" जैसे रचनात्मक शीर्षक उम्मीदवारों द्वारा सर्च बार में टाइप किए जाने वाले शब्दों से बिल्कुल मेल नहीं खाते। खोज योग्यता पर विशेषज्ञ मार्गदर्शन लगातार मानक जॉब शीर्षकों के साथ मूल कौशल कीवर्ड को उस पैटर्न के रूप में इंगित करता है जो बोर्ड सर्च और इंडेक्सिंग में सबसे अच्छा प्रदर्शन करता है।
"backend engineer" खोजने वाला व्यक्ति आपकी "Full-Stack Wizard" लिस्टिंग कभी नहीं ढूंढेगा, चाहे पोस्ट का बाकी हिस्सा कितना भी अच्छा क्यों न हो। समाधान लगभग यांत्रिक रूप से सरल है:
- मान्यता प्राप्त वरिष्ठता मार्कर (Junior, Senior, Lead) का उपयोग केवल तभी करें जब यह सटीक हो, न कि आकांक्षात्मक।
- मुख्य फ़ंक्शन (Engineer, Marketer, Operations Manager) से शुरू करें, न कि विभाग के नारे से।
- संस्कृति और व्यक्तित्व को शुरुआती पैराग्राफ के लिए बचाएं, शीर्षक फ़ील्ड के लिए नहीं।
- आंतरिक शॉर्टहैंड को पूरी तरह छोड़ें। यदि आपकी टीम आंतरिक रूप से भूमिका को "Growth Hacker" कहती है, तो सार्वजनिक शीर्षक फिर भी "Growth Marketer" या "Performance Marketing Manager" पढ़ना चाहिए।
Pro Tip: शीर्षकों को 60 अक्षरों से कम रखें। अधिकांश जॉब बोर्ड मोबाइल पर इससे लंबी किसी भी चीज़ को काट देते हैं, और कटा हुआ शीर्षक उस समय लापरवाह लगता है जब उम्मीदवार ने आपकी पिच का एक भी शब्द नहीं पढ़ा होता।
आप एक आकर्षक शुरुआती पैराग्राफ कैसे लिखते हैं?
शुरुआती पैराग्राफ या तो पहले दस सेकंड में स्क्रॉल अर्जित करता है या उम्मीदवार को खो देता है। तीन सवालों का क्रमबद्ध जवाब दें: कंपनी वास्तव में क्या करती है, यह व्यक्ति किसका स्वामित्व लेगा, और यह स्वामित्व अभी क्यों मायने रखता है। इनमें से किसी एक को भी छोड़ें और पैराग्राफ भराव की तरह पढ़ता है।
अस्पष्ट विकास दावे ("हम उद्योग को बाधित कर रहे हैं") और सामान्य क्लिशे ("fast-paced environment," "wear many hats") संस्थापकों के इरादे के विपरीत काम करते हैं। वे संकेत देते हैं कि लेखक ने विशिष्ट होने के लिए पर्याप्त कठिन नहीं सोचा, और विशिष्टता ही वह चीज़ है जो पहली जगह एक स्टार्टअप भूमिका को आकर्षक बनाती है। पूरे पैराग्राफ को लगभग 60 शब्दों से कम रखें। स्टार्टअप-केंद्रित हायरिंग सलाह इस ढांचे का सीधे समर्थन करती है, और संस्थापकों को सुझाव देती है कि वे कर्तव्यों की सूची से शुरू करने के बजाय भूमिका क्यों मायने रखती है इससे शुरू करें।
यहाँ बताया गया है कि यह व्यवहार में कैसा दिखता है, एक seed-stage लॉजिस्टिक्स स्टार्टअप में backend engineering भूमिका के लिए:
हम वह रूटिंग सॉफ़्टवेयर बनाते हैं जो 200 क्षेत्रीय डिलीवरी फ्लीट को समय पर रखता है। जब हम 200 फ्लीट से 2,000 तक जाएंगे, तो आप हमारी मुख्य API परत के स्वामी होंगे, जिसका अर्थ है कि इस तिमाही में आप जो आर्किटेक्चर निर्णय लेते हैं वे तीन साल बाद भी व्यवसाय को चला रहे होंगे।
ध्यान दें क्या गायब है: कोई "rocket ship" नहीं, कोई "join our journey" नहीं, कोई विशेषण नहीं जो वह काम कर रहा हो जो एक तथ्य को करना चाहिए।
उम्मीदवार प्रोफ़ाइल और दैनिक वास्तविकता कैसी होनी चाहिए?
अपनी Ideal Candidate Profile को चार से छह persona बुलेट में अनुवाद करें जो मानसिकता और संदर्भ का वर्णन करते हैं, न केवल एक रेज़्यूमे चेकलिस्ट। एक उम्मीदवार प्रोफ़ाइल आवश्यकताओं की सूची से एक अलग सवाल का जवाब देती है। आवश्यकताएं पूछती हैं "क्या वे काम कर सकते हैं।" एक प्रोफ़ाइल पूछती है "क्या वे इस विशेष वातावरण में फलेंगे-फूलेंगे," जो एक early-stage स्टार्टअप के लिए आमतौर पर अस्पष्टता के साथ सहजता और बिना किसी playbook के परिणामों का स्वामित्व लेने के ट्रैक रिकॉर्ड का मतलब है।
एक early operations हायर के लिए एक मजबूत persona सेक्शन कुछ इस तरह पढ़ सकता है:
- ऐसी भूमिका में काम किया है जहाँ जॉब डिस्क्रिप्शन हर तिमाही बदलती थी, और इसे अराजक के बजाय सामान्य माना।
- किसी परिपक्व प्रक्रिया को विरासत में लेने के बजाय उसका पहला संस्करण बनाना पसंद करते हैं।
- अधूरी जानकारी के साथ एक महत्वपूर्ण निर्णय लिया है और उसके परिणाम के साथ जिया है।
- बिना स्टेटस अपडेट मांगे सक्रिय रूप से संवाद करते हैं।
- किसी मेट्रिक का सीधे स्वामित्व लिया है, न केवल उस टीम में योगदान दिया है जो उसकी मालिक थी।
उसे एक छोटे "day in the life" स्नैपशॉट के साथ जोड़ें। उसी operations भूमिका के लिए: एक सामान्य मंगलवार किसी vendor invoice विसंगति को सुलझाने से शुरू हो सकता है, फिर किसी shipping delay के बारे में fulfillment partner के साथ 30 मिनट की call पर जा सकता है, और उस returns policy का पहला मसौदा तैयार करने के साथ समाप्त हो सकता है जो अभी तक किसी ने नहीं लिखी है। वह पैराग्राफ "responsibilities" की किसी भी बुलेट सूची की तुलना में अधिक फ़िल्टरिंग काम करता है क्योंकि यह अस्पष्टता की बनावट को अमूर्त रूप से वर्णन करने के बजाय दिखाता है।
प्रत्येक persona बुलेट को पोस्ट में पहले बताए गए 90 से 180 दिन के परिणामों से जोड़ें। यदि परिणाम "शुरू से एक returns प्रक्रिया खड़ी करना" है, तो प्रोफ़ाइल को स्पष्ट रूप से ऐसे व्यक्ति को महत्व देना चाहिए जिसने पहले शून्य से एक प्रक्रिया बनाई हो, न केवल "operations experience" वाले किसी व्यक्ति को।
स्टार्टअप जॉब पोस्टिंग में कितनी आवश्यकताएं होनी चाहिए?
अपनी must-haves को तीन से पांच और nice-to-haves को तीन या चार तक सीमित रखें। बस इतना ही। यही नियम है, और स्टार्टअप हायरिंग मार्गदर्शन इस पर एकमत है क्योंकि एक लंबी सूची संस्थापकों की सोच के विपरीत काम करती है: यह मानक नहीं बढ़ाती, बस गुणवत्ता में सुधार किए बिना आवेदक पूल को छोटा कर देती है। Recruiter-केंद्रित ढांचे 5 से 7 must-haves और 3 से 4 nice-to-haves को उस सीमा के रूप में सुझाते हैं जिसके बाद रिटर्न नकारात्मक होने लगते हैं।
यहाँ एक आँकड़ा है जो आपके आवश्यकता सूचियाँ लिखने के तरीके को बदल देना चाहिए: Harvard Business Review के शोध ने पाया कि महिलाएं किसी भूमिका के लिए तभी आवेदन करती हैं जब उन्हें लगता है कि वे लगभग सभी सूचीबद्ध योग्यताओं को पूरा करती हैं, जबकि पुरुष बहुत कम मानदंड पूरा करने पर आवेदन करते हैं। आपकी आवश्यकताओं की सूची पर हर अनावश्यक लाइन तटस्थ नहीं है। यह सक्रिय रूप से उन योग्य लोगों को फ़िल्टर कर रही है जो आपकी सूची को सच मानते हैं।
समाधान विशिष्टता है, न केवल संक्षिप्तता। इन दोनों की तुलना करें:
- अस्पष्ट: "Backend development experience required."
- विशिष्ट और परीक्षण योग्य: "Python के साथ REST APIs बनाने के 3+ वर्ष, जिसमें कम से कम एक production system शामिल हो जो वास्तविक user traffic संभालती हो।"
दूसरा संस्करण लिखने में छोटा है और स्क्रीन करने में नाटकीय रूप से आसान है। यह उम्मीदवार को यह भी बताता है कि अपने आवेदन में क्या उजागर करना है, बजाय उन्हें अनुमान लगाने के।
डिग्री आवश्यकताओं पर भी कड़ी नज़र डालें। जब तक भूमिका के लिए कोई लाइसेंस या मान्यता कानूनी रूप से आवश्यक न हो, एक डिग्री लाइन आमतौर पर आपकी must-haves के पास कहीं नहीं होनी चाहिए। यदि आप वास्तव में एक विशिष्ट टूल स्टैक का उपयोग करते हैं, तो इसे आवश्यकताओं में जोड़ने के बजाय एक अलग "Tools We Use" अनुभाग में सूचीबद्ध करें। जिस उम्मीदवार ने Linear को कभी नहीं छुआ लेकिन Asana के साथ तीन product launches चलाए हैं, वह अयोग्य नहीं है। वे एक Slack message दूर हैं उत्पादक होने से।

आप जिम्मेदारियों को स्कैन करने योग्य कैसे बनाते हैं?
अधिकांश उम्मीदवार किसी जॉब पोस्ट को ध्यान से पढ़ने का निर्णय लेने से पहले उसे स्किम करते हैं, यही कारण है कि आपके responsibilities अनुभाग का आकार उसकी सामग्री जितना ही मायने रखता है।
इसका मतलब सब कुछ पैराग्राफ में ठूंसना नहीं है। इसका मतलब उन चीज़ों के लिए बुलेट का उपयोग करना है जो वास्तव में एक कठोर दृश्य विराम से लाभान्वित होती हैं, जैसे तीन या चार सबसे उच्च-लीवर जिम्मेदारियां, और उस संदर्भ के लिए छोटे गद्य का उपयोग करना जो उन्हें जोड़ता है। 15 बुलेट पॉइंट की दीवार एक कार्य सूची की तरह पढ़ती है। तीन तीखे बुलेट के बाद एक तंग पैराग्राफ वास्तविक दायरे वाली भूमिका की तरह पढ़ता है।
सामान्य कर्तव्यों को परिणाम विवरण के रूप में फिर से लिखें। तुलना करें:
- सामान्य: "Manage customer support tickets."
- परिणाम-उन्मुख: "अपने पहले 60 दिनों में first-response time को दो घंटे से कम करें, और FAQ library बनाएं जो हमें वहाँ पहुंचाए।"
- सामान्य: "Write marketing copy."
- परिणाम-उन्मुख: "उस email sequence का स्वामित्व लें जो वर्तमान में 2% पर convert होती है और इसे Q2 के अंत तक 4% से ऊपर ले जाएं।"
- सामान्य: "Help with backend development."
- परिणाम-उन्मुख: "एक भी दिन downtime के बिना हमारी payments service को legacy queue system से migrate करें।"
परिणाम framing काम करती है क्योंकि यह उम्मीदवार को किसी ठोस चीज़ के खिलाफ खुद को मूल्यांकन करने देती है, बजाय यह अनुमान लगाने के कि "help with backend development" का मतलब typos ठीक करना है या कोई service architect करना।
Pro Tip: बुलेट लाइनों को लगभग 15 शब्दों से कम रखें। मोबाइल पर, इससे लंबी कोई भी चीज़ तीन लाइनों में wrap हो जाती है और आप जो दृश्य scannability चाहते थे वह पूरी तरह गायब हो जाती है।
स्टार्टअप को वेतन और इक्विटी के बारे में कितना साझा करना चाहिए?
एक वास्तविक वेतन सीमा प्रकाशित करें, न कोई placeholder, और न ही $60,000 का फैलाव जो उम्मीदवारों को कुछ नहीं बताता। मुआवजे की पारदर्शिता पर मार्गदर्शन लगातार पाता है कि एक यथार्थवादी वेतन सीमा प्रकाशित करने से आवेदन की मात्रा और आवेदक का विश्वास दोनों बढ़ते हैं, मुख्यतः क्योंकि उम्मीदवार तीन इंटरव्यू के बाद अंधे होकर आवेदन करने और यह जानने के बजाय खुद चयन कर सकते हैं कि संख्या काम नहीं करती।

एक संकीर्ण, ईमानदार सीमा आपके funnel के लिए एक विस्तृत सीमा से अधिक करती है जो तकनीकी रूप से सटीक लेकिन व्यावहारिक रूप से बेकार है। यदि भूमिका $95,000 से $105,000 के बीच वेतन देती है, तो यही कहें। यदि यह अनुभव स्तर के आधार पर $80,000 से $140,000 के बीच देती है, तो शायद आपने अभी तय नहीं किया है कि आप किस स्तर के लिए हायर कर रहे हैं, और यह पोस्ट करने से पहले ठीक करने लायक है।
यहाँ विशेष रूप से क्या स्पष्ट करना है:
- Base salary range, एक संख्या के रूप में, न कि "competitive" या "market rate" के रूप में।
- Equity framework, संक्षेप में भी: प्रतिशत सीमा या option pool आकार, और क्या यह 1-year cliff के साथ standard 4-year vesting है।
- Bonus structure, यदि कोई मौजूद है, एक लक्ष्य प्रतिशत के रूप में, न कि अस्पष्ट छोड़ा गया।
- मुख्य लाभ जो इस भूमिका के लिए वास्तव में अलग हैं, न कि किसी टेम्पलेट से कॉपी की गई सामान्य सूची।
हम पूर्ण स्वास्थ्य कवरेज और unlimited PTO प्रदान करते हैं जिसमें 10-दिन का minimum है जिसे हम वास्तव में लागू करते हैं।"* अंतिम खंड पर ध्यान दें। यह बताना कि कोई लाभ व्यवहार में वास्तव में कैसे काम करता है, लाभ से ही अधिक विश्वसनीय लगता है।
आवेदन निर्देशों में क्या होना चाहिए?
उम्मीदवारों को ठीक-ठीक बताएं कि क्या जमा करना है और send बटन दबाने के बाद क्या होता है। यहाँ अस्पष्टता न केवल आवेदकों को परेशान करती है, बल्कि यह सक्रिय रूप से आपको मिलने वाली चीज़ों की गुणवत्ता को कम करती है, क्योंकि विकल्पों वाले मजबूत उम्मीदवार उस भूमिका को कम प्राथमिकता देंगे जो उन्हें प्रक्रिया का कोई अंदाजा नहीं देती।
तीन चीज़ें मांगें, और केवल तीन, जब तक कि भूमिका को वास्तव में अधिक की आवश्यकता न हो: एक resume, तकनीकी भूमिकाओं के लिए एक प्रासंगिक portfolio या GitHub link, और एक generic cover letter के बजाय भूमिका के बारे में एक विशिष्ट प्रश्न का एक छोटा, लक्षित उत्तर। तीसरा आइटम पहले दो की तुलना में अधिक फ़िल्टरिंग काम करता है, क्योंकि इसे fake करने में वास्तविक प्रयास लगता है और यह तुरंत प्रकट करता है कि किसी ने वास्तव में पोस्टिंग पढ़ी है या नहीं।
अपेक्षित समयरेखा को अग्रिम रूप से प्रकाशित करना और आवश्यक सामग्री के बारे में स्पष्ट होना उम्मीदवार drop-off को मापनीय रूप से कम करता है और उस प्रकार की early-stage ghosting को रोकता है जो एक संस्थापक का सप्ताह बर्बाद कर देती है।
एक early-stage हायर के लिए एक यथार्थवादी समयरेखा कुछ इस तरह दिखती है: 3 business days के भीतर आवेदन समीक्षा, अगले सप्ताह के भीतर 20 मिनट की screening call, तुरंत बाद भेजा गया role-specific skills assessment, और प्रारंभिक आवेदन के 10 से 14 दिनों के भीतर अंतिम onsite या live working session। पोस्ट में ही इसके करीब कुछ प्रकाशित करें।
एक नमूना "how to apply" ब्लॉक: "अपना resume और इस प्रश्न का दो-पैराग्राफ उत्तर भेजें: सबसे अस्पष्ट समस्या क्या है जिसे आपने अधूरी जानकारी से हल किया? हम 3 business days के भीतर आवेदनों की समीक्षा करते हैं और दो सप्ताह के भीतर पूरी प्रक्रिया पूरी करने का लक्ष्य रखते हैं।" वह एकल वाक्य एक अपेक्षा निर्धारित करता है जो अधिकांश जॉब पोस्ट कभी सेट करने की जहमत नहीं उठातीं, और यही वह अंतर है एक उम्मीदवार के बीच जो जुनूनी रूप से अपना ईमेल चेक करता है और एक जो चुपचाप आपके प्रतिस्पर्धी की पोस्टिंग पर चला जाता है।
कौन सी भाषा संबंधी गलतियाँ चुपचाप अच्छे उम्मीदवारों को दूर भगाती हैं?
स्टार्टअप जॉब डिस्क्रिप्शन में सबसे आम गलती kitchen-sink requirements list है, वह जो एक mythical hire के लिए wish list की तरह पढ़ती है जो एक साथ senior engineer, product strategist और part-time community manager है। Recruiters तेजी से जॉब डिस्क्रिप्शन को एक sales document के रूप में मानते हैं न कि उन सभी चीजों की सूची के रूप में जो अच्छी होतीं, और लंबी सूचियां मजबूत उम्मीदवारों, विशेष रूप से महिलाओं, को आवेदन करने से असंगत रूप से हतोत्साहित करती हैं।
Masculine-coded भाषा उसी समस्या का एक सूक्ष्म संस्करण है। "dominant," "aggressive growth," या "ninja" जैसे शब्द किसी कौशल का वर्णन नहीं करते। वे एक व्यक्तित्व प्रकार का वर्णन करते हैं, और वे वास्तविक नौकरी प्रदर्शन के बारे में कोई संकेत जोड़े बिना चुपचाप आपके आवेदक पूल को संकुचित कर देते हैं।
| बचने योग्य वाक्यांश | स्पष्ट विकल्प |
|---|---|
| "Rockstar" या "ninja" developer | "Experienced backend engineer" |
| "Must thrive under pressure" | "साप्ताहिक रूप से बदलने वाली योजनाओं पर पुनः प्राथमिकता देने में सहज" |
| "Wear many hats" | "अपने पहले 90 दिनों में तीन अलग-अलग कार्यों का स्वामित्व लें: X, Y, Z" |
| "Aggressive growth targets" | "Q3 तक monthly signups को 500 से 2,000 तक बढ़ाएं" |
| "Competitive salary" | "$85,000 से $95,000 base, plus equity" |
| "Bachelor's degree required" (जब तक कानूनी रूप से आवश्यक न हो) | "[विशिष्ट कौशल] के साथ प्रदर्शित अनुभव" |
must-haves और nice-to-haves को वास्तव में अलग-अलग अनुभागों में रखें। उन्हें पोस्ट के बॉडी टेक्स्ट में वापस मिलाना, यहाँ तक कि बुलेटेड सूची में सही तरह से लेबल करने के बाद भी, उसी भ्रम को फिर से शुरू कर देता है जिसे आप ठीक करने की कोशिश कर रहे थे। और केवल compliance box चेक करने के लिए एक performative वेतन सीमा प्रकाशित करने के प्रलोभन का विरोध करें। $50,000 से $150,000 जैसी सीमा संकेत देती है कि या तो आपने तय नहीं किया है कि आप किस स्तर के लिए हायर कर रहे हैं या आप एक वास्तविक प्रतिबद्धता से बचने की कोशिश कर रहे हैं, और उम्मीदवार इसे तुरंत उसी तरह पढ़ते हैं।
दो पूर्ण स्टार्टअप जॉब डिस्क्रिप्शन उदाहरण जिन्हें आप अपना सकते हैं
सार्वभौमिक टेम्पलेट किसी भी भूमिका के लिए काम करता है: hook → outcome → team context → must-haves → salary → apply। यहाँ बताया गया है कि यह दो बहुत अलग early-stage भूमिकाओं के लिए पूरी तरह कैसे काम करता है।
Backend Engineer, early-stage fintech startup (लगभग 280 शब्द)
हम वह payments infrastructure बना रहे हैं जो छोटे व्यवसायों को merchant account के बिना card payments स्वीकार करने देता है। जब हम 500 से 5,000 daily transactions तक scale करेंगे, तो आप हमारी मुख्य transaction service के स्वामी होंगे, जिसका अर्थ है कि इस वर्ष आप जो reliability निर्णय लेते हैं वे निर्धारित करते हैं कि क्या हम downtime के बिना उस विकास का समर्थन कर सकते हैं।
अपने पहले 90 दिनों में, आप हमारी legacy payment queue को fault-tolerant architecture में migrate करेंगे और हमारी P1 incident rate को आधे से कम करेंगे।
आप सीधे हमारे दो संस्थापकों और एक अन्य engineer के साथ काम करेंगे। अभी तक कोई अलग QA team नहीं है, इसलिए आप जो build करते हैं उसके testing के स्वामी आप होंगे।
Day 1 पर आपको क्या चाहिए होगा:
- Production REST APIs बनाने के 3+ वर्ष, आदर्श रूप से Python या Go में
- Payment processing systems या PCI-compliant infrastructure के साथ प्रत्यक्ष अनुभव
- किसी dedicated ops team के बिना end-to-end service का स्वामित्व लेने में सहजता
Nice to have: Kubernetes के साथ अनुभव, पूर्व startup अनुभव, Stripe के API से परिचितता।
आवेदन करने के लिए: अपना resume और उस सबसे reliability-critical system के बारे में एक छोटी note भेजें जिसका आपने स्वामित्व लिया है। हम 3 business days के भीतर जवाब देते हैं।
Operations Generalist, seed-stage consumer startup (लगभग 260 शब्द)
हम direct-to-consumer skincare बेचते हैं और अभी-अभी 10,000 orders per month पार किए हैं। आप वह operations backbone बनाएंगे जो हमें बिना पहियों के निकले 30,000 तक पहुंचने देती है, जो उस returns process से शुरू होती है जो वर्तमान में मौजूद ही नहीं है।
90 दिनों के भीतर, आप average fulfillment delays को 4 दिनों से 24 घंटे से कम करेंगे और हमारी पहली लिखित returns policy तैयार करेंगे।
आप सीधे हमारे COO को report करेंगे और हमारी दो-व्यक्ति customer support team के साथ काम करेंगे।
Day 1 पर आपको क्या चाहिए होगा:
- एक छोटी कंपनी में operations या logistics भूमिका में 2+ वर्ष
- vendors या fulfillment partners के साथ negotiate करने का प्रत्यक्ष अनुभव
- शुरू से एक process बनाने का ट्रैक रिकॉर्ड, न केवल उसे बनाए रखना
Nice to have: e-commerce अनुभव, Shopify से परिचितता, supply chain background।
Pay: $70,000 से $80,000 base, plus equity 0.05% से 0.1% की सीमा में।
आवेदन करने के लिए: अपना resume और इस प्रश्न का दो-पैराग्राफ उत्तर भेजें: एक ऐसी process का वर्णन करें जो आपके आने से पहले पिछली नौकरी में मौजूद नहीं थी और जिसे आपने बनाया।
| अनुभाग | Backend engineer उदाहरण | Operations उदाहरण |
|---|---|---|
| Hook | Payments infrastructure scaling story | Fulfillment scaling story |
| 90-दिन का परिणाम | Queue migrate करें, incidents 50% कम करें | Delays को 24 घंटे तक कम करें, returns policy बनाएं |
| Must-haves | 3, तकनीकी और परीक्षण योग्य | 3, अनुभव-आधारित और परीक्षण योग्य |
| Nice-to-haves | 3, tool-specific | 3, industry-specific |
| मुआवजा | Base range plus equity band | Base range plus equity band |
आप जॉब डिस्क्रिप्शन को कौशल मूल्यांकन में कैसे बदलते हैं?
एक पूरी जॉब डिस्क्रिप्शन लेखन प्रक्रिया का अंत नहीं है। यह एक screening tool के लिए कच्चा माल है, और इसे उस तरह से treat करना ही वह चीज़ है जो उन संस्थापकों को अलग करती है जो तेज़, आत्मविश्वासपूर्ण हायर करते हैं उन संस्थापकों से जो मैन्युअल रूप से चालीस लगभग-समान resumes पढ़ने में फंसे रहते हैं।
यहाँ workflow है:
- अपने responsibilities अनुभाग से तीन मुख्य परिणाम निकालें। ऊपर के backend engineer उदाहरण के लिए, वे reliability engineering, API design, और QA team के बिना स्वतंत्र स्वामित्व हैं।
- प्रति परिणाम तीन कौशल परिभाषित करें। "Reliability engineering" के लिए, इसका मतलब हो सकता है production pressure में debugging, distributed systems में failure modes को समझना, और ऐसे tests लिखना जो वास्तव में regressions पकड़ें।
- प्रति कौशल दो से तीन छोटे test prompts बनाएं। एक prompt किसी उम्मीदवार से एक वर्णित production incident का निदान करने और एक fix प्रस्तावित करने के लिए कह सकता है, या queue-handling code के एक snippet की समीक्षा करने और failure points को flag करने के लिए।
- prompts को एक single short assessment में bundle करें, एक simple rubric के खिलाफ score किया गया: क्या response मुख्य समस्या की पहचान करती है, क्या यह एक काम करने योग्य fix प्रस्तावित करती है, और क्या यह tradeoffs की जागरूकता दिखाती है।
वह संरचना एक subjective resume review को वास्तविक output की objective तुलना में बदल देती है, जो ठीक वह अंतर है जिसे role-specific skill assessments बंद करने के लिए बनाए गए हैं। जैसे-जैसे आप अधिक हायर करते हैं लाभ compound होता है: तेज़ shortlists, कम resume-based bias, और interview का समय कमज़ोर उत्तरों को screen करने के बजाय मजबूत उत्तरों की जांच करने में बिताया जाता है।
Pro Tip: हर assessment को हाथ से न बनाएं। जो tools job description text से सीधे structured tests generate करते हैं, वे 40 मिनट की manual process को पांच मिनट की process में बदल सकते हैं, जो तब बहुत मायने रखता है जब आप एक साथ तीन भूमिकाओं के लिए हायर कर रहे हों।
स्टार्टअप संस्कृति पोस्टिंग में कैसे दिखनी चाहिए?
संस्कृति विशिष्टताओं में होनी चाहिए, न कि विशेषणों में। "हमारी संस्कृति fast-paced और collaborative है" लिखना एक उम्मीदवार को कुछ नहीं बताता, क्योंकि हर कंपनी चाहे वे सच हों या न हों, समान तीन शब्दों का दावा करती है। जो वास्तव में संस्कृति को संप्रेषित करता है वह यह है कि निर्णय कैसे लिए जाते हैं, असहमति कैसे हल होती है, और एक बुरा सप्ताह होने पर कैसा दिखता है।
एक छोटा, ईमानदार "expectations" अनुभाग शामिल करने पर विचार करें जो early-stage काम की वास्तविकताओं को स्पष्ट रूप से बताता है: प्राथमिकताएं सप्ताह दर सप्ताह बदलती हैं, अधिकांश भूमिकाओं के लिए अभी तक कोई dedicated support function नहीं है, और अस्पष्टता अपवाद के बजाय default state है। इस तरह की सीधी framing उन उम्मीदवारों के लिए filter करती है जो उस वातावरण को थकाऊ के बजाय ऊर्जादायक पाते हैं, और उन लोगों को दूर भगाती है जो एक महीने के भीतर वहाँ दुखी हो जाते। जो संस्थापक इस अनुभाग को जोड़ते हैं वे रिपोर्ट करते हैं कि यह लगभग तुरंत ही आवेदन करने वालों के tenor को बदल देता है, क्योंकि यह उस अस्पष्ट आशावाद के विपरीत है जिसे अधिकांश पोस्टिंग default करती हैं।
आप लचीलापन और विकास की संभावना को कैसे उजागर करते हैं?
स्टार्टअप वास्तव में कुछ ऐसा प्रदान करते हैं जो बड़ी कंपनियां संरचनात्मक रूप से नहीं कर सकतीं: अच्छा काम करने और उसके लिए अधिक जिम्मेदारी मिलने के बीच बहुत कम दूरी। यह एक वास्तविक लाभ है, लेकिन केवल तभी जब आप इसे एक generic "room to grow" लाइन के साथ इंगित करने के बजाय ठोस रूप से बताते हैं।
"opportunity for advancement" के बजाय, लिखें कि आपकी कंपनी के वर्तमान चरण में advancement वास्तव में कैसा दिखता है। यदि आपके पहले ops hire के पास आपकी growth trajectory को देखते हुए एक वर्ष के भीतर एक तीन-व्यक्ति team बनाने और lead करने का यथार्थवादी मौका है, तो यह सीधे कहें। यदि आपका engineering hire संभवतः आपके Series A raise करने तक आपका technical lead होगा, तो यह भी कहें। विशिष्ट, प्रशंसनीय विकास पथ अमूर्त वादों की तुलना में कहीं अधिक persuasive हैं, और एक उम्मीदवार के लिए अपने स्वयं के career goals के खिलाफ ईमानदारी से मूल्यांकन करना भी आसान है।
लचीलेपन को भी यही विशिष्टता चाहिए। "Flexible schedule" का हर कंपनी में अलग-अलग मतलब है। अपने वास्तविक norms बताएं: core hours, async expectations, दिन-प्रतिदिन अपने calendar पर किसी को कितनी autonomy है।
क्या स्टोरीटेलिंग वास्तव में भर्ती में मदद कर सकती है?
एक जॉब डिस्क्रिप्शन जो एक legal document की तरह पढ़ती है वह उन लोगों को आकर्षित करती है जो एक predictable, well-defined भूमिका चाहते हैं। एक जॉब डिस्क्रिप्शन जो एक छोटी, विशिष्ट कहानी सुनाती है वह उन लोगों को आकर्षित करती है जो कुछ बनाना चाहते हैं। वेतन पर अधिक खर्च करने वाली कंपनियों के खिलाफ प्रतिस्पर्धा करने वाले स्टार्टअप के लिए, storytelling अक्सर एकमात्र lever बचा होता है जो वास्तव में काम करता है।
कहानी को elaborate होने की ज़रूरत नहीं है। इसे एक ठोस विवरण चाहिए जो एक generic posting में शामिल नहीं होता: वह विशिष्ट समस्या जो कंपनी हल कर रही है, वह क्षण जिसने इस exact hire की आवश्यकता को प्रकट किया, या वह scale जिसे संस्थापक hit करने की उम्मीद करता है और कब तक। एक posting जो "हमने देखा कि customers manually spreadsheets में invoices reconcile कर रहे थे, और हमने ऐसा software बनाया जो इसे seconds में करता है" से शुरू होती है, वह तीन paragraphs के mission-statement language की तुलना में एक वाक्य में अधिक कहती है। Entrepreneurial-minded candidates, जो ambiguity में thrive करते हैं और ownership चाहते हैं, specificity पर respond करते हैं क्योंकि यह एक fill करने की job के बजाय हल करने लायक एक real problem का संकेत देती है।
आप पोस्टिंग में रिमोट और हाइब्रिड विकल्पों को कैसे संभालते हैं?
अपनी वास्तविक policy को एक स्पष्ट वाक्य में बताएं, न कि "flexibility" की ओर एक अस्पष्ट इशारे के रूप में। स्टार्टअप तेजी से remote-first या hybrid arrangements में default हो रहे हैं, और उम्मीदवार अब इसे एक primary filter के रूप में मानते हैं जो वेतन जितना ही महत्वपूर्ण है, इसलिए इसे posting के paragraph चार में दफनाना उस clarity को बर्बाद करता है जो यह शुरुआत में प्रदान कर सकता था।
यदि भूमिका पूरी तरह remote है, तो बताएं कि क्या team overlap hours से जुड़े time zone constraints हैं। यदि यह hybrid है, तो "occasional office visits" के बजाय वास्तविक expected in-office days बताएं, जिसका अर्थ इसे पढ़ने वाले हर उम्मीदवार के लिए अलग होता है। यदि भूमिका के लिए relocation आवश्यक है या operational कारणों से यह strictly on-site है, तो किसी उम्मीदवार को तीन interviews के बाद यह पता लगाने देने के बजाय सीधे कहें। यहाँ अस्पष्टता flexibility नहीं बनाती। यह ऐसे उम्मीदवार बनाती है जो एक धारणा के तहत offer स्वीकार करते हैं और वास्तविकता स्थापित होने पर दो महीने के भीतर छोड़ देते हैं।
स्टार्टअप जॉब डिस्क्रिप्शन को कितनी बार अपडेट करना चाहिए?
हर जॉब डिस्क्रिप्शन को एक living document के रूप में treat करें, न कि एक one-time artifact के रूप में। छह महीने पहले एक भूमिका के लिए लिखी गई posting शायद ही कभी reflect करती है कि कंपनी को आज वास्तव में क्या चाहिए, विशेष रूप से उस pace पर जिस पर अधिकांश early-stage startups evolve करते हैं, और stale language को repost करना आपका और उम्मीदवारों दोनों का समय बर्बाद करता है।
इनमें से किसी भी trigger के तुरंत बाद JD अपडेट करें: भूमिका के core outcomes एक pivot के कारण बदल जाते हैं, आप एक समान भूमिका के लिए एक hire पूरा करते हैं और सीखते हैं कि interviews में वास्तव में क्या मायने रखा, या दो सप्ताह की posting window में आपकी applicant quality ध्यान से गिरती है। वह अंतिम संकेत अक्सर सबसे स्पष्ट होता है। यदि एक posting जो पहले एक सप्ताह में पांच strong applicants generate करती थी अचानक शून्य generate करती है, तो बाज़ार चला गया है या आपकी language stale हो गई है, और यह मानने से पहले कि talent pool सूख गया है एक rewrite लायक है।
हर बार जब आप किसी posting को touch करते हैं तो एक simple internal log रखें कि क्या बदला और क्यों। तीन या चार hires पर, वह log अपना स्वयं का internal playbook बन जाता है कि कौन सी phrasing और structure वास्तव में convert करती है।
Early-stage startups के लिए हायरिंग करते समय सीखे गए व्यावहारिक सबक
जो pattern मैं सबसे अधिक fail होते देखता हूँ वह एक बुरी जॉब डिस्क्रिप्शन नहीं है। यह एक तकनीकी रूप से ठीक जॉब डिस्क्रिप्शन है जो भूमिका की stability को oversell करती है और उसकी वास्तविक मांगों को undersell करती है, जो ऐसे उम्मीदवार produce करती है जो offer स्वीकार करते हैं और फिर probation window के भीतर छोड़ देते हैं जब उन्हें पता चलता है कि नौकरी में वास्तव में क्या है। जो postings multiple hiring cycles में टिकी रहती हैं वे सीधी हैं, जो शुरुआत में एक या दो कठिन rejection criteria का नाम लेने के लिए तैयार हैं, बजाय सबको appeal करने की कोशिश के।
जो consistently काम करता है वह job description को interview scorecard का पहला draft मानना है, न कि brain के एक अलग हिस्से द्वारा लिखा गया एक अलग document। यदि कोई requirement इसके लिए test करने के लिए पर्याप्त specific नहीं है, तो यह आमतौर पर इसके लिए screen करने के लिए भी पर्याप्त specific नहीं है, और इसे शायद काट दिया जाना चाहिए।
कुछ operational habits तुरंत अपनाने लायक:
- हर completed hire के बाद job description को revisit और edit करें, अगले version को तेज़ करने के लिए interviews में जो सीखा उसका उपयोग करते हुए।
- केवल volume नहीं, application quality track करें, और quality में गिरावट को talent pool कमज़ोर मानने से पहले rewrite का संकेत मानें।
- हर job description को सीधे उस skills assessment से जोड़ें जिसका उपयोग आप candidates को screen करने के लिए करेंगे, ताकि दोनों documents कभी अलग न हों।
Talent Approved आपके JD को हायरिंग शॉर्टकट में कैसे बदलता है
एक बार जब आपकी job description tight हो जाती है, तो उस पर act करने का सबसे तेज़ तरीका है इसे सीधे एक skill assessment में feed करना, बजाय उन्हीं requirements को दूसरी बार manually hand से rewrite करने के। Talent Approved का Magic Create feature ठीक यही करता है: अपनी finished job description या एक short skill list paste करें, और यह minutes में एक role-specific assessment build करता है, बजाय उन घंटों के जो scratch से test questions लिखने में लगते हैं।

Platform उन हिस्सों को संभालता है जो screening के दौरान founder का समय खाते हैं। Built-in anti-cheat monitoring, जिसमें screen और webcam checks शामिल हैं, results को honest रखता है। AI-generated summaries और candidate rankings का मतलब है कि आप चालीस raw transcripts के बजाय एक छोटा, structured readout review कर रहे हैं। क्योंकि assessment आपकी job description के वास्तविक must-haves से सीधे generated है, यह एक generic competency bank के बजाय आपके द्वारा listed specific skills को test करता है, जो आपने जो मांगा और आप वास्तव में क्या measure करते हैं उसके बीच की खाई को बंद करता है।
Talent Approved एक pay-as-you-go model पर चलता है, प्रति candidate जो assessment complete करता है $5 fee, जिसमें कोई subscription commitment आवश्यक नहीं है। यदि आपने अभी ऊपर दिए गए framework का उपयोग करके एक job description तैयार की है, तो स्वाभाविक अगला कदम है इसे एक test में बदलना: अपनी job description से एक skill test बनाएं और देखें कि यह आपके पहले batch of applicants पर कौन सी candidate ranking produce करता है।
स्रोत
कुछ sources ने इस article में मार्गदर्शन को आकार दिया, और यदि आप यह case बना रहे हैं कि आपकी team job postings कैसे लिखती है, तो प्रत्येक को करीब से पढ़ने लायक है।
- Why Women Don't Apply for Jobs Unless They're 100% Qualified | Harvard Business Review
- How to Write Job Descriptions That Attract Top Candidates | StartupKit
- How to Write Job Descriptions That Attract Qualified Candidates | Recruiter Copilot
- How to Write Startup Job Descriptions — Allied Venture Partners
FAQ
हायरिंग में 70/30 नियम क्या है?
नौकरी में 3 महीने का नियम क्या है?
जॉब डिस्क्रिप्शन लेखन में, "3 month" framing आमतौर पर एक ठोस परिणाम बताने को refer करती है जो नए hire को अपने पहले 90 दिनों के भीतर प्राप्त करना चाहिए, जो candidate और employer दोनों को fit और performance के लिए एक स्पष्ट early benchmark देता है।
जॉब डिस्क्रिप्शन में सामान्य गलतियाँ क्या हैं?
सबसे सामान्य गलतियाँ हैं kitchen-sink requirement lists जो योग्य candidates को आवेदन करने से हतोत्साहित करती हैं, "fast-paced environment" जैसे अस्पष्ट corporate clichés, missing या performative salary ranges, और job boards के लिए index करने के लिए बहुत creative शीर्षक।
जॉब डिस्क्रिप्शन विकसित करने के लिए एक अच्छा शुरुआती बिंदु क्या है?
उस परिणाम से शुरू करें जो hire को अपने पहले 90 से 180 दिनों में deliver करना है, फिर कर्तव्यों की generic list से शुरू करने के बजाय उसे hit करने के लिए आवश्यक तीन से पांच must-have skills पर वापस काम करें।
मैं एक finished job description को skills test में कैसे बदलूं?
भूमिका के core outcomes निकालें, प्रति outcome दो या तीन testable skills परिभाषित करें, और उनके आसपास short prompts बनाएं। Talent Approved का Magic Create feature इस प्रक्रिया को सीधे आपकी job description text से automate करता है।