Запыт на рашэнне задачы праграмавання
Кампанія вельмі часта просіць задачы па наборы першага этапу набору. О, вы можаце многае напісаць пра гэта зараз. Шмат разоў я сам выразаў такія задачы, як і многія мае сябры. На мой погляд, прынцып просты:
• калі гэта 30-хвілінная задача (напрыклад, на платформе Codility), вы можаце лёгка вырашыць яе. У мяне ёсць станоўчы досвед працы з такімі задачамі (хутка і эфектыўна).
• калі гэта тэкставае заданне, адпраўленае ў фармаце PDF, якое зойме ў вас некалькі дзён - адкіньце яго.
30-хвілінныя задачы Codility сапраўды могуць паказаць вам, калі вы ведаеце пра праграмаванне. Звычайна яны маюць алгарытмічны характар і складаюцца з напісання адной простай функцыі, якая здабывае дадзеныя і вяртае іх у нейкім фармаце. З такой задачы наконт кандыдата няма чаго зрабіць, але кампанія мае арыенцір і ведае, ці варта запрашаць вас на наступныя этапы.
Больш працяглыя задачы (апісаныя і адпраўленыя ў асобны файл PDF) звычайна займаюць больш часу і складаней. Напрыклад, кампанія можа запатрабаваць напісання прагляду вэб-фатаграфій, простай вэб-сістэмы з аўтарызацыяй і формамі (патрабуецца падключэнне да базы дадзеных альбо выкарыстанне ORM). Вы будзеце марнаваць шмат часу на такую задачу, і, напэўна, хто-небудзь будзе прытрымлівацца вашага рашэння.
Чаму гэта Кампаніі думаюць, што з гэтай задачай яны даведаюцца ваш стыль кадавання і правяраць, ці чысты ваш код. Гэта поўная лухта. Гэтыя задачы займаюць шмат часу, яны могуць дапамагчы напісаць некалькі сяброў адначасова. Акрамя таго, не існуе такога абранага правільнага стылю кадавання. Стыль кадавання залежыць ад дызайну, які вы ўводзіце, і перш за ўсё ад тэхналогіі. Гэта датычыцца і палітыкі чыстага кода. Пры прызыве на новае прадпрыемства вы павінны пісаць праект, як гэта рабілі вашым папярэднікі.
Прыклад з рэальнага жыцця
Калісьці я прысвяціў 4 гадзіны свайго каштоўнага часу, каб вырашыць задачу па наборы. У C # я напісаў клас для разбору дыяпазонаў дат (вельмі спрошчана). Акрамя дыяпазонаў дат, мне давялося падтрымліваць усе магчымыя варыянты разбору, часовыя поясы, фарматы ўводу даты. На мой погляд, код быў абектна-ідэальным, я кіраваўся прынцыпамі SOLID, усе зменныя былі інкапсуляваны ў межах класа. Я нават пахваліўся з калегай па працы - мы абодва сказалі, што зрабіць гэта больш нельга.
Клас, які я пісаў, меў шмат прыватных зменных і адну ўласную ўласнасць. Публічная ўласнасць была запоўнена значэннем па змаўчанні, аднак яна дазволіла праграмісту змяніць спосаб працы класа (разбор даты). Я стварыў гэту ўласнасць як агульнадаступную, таму што лічыў, што гэта павінна быць. Я вырашыў, што ён павінен мець магчымасць змяніць спосаб працы па-за межамі класа.
Праз некалькі дзён я атрымаў адказ: "Усе зменныя ў класе павінны быць прыватнымі, а адна з вамі адкрытай. Гэта дрэнныя практыкі. Аднак, паколькі нам падабаецца рашэнне, калі ласка, выпрамце код і адпраўце яго зноў на разгляд".
Калі я прачытаў гэтае паведамленне, мае рукі апусціліся. "Старэйшы архітэктар" падпісаў яго. Пры праверцы майго кода ён, верагодна, не адрозніваў публічную ўласнасць ад публічнай зменнай. Я хацеў напісаць, што прыватная пераменная існуе, яна будзе створана толькі няяўнае кампілятарам, і спрошчанае прадстаўленне стварэння ўласнасці ў C # на самай справе будзе распрацавана ў два метады: усталяваць і атрымаць. Стварэнне грамадскага сетара не мае нічога агульнага са стварэннем публічнай зменнай ... Аднак я выявіў, што гэта не мае сэнсу. Патраціўшы некалькі гадзін, напісаўшы заданне, я выявіў, што мяне ацэньваюць няўмелыя асобы, якія фактычна адбіваюць мяне ад далейшага найму. Я ветліва падзякаваў і адмовіўся ад прызыву на працу.
Мяккія навыкі
Шчыра кажучы, па маім вопыце, мала кампаній звяртае ўвагу на навыкі мяккага. Гэта звязана з простым фактам: праграміст піша добры код, часам ён таксама праводзіць аналізы. Праграміст часта ўдзельнічае ў размовах з кліентам, але ў канчатковым выніку праграміст не абавязаны мець бездакорны выгляд і прэзентацыю - таму што ён толькі праграміст. Людзі на іншых пасадах павінны прадаць тавар і расказаць пра яго.
Артыкулы і парады наконт важнасці мяккіх навыкаў у нашай прафесіі не адлюстраваны ў маім вопыце. У першую чаргу ацэньваюцца веды і вопыт праграмістаў. Гэта галоўны пераважаючы фактар у поспеху найму праграміста ці не.