У меня был 12-месячный контракт (я живу в стране, где это не обычно для новых разработчиков), пока пару недель назад руководство моей компании не предложило мне предложение и повышение, чтобы стать для них постоянным сотрудником. Мне нравится постоянно обновлять свое резюме (особенно учитывая COVID), поэтому я гуглил вокруг, перечисляя его в своем резюме.
Совет, который я нашел, заключался в том, что я обычно должен перечислить, какое достижение вызвало наем. Справедливо.
Проблема в том, что достижение всегда достигало жестких сроков клиента, и, честно говоря, я сделал это, решив, что проектирование может быть менее звездным в целевых случаях (что руководство согласилось).
Я относительно младший разработчик в команде из 6 разработчиков. Тем не менее, я быстро стал одним из тех, кому руководство devs доверяет больше всего, чтобы доставлять вещи, когда я говорю, что доставлю их и буду информировать их об относительных компромиссах в получении. За мое, по общему признанию, короткое время здесь я всегда мог отправить что-то, когда я сказал, что могу отправить это.
У меня было несколько подобных случаев, но это тот случай, который я сделал перед тем, как мне предложили постоянную работу. Одним из наших продуктов является пакетный API, который вызывается один раз в день одним клиентом. Не нужно ничего возвращать, кроме CSV неудачных записей по электронной почте. Они хотели добавить новую функцию, и продавец согласился получить ее для них к концу месяца. По разным причинам этот запрос на использование не доходил до нас до понедельника последней недели месяца.
Старший разработчик сказал менеджеру, что разработка не может быть выполнена должным образом, и сказал клиенту, что это невозможно. Я не противоречу старшим разработчикам на совещаниях по планированию спринта, но, возможно, было очевидно, что я не согласен со старшим парнем. Мол, не согласен, но вариант существовал с определенными компромиссами. Другие разработчики также довольно пассивны, поэтому никто больше не противоречил ему. Менеджер не был доволен этим, так как клиент уже злится на нас за то, что мы не доставили, когда мы обещаем это сделать. Затем менеджер вызвал меня в свой офис после встречи, чтобы спросить, видел ли я альтернативу. Я сказал ему, что могу заставить что-то работать, но это, вероятно, удвоит время обработки API (что добавит 4 минуты), поскольку у меня нет специальных навыков SQL. Менеджер согласился, и, видимо, клиент даже не заметил.
Я не уверен, каковы были бы последствия пропуска крайнего срока, но они были достаточно крутыми, чтобы генеральный директор нашей компании из 1000 человек отправил мне благодарственное письмо за его доставку.
Другой случай не привлек столько внимания, но был процесс, который нам нужен для запуска базы данных. Правильный способ сделать это - написать надлежащий пакетный процесс в мега-системе Java, которую мы используем, отправить его через все обычные процессы QA и позволить ему выйти в конце через две недели. Я предложил менеджеру скрипт Python, который нужно будет запускать вручную и который будет ужасно неэффективным (при необходимости запускать его в одночасье), но при запуске один раз в месяц проблема будет сохраняться до тех пор, пока не будет достигнуто постоянное исправление. Это была проблема производства, поэтому он согласился с этим в качестве временной меры. Это был в основном просто дешевый цикл, который проверял строки для определенного типа ошибочных данных и переформатировал их.
Есть ли способ перечислить эти типы вещей в моем резюме, который не делает меня похожим на хакерского программиста, который подрывает старших разработчиков? Я признаю, что мои решения технически не обоснованы, но в то время они были разумными для нужд бизнеса, и в большинстве случаев неэффективный компромисс в значительной степени не имел значения.
Вы нашли несколько эффективных (неэффективных) способов решения проблем без их чрезмерной инженерии и «Готово лучше, чем идеально»
Поиск достаточно хорошего решения - важная способность для инженера, так как в противном случае вы бы потратили много времени на оптимизацию чего-то, что не стоит оптимизировать. Если что-то используется не часто, часто не стоит его оптимизировать. Есть хороший XKCD-Comic с таблицей, которая говорит вам, сколько времени вы должны инвестировать в что-то.
Решение чего-то стоит только в том случае, если оно используется (или может быть использовано), поэтому с помощью взлома вы позволили клиенту продолжать работать, пока у вас не будет решения.
Нет причин говорить кому-либо, что вы не согласны со своим руководителем. Просто зайдите на что-то вроде «Способен производить эффективные решения под давлением времени».
Я признаю, что мои решения технически не обоснованы, но они были звук для потребностей бизнеса в то время и неэффективности торговли в большинстве случаев это не имеет значения.
У вас была одна работа: «найти решение, которое работает в сроки, которые решают работу». И это именно то, что вы сделали.
У меня такое ощущение, что только руководство дает ответы здесь, потому что не было ничего, кроме похвалы за соблюдение необоснованных сроков.
Здесь есть другая точка зрения. Не стоит недооценивать социальные волнения, которые вы зажигаете в команде разработчиков, когда руководство сокращает углы и игнорирует мнение старших разработчиков. Есть поговорка, которая звучит примерно так:
Пока есть кто-то, кто постоянно гасит огонь, руководство не прекращает играть со спичками.
Одно дело, если вы один / два раза идете по изворотливой дороге, потому что вы вынуждены это делать, но совершенно другое, если оно становится нормой. И из вашего описания мне кажется, что менеджменту стало вполне комфортно с практикой использования вас для срезания углов. Вы должны серьезно рассмотреть вопрос о том, чтобы поднять этот вопрос перед вашим руководством и старшими разработчиками, чтобы поддерживать здоровую рабочую среду. Компания - это баланс между разработчиком и руководством, а не просто нисходящая структура. Есть причина, по которой слово «нет» существует, и вы должны практиковать его использование.
Тем не менее, это все еще больше проблема управления, чем ваша. Следовательно, нет причин как-то упоминать об этом в своем резюме. Так что я бы согласился с:
способен уложиться в сроки
Как говорится, «Идеально - враг добра» - идти на технические компромиссы для удовлетворения потребностей бизнеса - это в значительной степени de rigueur. Хорошие разработчики / программисты / инженеры - это те, кто может определить приемлемые компромиссы, которые могут быть сделаны.
В вашем примере API клиент явно был более готов принять 4-минутную задержку в обработке чего-то, что работало и доставлялось вовремя.
В идеале вы должны стремиться минимизировать технический долг при достижении этих компромиссов - но это 'Это неотъемлемая часть опыта и знание того, где можно побриться и когда нужно убедиться, что что-то сделано &"правильно &" чтобы сэкономить больше времени в долгосрочной перспективе.
Мой фундаментальный вопрос заключается в том, есть ли способ перечислить эти типы вещей в моем резюме, который не делает меня похожим на хакерского программиста, который подрывает старших разработчиков?
Когда оно превысит ваше резюме, вам не нужно вдаваться в подробности вашего решения - вы можете просто сказать, что у вас есть хороший послужной список выполнения срочных проектов с учетом времени, и привести примеры без подробностей фактической реализации.
То, что вы делаете, это НЕ «взлом», это «поиск решений».
Я работаю разработчиком и консультантом уже 20 лет, и этот навык - это то, что ищут работодатели: не оставляйте его в своем резюме, но подчеркивайте именно это: вы пытаетесь найти решения, даже если это означает идти "необычные" пути.
Не пишите, что вы делаете это за спиной старших разработчиков, но делаете это всякий раз, когда вас просят о решениях, даже если более опытные парни не согласны / говорят, что это невозможно.
Говорят, что есть отличная цитата из Альберта Эйнштейна, которая точно описывает вашу ситуацию
Все знали, что это невозможно, пока не появился дурак, который не знал, и сделал это.
Я работал вместе со многими разработчиками, и я знаю все аспекты этого:
Я работал с разработчиком, который входит в число 1% лучших экспертов по JavaScript в стековерфле. Он гений, и я действительно восхищаюсь каждой строкой кода, которую он пишет. Но довольно часто он не заканчивал свои проекты: он предпочел бы не закончить что-то, чем закончить это, когда он не был удовлетворен красотой кода.
И я работал с разработчиками, которые были чрезвычайно эффективными, но поэтому использовал много ярлыков, которые делали решения практически недоступными (жестко закодированные пути, магические числа и т. Д.).).
И я всегда предпочитал «сделано», а не «красиво», и, в конце концов, мои клиенты тоже: они предпочли бы «что-то», когда наступит крайний срок, чем «ничего, но будет прекрасно через некоторое время X»
Только одно: обходные пути / ярлыки / «хаки» должны быть понятными, документированными и исправными, тогда нет ничего против таких решений, как вы
Звучит как нормальный технический долг для меня. Старший, вероятно, был старше и измучен и не хотел больше увеличивать долг перед уже перегруженным проектом (немного похоже на меня, на самом деле я бы отодвинул это). Или, может быть, они просто пытались защитить команду. Давайте посмотрим на ваш вопрос прямо, хотя:
есть ли способ перечислить эти типы вещей в моем резюме, что нет заставь меня выглядеть как хакерский программист, который подрывает старших разработчиков?
Может быть, я здесь наивен, но вы не должны перечислять подобные вещи в своем резюме. Только общие достижения, так что, если это норма для этой компании, это будет то, что вы &"работал в сжатые сроки, чтобы предоставить решения клиентам и клиентам; вместо подробностей о том, как вы создали хранимую процедуру или две за несколько дней, чтобы сделать что-то, что работает для клиента. Если я прочитаю резюме, в котором говорится, что вы выполняете в сжатые сроки, я пойму суть, сказал Нуфф.
Это все, что вы должны добавить в свое резюме, даже тогда, когда я буду держать его в покое, вы работали на Blah Inc как разработчик, работающий с SQL и другими технологиями. Почему это даже должно быть в вашем резюме.
Вы описываете технический долг, и технический долг не всегда плох. Аналогия долга распространяется на множество законных причин, по которым компания берет на себя финансовый долг. Ключ в том, что это намеренно, и есть реалистичный план, чтобы погасить его. Мартин Фаулер много писал об этом, особенно о том, что он называет техническим долговым квадрантом:
Похоже, вы приняли разумное решение относительно технического долга. Признание того, где технический долг разумен, и знание того, как им управлять, являются чрезвычайно ценными навыками.
Должен сказать, я бы не хотел вас нанимать, и это не потому, что вы сделали компромиссы. Это важная часть работы и сложный навык для приобретения. Это потому, что вы сделали слепые компромиссы без использования опыта остальной части вашей команды.
Изучение потенциальных проектов не «противоречит» старшему разработчику. Разговор должен был идти примерно так:
Вы: Что если бы мы сделали X?
Старший разработчик: Это, вероятно, удвоит время обработки. Я не думаю, что клиент будет доволен этим.
ПМ: На самом деле, я думаю, что они предпочли бы это медленно, чем вообще не делать. Я свяжусь с ними, чтобы убедиться.
Другой младший: Боб много знает о SQL. Если мы сможем заставить его помочь, я Держу пари, он мог бы сократить много времени.
Старший разработчик: Но я все еще обеспокоен угловым делом Y. Это займет некоторое время, чтобы проверить это правильно. Это было бы очень неловко, если мы ошиблись.
ПМ: я согласен. Если вы работаете над тестированием, и OP работал с Бобом измените API, как он сказал, можно ли это сделать?
Старший разработчик: Я так думаю, что в срок, но я бы хотел вернуться и уберите это для следующего выпуска. В противном случае мы рискуем головной болью при обслуживании Y каждый раз, когда клиент делает это.
ПМ: Хорошо.
Кроме того, эти вещи приходят на собеседования. Интервьюер видит что-то вроде «признанного для совершения компромиссов, чтобы приносить пользу в сжатые сроки», и спрашивает пример, затем он отвечает, задавая почти те же вопросы, что и ваш старший разработчик.
Я оставлю вопрос "Ваше резюме - правильное место для этой истории?"в одну сторону. Возможно, в резюме нет места для таких деталей, но, скажем, это может произойти в интервью, и вы хотите подумать о том, как представить его в лучшем свете. В любом случае, даже если никто не говорит об этом снова, стоит подумать о последствиях для вашего собственного профессионального развития. Теперь, вот одно замечание, которое я бы предложил, уместно, о котором никто не упомянул:
У тебя все еще есть работа.
Вы смотрите, как лучше представить историю, но также имеете честь иметь возможность изменить историю.
Итак, вы сделали суждение и рискнули. Благодаря этому вам удалось достичь крайнего срока с полной наблюдаемой функциональностью, удовлетворить клиента и произвести впечатление на ваших менеджеров. Из-за этого вы также поставили решение с более высокими, чем необходимо, затратами на исполнение, потенциально скомпрометировали дизайн кодовой базы и смутили руководителей вашей команды. Это разумный призыв к суждению. Другие уже объяснили, как представить это: вы полностью исключаете конфликт внутри команды из истории, вы явно указываете технические проблемы с вашим решением, которое вы распознали, вместе с осознанием деловой реальности, и вы объясняете, что сделали вызов.
Но если бы вы могли рассказать лучшую историю, это включало бы как взятие, так и погашение этого долга. Это будет включать в себя немного времени для проверки, теперь крайний срок не приближается, возможно, чтобы лучше инкапсулировать код и добавить несколько ключевых тестов. Это может означать сбрить две дополнительные четыре минуты, возможно, проконсультируясь с вашим местным экспертом по SQL. Это будет включать поиск способов любезно поделиться кредитом с остальной частью вашей команды.
Если вы не хотите иметь репутацию парня, который быстро двигается и ломает вещи, оцените технические, деловые и межличностные беспорядки, которые ваши решения (включая жесткие, но очень разумные решения) принимают, и возьмите на себя ответственность за их устранение.
У тебя все еще есть работа.
Проблема в том, что достижение всегда доставляло на узкого клиента сроки и, честно говоря, я сделал это, решив, что инженер может быть менее звездным в целевых случаях (что руководство согласилось).
Я не уверен, какие последствия пропущенного срока будут иметь были, но они были достаточно крутыми, чтобы генеральный директор наших 1000 человек Компания отправила мне благодарственное письмо за доставку.
Есть ли способ перечислить эти типы вещей в моем резюме, который не делает заставь меня выглядеть как хакерский программист, который подрывает старших разработчиков?
Ваше резюме должно подчеркнуть достижение "... доставлен в сжатые сроки клиента и получил благодарственное письмо от генерального директора ".
То, как вы туда попали, может или не может появиться в обстановке интервью, но оно не относится к резюме.
Иногда бизнес-решение требует оперативности. По личному опыту я могу сказать, что менеджеры ценят людей, которые могут найти способ добиться важных целей.
Таким образом, вы создали программное обеспечение, для запуска которого потребовалось четыре минуты (потому что ваш код был не очень хорошим). Если мне потребуется 12 часов, чтобы выполнить работу вручную, ваше программное обеспечение экономит мне 11 часов 56 минут. Если вы написали лучший код, который работает за 1 секунду, это сэкономит мне 11 часов, 59 минут, 59 секунд. Если лучший код был доставлен через неделю, поэтому мне пришлось выполнять работу вручную пять раз, дополнительные 3 минуты 59 секунд никогда не компенсируют потерянное время.
Или сделать это более экстремальным. Программное обеспечение должно работать через 24 часа. Ваш код плохой, поэтому нам нужен компьютер за 5000 долларов, чтобы запустить его за 24 часа. С лучшим кодом компьютер за 2000 долларов может запустить его за 24 часа. Экономия 3000 долларов. Если для ускорения работы кода потребуется две недели, это общая потеря.
Способность доставлять, когда это необходимо, очень, очень хорошая вещь. Кроме того, очень хороший разработчик может написать плохой код таким образом, чтобы его можно было легко улучшить позже. Плохие разработчики пишут плохой код, который трудно преобразовать в хорошую форму, хорошие разработчики под давлением времени пишут плохой код, который легко улучшить.
< удар > проблема в том, < / удар > < b > < i > достижение (!) < / i > был < / b > всегда с соблюдением жестких сроков клиента и < strike > frankly, < / strike > < b > решив, что инженерное дело может быть менее звездным в целевых случаях < b > (на что руководство согласилось).& Лт; / B >
А также ...(!)
< i > < b > "Чувак....!!!"< / b > я хочу нанять < b > < i > you!!!< / i > < / b >Я не уверен, каковы были бы последствия пропуска крайнего срока, но они были достаточно крутыми, чтобы < b > < i > генеральный директор нашей компании из 1000 человек < / i > отправил спасибо по электронной почте < i > мне (!) < / i > < / b > для доставки.
если вы не станете консультантом по управлению в первую очередь...
Очень просто, вам нужно ... прежде всего ... признать, что вы стали исключительными, " тяжелой работой ваших собственных рук - и что вы были очень правильно признаны за это. В своих резюме вы должны подчеркнуть те качества, которые вы только что изложили в своем оригинальном посте.
Перефразируя Эйнштейна,
Качество программного обеспечения должно быть как можно ниже, но не ниже.
Я знаю, что есть много разработчиков, которые гордятся кодом, который они пишут, и категорически не согласны с этим. Но с точки зрения бизнеса, как только цель качества программного обеспечения достигнута, дальнейшее улучшение качества сводится к дополнительной работе, потраченной на то, что вас не просили или за что вам платят. Абсолютное качество просто недоступно: независимо от того, насколько хорошо ваше программное обеспечение, всегда есть возможности для улучшения.
Понятно, что вас не хвалили за падение качества кода. Вас похвалили за поддержание приемлемого качества кода при соблюдении крайнего срока. Вот как вы должны сформулировать это в своем резюме .
У меня нет особого мнения о том, что поставить в ваше резюме для этого, хотя я склонен согласиться с ответами, которые говорят, что подобные вещи на самом деле не вписываются в резюме.
Однако я хотел бы указать, что произойдет, если я буду брать у вас интервью, а вы описали ситуацию так же, как и в вопросе.
Моя первая мысль была бы: «Хорошо, мне нравится кто-то, кто может делать то, что необходимо в краткосрочной перспективе, признавая компромиссы, которые он делает.«Но есть и довольно четко идентифицируемая проблема в управлении вашей компанией своими программными проектами, которую я бы попросил вас идентифицировать.
Ответ, который я хотел бы услышать, заключается в том, что кто-то, не входящий в техническую команду, обещал что-то клиенту к определенному сроку без оценки технической команды, когда это может быть доставлено. Это рецепт долгосрочной катастрофы. Если бы вы не смогли выявить такую проблему, я бы очень опасался, что вы в моей команде.
Кроме того, после того, как проблема выявлена, кто-то должен внедрить долгосрочные исправления, чтобы убедиться, что проблема постепенно уменьшается и, в идеале, в конечном итоге устраняется. Я бы спросил вас, что вы сделали в своей новой управленческой роли, чтобы это произошло. Если бы вы не смогли дать хороший ответ на этот вопрос, я бы очень опасался вас нанимать. Взять на себя ответственность за дорогостоящие краткосрочные исправления - это здорово, но если вы и № 39;не брать на себя ответственность за долгосрочные исправления, которые устраняют необходимость в этих дорогостоящих краткосрочных исправлениях, и сэкономить время и деньги компании в целом, I 'Я считаю, что вы подходите только для младшей роли, пока не научитесь это делать.