Від перекладача
Перед вами переклад публікації з блогу Haney Codes .NET. Автор блогу David Haney працює на позиції Engineering Manager в Stack Overflow. Пару років тому я вже переклав одну статтю його авторства: Плутанина з назвами посад.
Близько місяця тому я виявив себе розмовляючим по відеозв'язку з Joel Spolsky (автор відомого блогу «Joel on Software», співзасновник Stack Overflow - прим. перекл.). Навіть зараз здається абсурдним писати подібне. Довгий час, протягом всієї своєї кар'єри, я регулярно читав Joel Spolsky, і багато в чому сходився з ним у поглядах на розробку. І раптом спілкуюся обличчям до обличчя.
Домогтися цієї розмови було далеко не просто. Процес зайняв кілька тижнів, і, чесно кажучи, було важко знайти час на проходження стількох інтерв'ю. Скількох, запитаєте ви?
До Joel'a я говорив з 5 або 6 інших дивовижних людей (в їх числі Marc Gravell і Nicholas Larsen). Якимось чином мені вдалося справити на кожного з них достатнє враження, щоб дістатися до фінального боса. Розмова тривала близько години, а для мене пролетіла за 5 хвилин - ймовірно, через хвилювання. Ми обговорювали плюси і мінуси різних методологій розробки ПЗ, свої минулі кар'єрні помилки, деякі з проблем Dache (мій кеш з відкритим вихідним кодом), і пару інших тем. Потім Joel сказав щось дивне: «Приєднуйтесь до нас у Stack Exchange!» У той момент я відчув такий сильний виплеск адреналіну, що міг би підняти машину голими руками.
Через кілька днів я офіційно приступив до роботи. Я радий подібній можливості і вважаю, що мені дуже пощастило. До цього моменту, Stack Exchange зарекомендувала себе як неймовірно кваліфікована і професійна організація, яка ставиться до співробітників як до людей, а не як до витратних ресурсів, і я вже встиг полюбити тутешні звичаї спілкування з колегами.
ВАЖЛИВО: Перш за все, позиція - виключно моя, а не компанії Stack Exchange, або третіх осіб. У статті наводяться роздуми щодо процесу інтерв'ю, а також тієї специфіки моїх знань і професійного шляху, які допомогли отримати цю роботу. Це не «зрив покривів», і не полегшує шлях підказка. Якщо ви хочете працювати тут, вам доведеться пройти ті ж випробування (деталі яких я не буду розкривати), що пройшов і я.
З цим застереженням, ось мої думки про те, як я отримав роботу в Stack Exchange, і про те, як це можете виконати ви:
Его - вбивця розуму, так що вбийте его. Більшість розробників (в тому числі, і я - колишній) мають масивний «Я». Їх его настільки велике, що ледь поміщається в кімнаті. Це природно, враховуючи те, що ми цілими днями створюємо речі божественної якості, які приносять солідний дохід буквально з нічого. Ми починаємо відчувати себе дуже могутніми. Досконало вивчивши технологічний стек компанії, ми робимо висновок, що знаємо все про будь-яке ПЗ і «залізо».
Думати, що знаєш все - найпростіший спосіб облажатися як програміст. Вірячи в подібне, ви більше не вивчаєте новинок (ви ж їх вже знаєте). Поки ви майстерно освоїли ASP.NET MVC 3 на поточному місці роботи, вийшли 4-а, а потім 5-а версії фреймворку... ось тільки ваша компанія не зробить апгрейд, тому що це занадто ризиковано, і тому ви ніколи не вивчите нову версію. Через кілька років ви опинитеся так далеко позаду сучасних технологій, що не зможете їх побачити навіть у бінокль. До речі, я згадав ті штуковини - Ruby і PHP, або навіть Java, на яких ви так і не написали жодного рядка? А як щодо MongoDB, Couchbase, Azure, EC2, і тисяч інших платформ і мов програмування? Сподіваюся, тепер ви зрозуміли, що ваші знання про мови та апаратні конфігурації - це крапля в морі... можливо 0,1% від усіх знань про розробку. Стільки ж знаю я, і це нормально.
Не будьте рок-зіркою. Цим я займався протягом декількох років, що тільки зашкодило моїй кар'єрі. Багато компаній навмисне підгодовують его своїх співробітників, щоб ті відчували себе цінними (часто без відповідної оплати). Бути рок-зіркою - звучить здорово, але насправді це ризикована стратегія, яка може зростити неймовірно вибухонебезпечну атмосферу в колективі. Компанії розшукують і наймають рок-зірок, і рок-зірки сприймають це, як належне. Вони роздмухують свої «Я» і сперечаються на зборах, перебиваючи і розштовхуючи інших. Міркують в дусі «я правий, тому що ви не праві, тому що я правий». Рок-зірка переконаний: інші існують, щоб потурати його примхам... у той час, як інші ненавидять працювати з такою людиною.
Справа в тому, що ви насправді можете бути тим самим, одним на мільйон великим розробником, «рок-зіркою» - але всім на це плювати. Слова нічого не варті, і люди скажуть майже все що завгодно, щоб справити на людину потрібне їм враження. Навіть якщо ви дійсно хороші - говорити з людьми тільки про це, і ні про що інше - змусить їх зневажати вас. Хорошому розробнику не потрібно хвалитися, його результати скажуть самі за себе красномовніше будь-яких слів. Природно, що оточуючі оцінять подібну людину. Дозвільні розмови на тему «вау, він дуже розумний» або «вона впоралася за годину, а ми-то думали - це займе кілька днів» будуть міцніти, що не погано. Нехай люди говорять про вас все, що їм заманеться, але збережіть скромність і почуття реалізму. Ви можете бути найкращим розробником в команді або навіть компанії, але ви все ще людина, і ви все ще на роботі. Нікого тут не наймали обслуговувати ваше его (навіть тих, чиї повсякденні обов'язки - робота на вас). Те, що ви хороший розробник - не робить вас кращими, як особистість; це просто робить успішніше вашу кар'єру. Ніколи не забувайте, що тисячі інших розробників також блищать на своїх робочих місцях. З їх загального ряду - зможе виділитися відмінний і скромний розробник. Це дуже рідкісне поєднання з мого досвіду, і межа мрій для найму в багатьох компаніях. Навіть якщо ви самий-самий (що кльово!) з усіх, перестаньте хвалитися оточуючим. Їм все одно, як і вам повинно бути.
Знайте, що ви знаєте достатньо для розуміння обмеженості ваших знань (оригінал know that you know enough to know that you don't know enough - прим. перекл.). Усвідомлюйте, що ви знаєте, а що ні. Ніколи не бійтеся сказати: «я не знаю», коли це правда. Розробник, який не робіє вимовити: «я не знаю» перед повною людей кімнатою - рідкість. Будучи чесним, ви створюєте довіру і авторитет. Ви також розвиваєте позитивні відносини з колегами і компанією. Якщо ви ніколи не чули про Angular.js або Couchbase - ніхто цього не стане запам'ятовувати, але люди завжди будуть вдячні, якщо ви не стали витрачати їх час і гроші.
Знайте свої структури даних та алгоритми. Мови програмування високого рівня, такі як C #, настільки абстрактні, що багато хто з нас не має ні найменшого поняття про те, що ж насправді відбувається «під капотом» при виконанні програми. Це здорово - всюди використовувати LINQ, але чи знаєте ви обчислювальну складність того, що написали? Ви знаєте, що таке хеш-таблиці, і навіщо вони потрібні? Чи можете ви відсортувати масив найбільш ефективним шляхом? А придумати сценарій, де найкращим варіантом є використання стека? Зверніть увагу - вам не потрібно запам'ятовувати речі на зразок алгоритмів сортування (чорт, та я не зміг би, навіть якби спробував), але дуже цінним є знання структур даних: дерева, хеш, списки, черга, стек; у поєднанні з рудиментарними поняттями про сортування, пошук і кешування. Ось відмінність між гарним і чудовим програмістами. Кожен може писати на C #, але тільки розуміє низькорівневу «підноготну» кожного викликаного методу напише хороший, чистий, ефективний код. Вам необхідно фундаментальне розуміння того, як працюють структури даних, такі як стек і купа, як працює адресація за значенням і за посиланням. Ці основні принципи застосовні до ВСІХ мов програмування. Занадто багато розробників ігнорують складність алгоритмів і просто викликають готові методи, не розуміючи наслідків. Вивчіть структури даних і алгоритми, і раптово ви опинитеся попереду зграї.
Знайте, чому ваш код працює і чому ваш код не працює. Ви бачили це зображення з Reddit і йому подібних сайтів?
Нехай ця картинка і смішна, але її популярність мене бісить. Вона заявляє, що суть програмування - не врубуватися, чому ваш код працює або не працює. Як на мене, так це неприпустимо. Чудовий розробник прагне дізнатися ЧОМУ речі працюють так чи інакше, а не тільки ЯК це виправити. Код не компілюється? ЧОМУ? Race condition? ЧОМУ? Ставлячи запитання «чому» ви розширите свій кругозір і набір навичок порівняно з прагматичним «як», що дозволить вам стати кращим програмістом. Більшість великих програмістів не повторюють одні й ті самі помилки знову і знову, хоча вони, звичайно, помиляються... Вони просто роблять нові і цікаві помилки!
Я пам'ятаю дні написання дрянного коду, і подальшого копіювання рядків зі Stack Overflow і йому подібних сайтів - до тих пір, поки код не починав начебто працювати (хоча я не був впевнений, як і чому це сталося). Ці дні залишилися далеко позаду. Коли мій код не компілюється, в 99% випадків я відразу знаю, як вирішити проблему. Коли в моєму коді, як правило, я знаю, як відстежити і виправити його, і при цьому вчуся уникати подібних ситуацій в майбутньому. Не мати ні найменшого поняття, чому ваш код працює - все одно, що бути адвокатом, який не має ні найменшого поняття, чому клієнт не винен: марне, дороге і кумедне видовище одночасно. Переконайтеся, що усвідомлюєте, чому ваш код працює... або не працює. На мій погляд, це основна якість професійного розробника. Створити порожню або зробити помилку - OK, але повторити ту ж помилку кілька разів - не ОК!
Ось я і описав вам свій набір навичок і ключових компетенцій - те, що показав команді Stack Exchange на інтерв'ю. Не на всі технічні питання я зміг дати точну (або оптимальну) відповідь, але я поводився скромно і ніколи не боявся попросити допомоги або сказати «я не знаю», коли в чомусь вагався. У моїх відповідях були ефективні структури даних і алгоритми, і я був в змозі пояснити, чому ось ця конкретна структура - кращий вибір для вирішення проблеми. Зробивши помилку, в більшості випадків я був в змозі це визначити і вказати шляхи виправлення. Показавши свою компетентність і спроможність як розробник, я в підсумку отримав роботу мрії.
