നിങ്ങൾ എപ്പോഴെങ്കിലും ഒരു അപേക്ഷകരെ തിരഞ്ഞെടുക്കുന്ന സിസ്റ്റത്തിലേക്ക് (applicant tracking system) ഒരു റെസ്യൂമെ അപ്ലോഡ് ചെയ്തിട്ടുണ്ടെങ്കിൽ, എന്തുകൊണ്ടാണ് ഒരു മനുഷ്യൻ അത് കാണാത്തതെന്ന് ചിന്തിച്ചിട്ടുണ്ടെങ്കിൽ, AI റിക്രൂട്ട്മെന്റിലെ 'ബ്ലാക്ക്-ബോക്സ്' (black-box) പ്രശ്നം നിങ്ങൾക്കറിയാം. മിക്ക റെസ്യൂമെ സ്കോറിംഗ് ടൂളുകളും അവരുടെ യുക്തികൾ SaaS ഡാഷ്ബോർഡുകൾക്കും മര്യാദയുള്ള റിജക്ഷൻ ഇമെയിലുകൾക്കും പിന്നിൽ ഒളിപ്പിച്ചു വെക്കുന്നു. HackerRank മറ്റൊരു വഴി തിരഞ്ഞെടുത്തു. ഇതിന്റെ Hiring Agent ഒരു ഓപ്പൺ സോഴ്സ് പ്രോഗ്രാമാണ്, അതായത് ആർക്കും ഇതിന്റെ കോഡ് പരിശോധിക്കാനും ഒരു LLM എങ്ങനെ ഒരു PDF-ഉം GitHub ലിങ്കും ഉപയോഗിച്ച് ഒരു സ്കോർ നിർമ്മിക്കുന്നു എന്ന് കൃത്യമായി മനസ്സിലാക്കാനും സാധിക്കും. ഒരു ഡെവലപ്പർ ഇത് കൃത്യമായി ചെയ്തു. അവർ കണ്ടെത്തിയത് ഒരു മികച്ച റിക്രൂട്ടിംഗ് ഫ്രെയിംവർക്ക് അല്ല, മറിച്ച് ഓട്ടോമേഷൻ എങ്ങനെ വളരെ എളുപ്പത്തിൽ വ്യക്തിപരമായ അഭിപ്രായങ്ങളെ കോഡുകളാക്കി മാറ്റുന്നു എന്ന് കാണിക്കുന്ന ഒരു കണ്ണാടിയാണ്.
പ്രവർത്തനരീതി
ഈ പ്രക്രിയ കാണാൻ വളരെ ലളിതമാണ്. ഒരു ഉദ്യോഗാർത്ഥിയുടെ PDF റെസ്യൂമെ ആദ്യം Markdown-ലേക്ക് മാറ്റുന്നു, തുടർന്ന് അത് തൊഴിൽ ചരിത്രം, കഴിവുകൾ, വിദ്യാഭ്യാസം, സൈഡ് പ്രോജക്റ്റുകൾ എന്നിവയ്ക്കായി കൃത്യമായ ഒരു JSON ഘടനയിലേക്ക് മാറ്റുന്നു. Python സ്ക്രിപ്റ്റുകൾ ഈ ഡാറ്റ ഓരോ ഘട്ടത്തിലേക്കും എത്തിക്കുന്നുണ്ടെങ്കിലും, യഥാർത്ഥ ചിന്താപ്രക്രിയ നടക്കുന്നത് പ്രോംപ്റ്റുകളുടെ (prompts) ഒരു ശൃംഖലയ്ക്കുള്ളിലാണ്. ഓരോ വിഭാഗത്തിനും അതിന്റേതായ പ്രോംപ്റ്റുകൾ ഉണ്ട്. LLM ഈ ഘടനയിലുള്ള ഡാറ്റ വായിക്കുകയും, ലളിതമായ ഇംഗ്ലീഷിൽ എഴുതപ്പെട്ട സ്കോറിംഗ് നിയമങ്ങൾ പ്രയോഗിക്കുകയും, ഒരു ഗ്രേഡ് നൽകുകയും ചെയ്യുന്നു.
ഈ ആർക്കിടെക്ചർ വളരെ പ്രധാനപ്പെട്ടതാണ്. ഇതിലെ പ്രധാനപ്പെട്ട കാര്യങ്ങൾ നടക്കുന്നത് ബുദ്ധിപരമായ അൽഗോരിതങ്ങളിലോ ട്രെയിനിംഗ് ലൂപ്പുകളിലോ അല്ല, മറിച്ച് പ്രോംപ്റ്റുകളുടെ വാക്കുകളിലാണ്. നിർദ്ദേശങ്ങളിൽ ഏതാനും വിശേഷണങ്ങൾ മാറ്റിയാൽ മതി, ഒരേ എഞ്ചിനീയർ ഒരു മികച്ച ഉദ്യോഗാർത്ഥിയിൽ നിന്ന് ഒരു ദുർബലനായ ഉദ്യോഗാർത്ഥിയായി മാറിയേക്കാം. ഇത് ഈ ടൂളിനെ അസ്ഥിരമാക്കുന്നു, അതേസമയം തന്നെ ഇത് സത്യസന്ധവുമാണ്. മിക്ക AI റിക്രൂട്ടിംഗ് കമ്പനികളും അവരുടെ പ്രോംപ്റ്റുകൾ നിങ്ങൾക്ക് കാണാൻ അനുവദിക്കില്ല. എന്നാൽ HackerRank-ന്റെ ഈ പ്രോടോട്ടൈപ്പ് ഒരു സത്യം വെളിപ്പെടുത്തുന്നു: റെസ്യൂമെ സ്കോറിംഗ് എന്നത് എപ്പോഴും കോഡിനെക്കുറിച്ചല്ല, മറിച്ച് അതിന്റെ മാനദണ്ഡങ്ങളെ (rubric) കുറിച്ചായിരുന്നു.
35 ശതമാനത്തിന്റെ ആധിപത്യം
ഏറ്റവും ശ്രദ്ധേയമായ പക്ഷപാതം സ്കോറിംഗ് റൂബ്രിക്ನಲ್ಲಿ ഒളിഞ്ഞിരിപ്പുണ്ട്. ആകെ സ്കോറിന്റെ 35 ശതമാനം ഓപ്പൺ സോഴ്സ് സംഭാവനകൾക്കാണ് നൽകുന്നത്. ഇത് വളരെ വലിയൊരു പങ്കാണ്. അതായത്, ഒരു ഉദ്യോഗാർത്ഥിയുടെ മുഴുവൻ തൊഴിൽ ചരിത്രവും വിദ്യാഭ്യാസവും കഴിവുകളും ബാക്കിയുള്ള 65 ശതമാനത്തിനുള്ളിൽ മത്സരിക്കണം, എന്നാൽ അവരുടെ കോഡിംഗ് ജീവിതത്തിലെ ഒരു ചെറിയ ഭാഗം മാത്രം 35 ശതമാനമായി മാറുന്നു.
നിയമങ്ങൾ ഈ വിഹിതത്തേക്കാൾ കഠിനമാണ്. വ്യക്തിഗത GitHub റെപ്പോസിറ്ററികൾ ഇതിൽ പരിഗണിക്കില്ല. നിങ്ങൾ സ്വന്തമായി ഒരു ലൈബ്രറി പരിപാലിക്കുന്നുണ്ടെങ്കിൽ, അത് എത്രത്തോളം ഉപകാരപ്രദമാണെങ്കിലും സ്കോർ പൂജ്യം ആയിരിക്കും. മറ്റുള്ളവരുടെ പ്രോജക്റ്റുകളിലെ സംഭാവനകൾക്ക് മാത്രമേ ഈ ടൂൾ പ്രതിഫലം നൽകുന്നുള്ളൂ. ആ പോയിന്റുകൾ നേടുന്നതിന് ഉദ്യോഗാർത്ഥി മറ്റൊരാളുടെ കോഡ്ബേസിൽ ഒരു കമിറ്റർ (committer) ആയിരിക്കണം.
ഈ മുൻഗണന വലിയ സാമൂഹിക സ്വാധീനമുണ്ടാക്കുന്നുണ്ട്. സ്വന്തമായി ടൂളുകൾ നിർമ്മിക്കുന്ന എഞ്ചിനീയർമാർ പലപ്പോഴും മറ്റാരും പരിഹരിക്കാത്ത പ്രശ്നങ്ങൾക്ക് പരിഹാരം കാണുന്നവരാണ്. അവർക്ക് പുറത്തുനിന്നുള്ള സംഭാവനകൾ നിരോധിക്കുന്ന ജോലികൾ ആയിരിക്കാം, അല്ലെങ്കിൽ വലിയ ഓപ്പൺ സോഴ്സ് കമ്മ്യൂണിറ്റികൾ ഇല്ലാത്ത പ്രദേശങ്ങളിൽ ജോലി ചെയ്യേണ്ടി വന്നേക്കാം, അല്ലെങ്കിൽ കുടുംബപരമായ ഉത്തരവാദിത്തങ്ങൾ കാരണം ജോലിക്ക് ശേഷമുള്ള കോഡിംഗ് അസാധ്യമായവരാകാം. പ്രോംപ്റ്റ് ഇത്തരത്തിൽ എഴുതുന്നതിലൂടെ, ഈ ടൂൾ യഥാർത്ഥ എഞ്ചിനീയറിംഗ് കഴിവല്ല അളക്കുന്നത്. മറിച്ച്, ഒരു പ്രത്യേക കോഡിംഗ് സംസ്കാരത്തിലെ പങ്കാളിത്തത്തെയാണ് അത് അളക്കുന്നത്, എന്നിട്ട് അതിനെ നിഷ്പക്ഷത എന്ന് വിളിക്കുന്നു.
നിർദ്ദേശങ്ങൾ ഫലിക്കാത്തപ്പോൾ
സ്റ്റാർട്ടപ്പിലെ പ്രവൃത്തിപരിചയത്തിന് മുൻഗണന നൽകാനും ഈ റൂബ്രിക് ശ്രമിക്കുന്നുണ്ട്. ഫൗണ്ടർമാർക്കും (founders) തുടക്കകാലത്തെ എഞ്ചിനീയർമാർക്കും അധിക പോയിന്റുകൾ നൽകണമെന്ന് പ്രോംപ്റ്റിൽ വ്യക്തമായി നിർദ്ദേശിക്കുന്നുണ്ട്. സിദ്ധാന്തപരമായി ഇത് ന്യായമായി തോന്നാം. സ്റ്റാർട്ടപ്പുകളിൽ പ്രവർത്തിക്കുന്നവർ പലപ്പോഴും ഒരേസമയം പല ചുമതലകൾ നിർവഹിക്കുകയും സമ്മർദ്ദത്തിനിടയിൽ ജോലി ചെയ്യുകയും ചെയ്യുന്നവരാണ്. അതിനാൽ ടെസ്റ്റർ ഒരു പരീക്ഷണം നടത്തി. അവർ ഒരൊറ്റ റെസ്യൂമെ എടുത്ത് അതിലെ ഏറ്റവും പുതിയ ജോലിയുടെ പേര് മാത്രം മാറ്റി, മൂന്ന് വ്യത്യസ്ത ലേബലുകളോടെ മൂന്ന് തവണ ഏജന്റിന് നൽകി: Senior Java Engineer, Founding Engineer, Co-founder / CTO.
സ്കോറുകളിൽ വലിയ മാറ്റമൊന്നും വന്നില്ല. LLM അടിസ്ഥാനപരമായി ആ നിർദ്ദേശം അവഗണിച്ചു.
ഈ ഓഡിറ്റിലെ ഏറ്റവും പ്രധാനപ്പെട്ട കണ്ടെത്തലുകളിൽ ഒന്നാണിത്. ഒരു പ്രോംപ്റ്റ് നിയമം എന്നത് വെറുമൊരു നിർദ്ദേശം മാത്രമാണെന്ന് ഇത് തെളിയിക്കുന്നു. ഏതാണ് ഗുണനിലവാരമുള്ളതെന്ന് തീരുമാനിക്കുന്ന കാര്യത്തിൽ വലിയ ഭാഷാ മാതൃകകൾക്ക് (LLMs) അവരുടേതായ മുൻവിധികൾ ഉണ്ടാകാം. മോഡലിന്റെ ട്രെയിനിംഗ് ഡാറ്റ ചില പദവികളെയോ കമ്പനികളുടെ പേരുകളെയോ ആണ് ഗുണനിലവാരമായി കാണുന്നതെങ്കിൽ, നിങ്ങൾ ശ്രദ്ധയോടെ എഴുതിയ നിർദ്ദേശങ്ങൾ അവഗണിക്കപ്പെട്ടേക്കാം. സ്റ്റാർട്ടപ്പ് പദവികൾക്ക് പ്രാധാന്യം നൽകാൻ പ്രോംപ്റ്റ് മോഡലിനോട് പറയുന്നുണ്ടെങ്കിലും, മോഡലിന് അതിന്റേതായ ആശയങ്ങളുണ്ട്, അവയാണ് വിജയിക്കുന്നത്. മനുഷ്യന്റെ ഉദ്ദേശ്യവും യന്ത്രത്തിന്റെ പെരുമാറ്റവും തമ്മിലുള്ള ഈ വ്യത്യാസം ഒരു റിക്രൂട്ടിംഗ് സ്കോർ നൽകുമ്പോൾ അപകടകരമാണ്.
ലക്ഷ്യമില്ലാത്ത പോയിന്റുകൾ
പ്രധാനപ്പെട്ട കാര്യങ്ങൾക്കപ്പുറം, ഈ റൂബ്രിക് വിചിത്രമായ ചില സൂക്ഷ്മ നിയമങ്ങളാൽ (micro-rules) നിറഞ്ഞതാണ്. ഇവ ഡാറ്റാധിഷ്ഠിത തീരുമാനങ്ങളേക്കാൾ ഉപരിയായി, ആരെങ്കിലും രാത്രിയിൽ വെറുതെ ചിന്തിച്ചുണ്ടാക്കിയ കാര്യങ്ങൾ പോലെയാണ് തോന്നിക്കുന്നത്.
A LinkedIn profile is worth exactly one point. Not the quality of the profile. Not the number of recommendations or the depth of the work history. Simply having a URL on the resume adds a single point to the total. Meanwhile, being a Google Summer of Code participant is worth five points. And if a candidate has forked repositories on GitHub, the agent ignores any fork with fewer than five forks of its own.
Each of these rules makes a loud value judgment disguised as a quiet coefficient. Why is LinkedIn presence worth a point at all? It signals that a candidate knows how to fill out a social network, not that they can architect a distributed system. Why is GSoC worth five times as much as a LinkedIn link? Perhaps because the prompt author respects the program. That respect is now a hiring policy. And why draw the line at five forks? A tool with ten users might solve a critical niche problem. Under this system, it might as well not exist.
These numbers do not emerge from regression analysis. They were chosen by individuals. One person decided open source participation is more than a third of an engineer’s worth. Another person decided a LinkedIn profile is worth 1 point. When you automate those guesses, you give them the authority of software.
Every Prompt Is a Prejudice
The hardest part of building a resume-scoring agent is not parsing PDFs or calling an API. It is deciding what matters. Every word in a scoring prompt is a value judgment about what makes a good engineer. Should side projects outweigh day jobs? Should public code matter more than private enterprise work? Should a social media profile matter at all? There are no mathematically correct answers to these questions. There are only cultural preferences.
When a recruiting team does this manually, at least the biases are distributed across many reviewers who can disagree, calibrate, and learn. When an LLM does it, the biases of one prompt engineer harden into a repeatable function that runs at scale. The tool does not eliminate subjectivity. It archives it.
Use It as a Mirror, Not a Filter
HackerRank’s Hiring Agent is best understood as a prototype. It feels like a first draft, which is exactly what it is. It offers a fascinating early look at how AI hiring tools are constructed, but it lacks the calibration, testing, and diverse input of a real recruiting organization.
If you are building hiring tech, study it carefully. It shows how quickly arbitrary rules turn into automated gatekeeping. If you are a candidate,remember that these systems are not oracles. They are spreadsheets dressed up in natural language, and they carry the assumptions of whoever wrote the prompts.
Until these tools are tested for bias as rigorously as the engineers they judge, they should inform human conversation, not replace it.