डेवलपर साक्षात्कार

एक तकनीकी साक्षात्कार लगभग किसी भी डेवलपर के रोजगार का एक अभिन्न गुण है, और वरिष्ठ डेवलपर्स के लिए, उन्हें (साक्षात्कार) आयोजित करना भी लगभग हर रोज का कर्तव्य है। लेकिन आवेदक के वास्तविक अनुभव के अधिक या कम स्वीकार्य विचार बनाने के लिए समय की एक छोटी अवधि (आदर्श रूप से 20-30 मिनट) में कैसे?

मुझे याद है पहली बार जब मुझे WPF पर एक युवक का इंटरव्यू लेने के लिए कहा गया था - मैंने कई घंटों के लिए पूछने लायक एक सूची बनाई थी (और उत्तरों की जांच की ताकि मेरे चेहरे पर कीचड़ न फेंके) ताकि हम कम से कम कंपनी में कुछ हद तक निश्चितता के साथ कह सकें ऐसा व्यक्ति या नहीं। और अब, 10-15 प्रश्नों से लैस, मैं बातचीत कक्ष में प्रवेश करता हूं, अपना परिचय देता हूं, एक-दो सामान्य प्रश्न पूछता हूं और, वैसे, निर्दिष्ट करें:
- और आपके पास WPF का उपयोग करते हुए कितने वर्षों का विकास का अनुभव है?
- मुझे नहीं पता WPF ...।
- ...
यह अजीब क्षण जब आपको एहसास होता है कि आपने सबसे स्पष्ट को छोड़कर सब कुछ छोड़ दिया है ...

एक और मोड़, मेरे लिए कोई कम अप्रत्याशित नहीं था, जब आवेदक के सीवी ने 5 साल के विकास के अनुभव का संकेत दिया और पेचीदा परियोजना विवरणों का एक समूह सूचीबद्ध किया गया था, और वास्तव में, एक व्यक्ति शायद ही यह समझा सके कि संदर्भ प्रकार महत्वपूर्ण लोगों से अलग कैसे हैं, और कचरा संग्रह के बारे में कहा यह सब पता है कि आपको .Net में स्मृति के बारे में सोचने की आवश्यकता नहीं है:

क्या पूछा जा सकता है ताकि आप उत्तर पर कुछ महत्वपूर्ण के रूप में भरोसा कर सकें?
- पूछें कि उसने कितनी किताबें पढ़ीं और कितनी बार? लेकिन सीखा योगों का मतलब यह नहीं है कि एक व्यक्ति वास्तविक समस्याओं को हल करने में सक्षम है, जिसके निर्माण में किताबों से अलग है और कभी-कभी एक या किसी अन्य कारण से विकास के सामान्य सिद्धांतों से विचलन की आवश्यकता होती है।
- पर्यावरण की सभी तकनीकी बारीकियों को लिखिए और उनके बारे में पूछिए? लेकिन सच में, जिन्हें कभी ज्ञान की आवश्यकता थी कि कचरा संग्रह कैसे काम करता है (जो संस्करण से संस्करण में भी बदलता है) और कितनी पीढ़ियाँ हैं? मैं यह नहीं कह रहा हूं कि यह अतिरिक्त ज्ञान किसी भी तरह से नहीं है, लेकिन इस सुविधा का ज्ञान या अज्ञान डेवलपर की "गुणवत्ता" को निर्धारित करने की अनुमति नहीं देगा।
- एक कोड उदाहरण के लिए पूछें? लेकिन वे आपको कौन सा कोड दिखाएंगे? कितने लोग पहले से ही इस पर शासन करते हैं? किन स्थितियों में लिखा गया था? क्या होगा अगर इन शानदार 300 लाइनों को बारिश के मौसम में अटलांटिक महासागर के सर्फ की एक महीने के लिए लिखा गया था? क्या हम अगले 300 शानदार लाइनों को प्राप्त करने के लिए "काम करने" के माहौल को फिर से बना सकते हैं?

मैं अपने विचारों को साझा करना चाहता हूं और साक्षात्कार के लिए इस दृष्टिकोण की रचनात्मक आलोचना सुनना चाहता हूं। मेरा विचार "OWN" कोड दिखाना और सुनना है। शाम के समय, मैंने एक भयानक कोड का उदाहरण दिया, जिसमें सबसे आम "त्रुटियां" शामिल थीं। मुझे उम्मीद है कि 4 साल या उससे अधिक के वास्तविक विकास के अनुभव वाले एक वरिष्ठ डेवलपर को 80% से अधिक त्रुटियों की पहचान करनी चाहिए और एक काल्पनिक वास्तुकला में मौजूदा समस्याओं को इंगित करना चाहिए।

और हां, वास्तव में कोड:

1 using System; 2 using System.Collections.Generic; 3 4 namespace App.Services 5 { 6 public enum LoginResult 7 { 8 Unknown = 0, 9 Success = 1, 10 WrongLogin = -1, 11 WrongPass = -2, 12 Error 13 } 14 15 public class LoginService 16 { 17 public string LastError = string.Empty; 18 19 /// <summary> 20 /// Allow to login new user 21 /// </summary> 22 /// <param name="login">login</param> 23 /// <param name="password">password</param> 24 /// <param name="asAdmin">asAdmin</param> 25 /// <returns>login result</returns> 26 public LoginResult Login(string login, string password) 27 { 28 List<Login> dbLogins = new List<Login>(); 29 try 30 { 31 dbLogins.AddRange( 32 DAL.GetItems<Login>( 33 "select * from db.Login where Name='" + login + "'")); 34 } 35 catch (Exception ex) 36 { 37 lock ((object)777) 38 { 39 LastError = ex.Message; 40 } 41 throw ex; 42 } 43 if (dbLogins.Count < 1) 44 { 45 return LoginResult.WrongLogin; 46 } 47 48 var prevUser = App.CurrentUser; 49 App.CurrentUser = dbLogins[0]; 50 if (password.CompareTo(App.CurrentUser.Password) != 0) 51 { 52 App.CurrentUser = prevUser; 53 return LoginResult.WrongPass; 54 } 55 56 var log = System.IO.File.AppendText(App.LogFile); 57 log.WriteLine("New user loggined. Login=" + App.CurrentUser.Name); 58 59 if (!(bool)((EventService)App.Service).SendWithConfirm(prevUser)) 60 { 61 log.Write("Error sending to user."); 62 } 63 64 GC.Collect(); 65 GC.Collect(); 66 67 return LoginResult.Success; 68 } 69 } 70 } 

त्रुटियां (लाइन नंबर और विवरण जो मुझे आवेदक से सुनने की उम्मीद है):
12 - "त्रुटि" के लिए मूल्य "-1" होगा, जो किसी मौजूदा को डुप्लिकेट करेगा और भविष्य में एक को दूसरे से अलग नहीं होने देगा।
17 (1) - सार्वजनिक क्षेत्र। अच्छे रूप के नियमों द्वारा, खेतों को सार्वजनिक रूप से उपलब्ध कराने की अनुशंसा नहीं की जाती है।
17 (2) - कोड के माध्यम से एक चर के आगे लिखना लॉक के माध्यम से "कार्यान्वित" किया जाता है, लेकिन बाहरी उपभोक्ता को पता नहीं हो सकता है कि चर के लिए कॉल किसी के साथ सिंक्रनाइज़ किया जाना चाहिए।
20 - अर्थहीन टिप्पणियाँ।
२४ - टीका सत्य नहीं है।
28 - सार्वजनिक विधि ने बाहर से मापदंडों को स्वीकार किया, लेकिन उनकी शुद्धता (कम से कम अशक्त) के लिए एक चेक नहीं किया।
32 - मजबूत कनेक्टिविटी।
33 (1) - एसक्यूएल इंजेक्शन का उपयोग करने के लिए संभावित स्थान। चूंकि अनुरोध बनाने के लिए संघनन और मापदंडों का उपयोग नहीं किया जाता है। और दूसरी बात, गैर-पैरामीटर वाले प्रश्नों को सीक्वल सर्वर (यदि DBMS एक अगली कड़ी है) द्वारा कैश नहीं किया जाता है।
33 (2) - क्वेरी पीढ़ी की एक समान शैली "एक विशिष्ट डीबीएमएस के लिए आवेदन" बांधता है)।
33 (3) - इस तरह से कॉन्टेनेटिंग स्ट्रिंग्स सबसे कुशल समाधान नहीं है।
35 - अच्छे फॉर्म के नियमों के अनुसार, आपको उन त्रुटियों को पकड़ना चाहिए जिन्हें संसाधित किया जा सकता है, और एक पंक्ति में सब कुछ नहीं।
37 - यह ताला काम नहीं करेगा।
39 - एक चर में एक अर्थहीन मूल्य और निदान करने में डेवलपर्स को कोई लाभ नहीं।
41 - वर्तमान स्टैक ट्रेस, जो एक त्रुटि का निदान करने में उपयोगी हो सकता है, इस तरह के अपवाद के साथ अनियमित रूप से खो जाता है।
49 (1) - एप्लिकेशन स्टेट का विनाश, यदि कोई त्रुटि कम है (अशक्त पासवर्ड), तो वर्तमान उपयोगकर्ता के पास पहले से ही फ़ील्ड में एक नया लॉगिन होगा।
४ ९ (२) - व्यापारिक तर्क। अन्य लॉगिन क्यों काटें?
50 (1) - पासवर्ड अशक्त के लिए जाँच नहीं किया गया है और एक अपवाद हो सकता है जो एप्लिकेशन स्थिति को नष्ट कर देगा।
50 (2) - पासवर्ड स्पष्ट पाठ में संग्रहीत और उपयोग किया जाता है।
53 - अच्छे फॉर्म के नियमों के अनुसार - प्रमाणीकरण त्रुटि के कारणों के बारे में ऐसी विस्तृत जानकारी नहीं दी जानी चाहिए।
56 (1) - इस तरह के रूप में एक अच्छी तरह से सोचा लॉगिंग तंत्र का अभाव।
56 (2) - एक धारा खुलती है, लेकिन इसके बंद होने और विनाश का प्रदर्शन नहीं किया गया, डेटा को अंतिम फ़ाइल में नहीं लिखा जा सकता है।
56 (3) - फाइलों के साथ काम करने का संचालन एक अपवाद को बढ़ा सकता है, जिसे एक स्तर ऊपर एक प्रमाणीकरण त्रुटि के रूप में व्याख्या की जा सकती है, हालांकि वास्तव में लॉगिन पहले ही पारित हो चुका है।
५ 57 - अर्थहीन जानकारी जो किसी भी तरह से लॉग फाइल विश्लेषक के जीवन को सरल नहीं करेगी अगर यह अचानक बनाया गया है और जिसे भी इसकी आवश्यकता है।
५ ९ (१) - जुड़ा होने के अलावा, नेस्टेड कॉल के साथ "ओवरस्टीमेटेड" वापसी परिणाम के बारे में अपेक्षाएं हैं।
५ ९ (२) - अविश्वासी व्यावसायिक तर्क।
61 - एक अर्थहीन लॉग प्रविष्टि।
64.65 - एप्लिकेशन में एक बड़ी मेमोरी समस्या का संकेत। (मुझे यह भी सुनने की उम्मीद है कि एक पंक्ति में दो कॉल क्यों और वैसे भी ऐसा करने के लायक क्यों नहीं है)

हो सकता है कि किसी ने पहले ही यह तरीका अपना लिया हो और अपना अनुभव साझा कर सके?