Это краткое изложение короткого выступления, которое я сделал людям, желающим проникнуть в технологическую отрасль, на Codebar and Talent2017.
Здесь, в Cogapp, мы хотели бы думать, что мы — то место, где люди хотели бы работать. Но почему? И как вы можете определить, когда ищете работу, что место, куда вы подаете заявление, будет для вас хорошей средой.
Люди часто забывают, что подача заявки на работу — это улица с двусторонним движением: вы не просто ищете место, которое вас примет, но и место, которое соответствует вашим ожиданиям.
Ты
Итак, когда вы устраиваетесь на работу, что вы должны делать? По сути, вы пытаетесь продемонстрировать совпадение навыков с компанией, в которую вы подаете заявку. Если только они не ожидают, что наймут вас и немедленно переобучат, должно быть некоторое совпадение между вашими навыками и тем, что нужно компании. Один из вопросов, который я задаю себе, просматривая чье-то резюме, звучит так: «Что этот человек мог сделать в первый же день?». В конце концов, вам нужно уметь что-то делать, даже если вам нужно некоторое время, чтобы освоиться в остальном.
Таким образом, я думаю, что важной частью является демонстрация этого совпадения навыков.
Одна вещь, которую я хотел бы, чтобы сделали больше людей, и которую мы начали явно просить в некоторых приложениях, — предоставить образец кода своей работы. Это не должно быть обширным, и мы понимаем, что много кода, который люди пишут в рамках своей работы, не является чем-то, что они могут сделать общедоступным, но что-то ориентировочное — это начало.
Таким образом, я бы рекомендовал вам:
Имейте соответствующий код, который вы написали, и о котором вы можете рассказать
В этом есть три части:
Соответствующий код
Кодекс должен иметь отношение к совпадению навыков между вами и вашим потенциальным работодателем, будь то из-за конкретной технологии или просто области, в которой они работают.
Что вы написали
Это звучит как легкая задача, но вы должны были написать код самостоятельно. Использование библиотек и открытого исходного кода — это хорошо, но убедитесь, что существует четкое разграничение между написанным вами кодом и кодом, полученным из других источников. Вы же не хотите произвести неправильное впечатление и в конечном итоге оказаться с яйцом на лице.
О чем вы можете говорить
Это самая интересная часть — есть что обсудить. В конце концов, это отправная точка для разговора о том, как вы подходите к проблемам и создаете технические решения. Вы должны быть в состоянии обосновать решения, которые вы приняли при проектировании и написании этого кода, а также обсудить возможные альтернативные решения.
Итак, как вы это делаете?
GitHub — отличный ресурс для программистов, ищущих работу, и я настоятельно рекомендую добавить несколько соответствующих примеров кода и включить ссылки в свое резюме. Это не обязательно должны быть завершенные проекты, но они должны соответствовать вышеуказанным критериям.
Это может показаться неприятным, учитывая огромные масштабы GitHub и объем кода, который находится в открытом доступе. Что делать, если в вашем коде есть ошибки? Что, если кто-то другой сделал это лучше? Часто кажется, что между программистами существует огромная пропасть в навыках, и хотя в некоторых случаях это правда, я думаю, что она часто преувеличена.
Я бы возложил вину за это на идею 10-кратного программиста, популяризированную Peopleware. Некоторые читатели сообщили об этом, предполагая, что есть программисты в 10 раз более продуктивные, чем большинство из нас, генерирующих коды, когда это не то, что говорится в цитируемом исследовании. На самом деле исследование устанавливает, что:
- Лучший опрошенный программист был в 10 раз более продуктивным, чем худший программист.
- Продуктивность среднего программиста была в 4 раза выше, чем у худшего программиста.
- Лучший программист был в 2,5 раза продуктивнее, чем средний программист.
Так что, если вы не находитесь в самой низкой группе навыков, на самом деле нет большого разрыва между вами и следующим лучшим человеком.
Мягкие навыки
Но что, если вы хотите преодолеть этот разрыв и сделать себя еще более привлекательным?
Я бы сказал, что после того, как вы станете компетентным в программировании, навык, который сделает вас более продуктивным и рентабельным, будет заключаться не в изучении большего количества языков, а в изучении большего количества социальных навыков (здесь я определяю мягкие навыки как все, что напрямую не связано с программированием). написание кода).
Вы можете сказать, что это звучит как ересь, но выслушайте меня. У Стива МакКоннелла есть блестящий график в Code Complete, который иллюстрирует стоимость дефектов в зависимости от того, когда они появляются в проекте. Суть в том, что чем дольше висит дефект, тем больше стоит его исправление.
В этом есть смысл — больше людей проделают работу, основанную на дефекте, поэтому придется повторить или выбросить больше человеко-часов.
График Макконнелла показывает, что после определенного момента программирование — не лучший способ быть эффективным с точки зрения общей стоимости проекта. Конечно, вы можете оттачивать свои способности до тех пор, пока не станете знаменитым суперпрограммистом, и вы никогда не внесете никаких дефектов в свой код, но, глядя на этот график, вы устраните только наименьшую возможную стоимость дефекта — между созданием и обслуживанием.
Более прагматичный подход состоял бы в том, чтобы лучше разбираться в вещах, которые возникают на ранних этапах процесса — улучшать свою способность писать спецификации, оценивать технологическую платформу и доносить прагматичные решения до руководителя проекта. Затем вы можете уменьшить огромное количество дефектов, возникающих на этапах требований и архитектуры, которые являются гораздо более заманчивыми целями для любого бизнеса.
Если бы мне нужно было выбрать некоторые мягкие навыки, которые я хотел бы видеть больше, я бы предложил эти пять:
- Иметь высокую планку качества
- (Знайте, как) протестировать свой собственный код
- Будьте открыты (но опасайтесь) новых вещей
- Знайте, когда просить о помощи
- Знай, чего ты не знаешь
Компания
Другая сторона трудовой сделки — оценка вашего потенциального работодателя. После того, как вы провели базовую комплексную проверку (прочитали их веб-сайт, провели некоторые предварительные исследования), как вы можете выяснить, насколько хороша компания на самом деле?
Одним из способов является наличие набора объективных измерений. Тест Джоэла — это эффективный набор быстрых и грязных метрик для оценки технических процессов и среды компании. Должен сказать, что я не согласен на 100% с этим (особенно с эффективностью написания кода на собеседовании как показателем технических способностей), но это хорошее начало.
Один вопрос, который я всегда советую задать в конце интервью, звучит так:
Как бы выглядел обычный день/неделя, если бы я начал работать здесь?
Это преследует двоякую цель: во-первых, это должно дать вам более точное представление о том, чего компания на самом деле ожидает от вас как от сотрудника. Часто объявления о работе не очень хорошо отражают реальность роли, поэтому у вашего интервьюера (который, как мы надеемся, будет работать близко к вашей предполагаемой роли) есть возможность уточнить.
Во-вторых, вы можете сравнить их ожидания со своими. В конце концов, не у всех идеальная работа выглядит одинаково.
Конец
Надеюсь, это вдохновило вас на поиск идеальной технической работы. Иногда это может быть немного утомительно (как найти правильную роль, так и найти подходящего кандидата), и я надеюсь, что реализация некоторых из них облегчит жизнь людям по обе стороны стола.
Кстати, Cogapp — довольно приятное место для работы, и мы используем систему контроля версий и все такое. Мы также ищем вакансию младшего технического специалиста прямо сейчас, поэтому, если это звучит так, пожалуйста, свяжитесь с нами (даже если у вас не так много кода на GitHub, чтобы показать нам).
Удачи!
