Как стать автором
Обновить
25
0

Software engineer

Отправить сообщение
Во-первых, вы опять как-то странно читаете (понимаете/додумываете?) мои комментарии. Я намеренно указываю на «длинные» тестовые задания (т.к. изначальный комментарий был про них, как и мои ответы). Соответственно, фраза «человека который утверждает что тестирования быть не должно» — это не моя фраза, и никак не следует из моих рассуждений. Моя позиция достаточно проста — она про «длинные» тестовые задания (пол дня и более).

Во-вторых, потеря времени может быть совершенно разной. Так можно договориться, что, если компания развалилась через год, то вы потеряли год времени. Но это немного не то.
Одно дело, когда вы не подошли друг другу на этапе собеседований — у вас есть возможность поспрашивать кучу вопросов, узнать много нового о внутренней кухне компании, побывать в новом месте, в конце концов (чаще всего перелет/отель оплачивают). И даже, если вы (или компания) решили не работать совместно, то опыт всё равно полезный, и, самое главное, вы (и компания) четко понимаете, почему вы не пошли дальше.
Другое дело, когда вы потратили те же пол дня — день, но на тестовое задание. Тут, вы очень сильно рискуете в итоге не получить ничего — ни фидбека, ни новых знаний о компании и ее процессах, ни опыта (мы тут считаем, что делать/доделывать/исправлять проекты вы итак умеете).

Есть просто некоторый набор звоночков, которые говорят о том, что лучше «сбросить карты» и не продолжать. Не знаю, есть ли для вас такие звоночки, или вы всегда соглашаетесь на все этапы приема на работу, не смотря ни на что. Но, лично для меня, такой набор есть, и мне проще потерять незначительный процент компаний, но не потерять время/нервы впустую.

В целом, ваша позиция тоже может быть правильной, кто знает. Не думаю, что мы сможем тут решить, кто «правее», но, в любом случае, спасибо за диалог, всегда интересно послушать другую точку зрения.
Вы всё делаете правильно! Я бы сам заблуждался, если бы вы не написали, спасибо)
Хм, в изначальном комменте человек писал
Задание, к слову, на полдня.

Если это ошибка, то тогда, конечно, никаких вопросов к таким тестовым нет. Я говорил только о таких длинных тестовых заданиях.
Вы путаете теплое с мягким. Одно дело тратить время на выбор хорошей компании, другое дело тратить его впустую.

Понятно, что у всех (хорошо, большинства) разработчиков нет никакой проблемы с финансовой подушкой, и они запросто могут уйти в свободное плаванье/поиск работы на несколько месяцев, а то и навсегда. Но это же совершенно не означает, что хочется тратить это время на бесполезные тесты/общение со странными командами и прочее. Со временем понимаешь, что есть некоторые нормы приличия. Если мне скажут, что чтобы попасть на работу надо пробежать полумарафон, то я откажусь, просто потому что, скорее всего, и к работе у них отношение странное, если у них такие тестовые задания. А не потому, что мне сложно его пробежать или нет времени. Также и с тестовыми. Мой опыт говорит о том, что проще игнорировать компании с большими тестовыми заданиями (тут я еще раз подчеркиваю слово «большие»/«длинные» — т.к. если вас просят сделать быстренькую задачку на 30-60 минут это совсем не то же самое, что доработать проект на пол дня и более). Ну и главное, рынок (хотя бы та часть, которую я вижу), говорит мне, что такой подход работает, т.к. большинство серьезных контор его используют.
Не знаю даже какого рода пруфы вам необходимы. Опыт сугубо американский, штат Калифорния. Компании из топа (в том числе описанные вами). Процесс занимает обычно 1 (максимум 2) дня с кучей интервью, но без тестовых заданий на дом (как я и описал в пред комменте). Времени тратится много, но вы сразу понимаете с чем имеете дело, и как на это реагируют. Если у вас не релевантный опыт, то после первого интервью с вами попрощаются. Если же релевантный, то вы вживую сможете узнать о всех проблемах. С тестовыми заданиями всё гораздо хуже (собственно, как у изначального коммента). У меня такой опыт тоже был, по убитию горы времени без фидбека.

Ну и никакх психологических тестов вам, конечно, проходить не нужно.

тестовое задание честнее и лучше показывает адекватность кандидата.

Это абсолютно не так, не знаю, каким образом вы прочитали мой коммент. Длинное или короткое обычно оговаривается перед заданием. Ни разу не встречал, чтобы не говорили временные рамки.
Я понял вашу позицию, она мне не близка.
Если вкратце, то я ценю своё время и оно, к сожалению, очень ограничено, чтобы тратить на длинные тестовые (тут была речь про пол дня и более) или, тем более, на психологические/iq тесты. Большинство знакомых хороших специалистов также считает (особенно после пары таких потерь).

Если поподробнее, то процесс найма — не абстрактная сущность. Если в процессе найма есть звоночки, то, скорее всего, и на самой работе это отразится. Поэтому, проще сразу попрощаться, чем терять время и нервы. Конечно, есть исключения, но, слава богу компаний много, и если какая-то одна хорошая попадет в этот список — то жаль, но не критично.

То есть вам лишь бы кого взять? Или как вы собираетесь отсеивать самозванцев и хвастунов?

Длинное тестовое не отсеивает лучше интервью. Как минимум, 2-4 технических/архитектурных интервью, на мой взгляд, это делают не хуже (но, признаться, тоже плохо). Поэтому, если рынок считает (тут, конечно, вопрос насколько наши HR квалифицированы в вопросе рынка, но у меня нет причин им недоверять), что несколько интервью это ок, а длинное тестовое — нет, то я не против использовать этот способ.

Но в целом, весь мой комментарий был к процитированной фразе. То, что вы пишите про «большинство серьезных контор с интересным стеком...» просто не правда. Большинство серьезных контор (как минимум из топ тех компаний с мировым именем) такой подход уже не используют.
Дело ваше, но большинство серьезных контор с интересным стеком и задачами и профессиональными командами, скорее всего таки попросят выполнить задание не на 5 минут.

Интересно, а гугл или фб — это серьезные конторы с интересным стеком?

Мне вот как раз кажется, что большинство серьезных контор не просят таким заниматься в последнее время. Раньше была мода на тестовые задания, но сейчас многие хорошие разработчики обходят такие тестовые стороной. Поэтому, например, когда я пытался добавить такую интересную задачку к нам на отбор, мне HRы сказали, что мы слишком много кандидатов потеряем и не стали так делать.
>Вы описываете случай когда новые знания/техники либо не появляются…
Ни в коем случае такого не описывал. Конечно, есть время на обучение, думаю, на любом более-менее крупном проекте. Вопрос же в другом. Если проект переходит на другой язык/фреймворк, то заложенного времени на обучение (которое обычно редко превосходит нескольких часов в неделю) вам будет недостаточно, и, конечно, компания должна выделять отдельное время на переходный этап и тут вопросов нет.

С другой стороны, если вам нужно гораздо больше времени из-за того, что каким-то чудом вы прошли собеседование без фундаментальных знаний, которые, как предпологается, есть на вашем уровне (мой изначальный пример с асинхронностью/многопоточностью, думаю, отлично подходит для сениор разработчика). В таком случае, на мой взгляд, вам следует тратить свое личное время на восполнение данных пробелов. Конечно, это всё очень зыбко, и где точная грань неизвестно. Я лишь высказал в своем изначальном комментарии, что есть случаи, когда вполне логично закрывать свои пробелы в знаниях самостоятельно, а не за счет компании.
Но она же все равно показывает, что кол-во запросов от линукс пользователей еще больше чем от osx? В смысле, если 2% пользователей линукса генерят 30% саппорт реквестов, то 4% (сколько osx) генерило бы 60%? Или я тоже не правильно понимаю эти графики?
Конкретно применимо к статье — да, это различные технологии, про которые я и писал, что должно выделяться рабочее время. Но как вы и пишите, есть часть квалификации/уровня, которая дб у работника, и если ее нет — то это задача работника закрыть этот пробел. Можно, конечно, рассуждать, что его же уже наняли, и это проблема найма, но по факту, невозможно всё проверить на собеседовании (даже в 5-7 этапов, как в больших компаниях). И если это присутствует в списке обязательных знаний, то, на мой взгляд, конечно, необходимо устранять эти пробелы уже в не рабочее время. Это обратная сторона — когда люди хотят рабочее время тратить на подтягивание скиллов, которые у них уже должны быть.
Возможно, выскажу не популярное мнение, но мне кажется, что это сильно зависит от конкретных проблем. Если проект переходит на новую технологию или нужно начать использовать новый api, то, конечно, это проблема менеджера, чтобы выделить рабочее время на обучение.
Но, если, допустим, вас взяли на позицию синьора, вы работали пол года, потом вам попала задача с немного другим функцоналом (допустим, раньше не было задач на асинхронность, а тут появилась), и вы говорите, что не знаете темы, то, кажется, что это ваша проблема, и вам придется тратить своё время, чтобы восполнить ваш пробел. Ну или грейд понижать, не знаю.
Вот очень печально, что у людей за стойкой так много прав. Мне, например, тот же оператор без проблем поменял симку, хотя она оформлена на мать. Я тогда порадовался, что всё получилось сделать одному, а после прочтения подобных статей, как-то не по себе.
А не придется в этом случае заплатить еще налог 13% потом, если этот курс оказался выше курса ЦБ?
Думаю, всё просто сильно зависит от размера продукта. Когда продукт разрабатывают тысячи разработчиков, то им приходится соблюдать архитектурные гайдлайны, вводить некоторые практики и т.п. Но потом многие небольшие проекты начинают использовать эти слишком сложные инструменты (как например, «микросервисность в каждый дом» или «фабрика на каждую ответственность»), и в итоге получают необходимость в поддержки этой сложной инфраструктуры. Но потом опять появляются разумные люди, вспоминают про KISS и говорят, что пора вернуться собственно к проблеме вместо использования всех хайповых практик — и появляется новая хорошая статья.
Ага, разработка скорее ходьба!
Если без шуток, то я уже понял, что многим отсылка к марафонам не понравилась, ничего страшного (если не считать подслитой кармы, но это тоже не страшно, пока еще есть). Эти сравнения были намерено усилены, но, возможно, мне не хватило писательского таланта, чтобы подобрать правильные метафоры. Вообще, статья изначально задумывалась как максимально спорная, чтобы породить обсуждение в комментариях, но не удалось.
Извиняюсь за долгий ответ, не было возможности ответить.
По первому. Абсолютно согласен, что главной причиной выгорания является плохой менеджмент. Данная заметка (специально называл ее в рамках всего текста именно так, а не статьей) использует некоторую гиперболизацию из-за того, что вижу очень много команд/компаний, которые используют спринты (да и agile в целом) как некоторую панацею от всех бед. В итоге, неправильное использование инструментов порождает выгорание и прочие проблемы. Марафон используется как противопоставление, что очень часто погоня за стори поинтами в спринтах несет большие проблемы на длинных дистанциях. Но, безусловно, истоки всего этого в неправильном менеджменте, да.

Про образование. К сожалению, погоня за золотой медалью и красным диплом достаточно частое явление. И, по моему скромному опыту, у таких людей бывают очень большие проблемы дальше по жизни. Но во времена школы/университета всем ставят их в пример, тем самым понижая самооценку других учеников. К сожалению, как вы называете, «достаточная» оценка, является достаточной далеко не для всех родителей (которые уже в свою очередь влияют на своих детей). Безуловно, можно сказать, что это проблемы не системы погони за золотой медалью (и откровенном вытягивании таких учеников), а в неправильном воспитании. Но, на мой взгляд, систему всегда менять правильнее, если это может улучшить жизнь большинства людей.

На самом деле, про образование (и воспитание) можно говорить часами, очень интересная тема, которая, как мне кажется, должна существенно модифицироваться в ближайшем будущем.
То есть, вы действительно считаете, что зубрежка различных точных дат и формул чем-то помогает? Именно как багаж знаний, а не как стимулирование мозга, тренировка памяти и прочее.

P.S. в любом случае, спасибо за комментарий, всегда интересно послушать другую точку зрения. В спорах, как известно, рождается истина.
Ух, как много понаписали. Постараюсь ответить.
Про образование. Совершенно не согласен. Точнее, ваши идеи имеют что-то близкое с правдой, но основная цель образования — дать общее представление о мире и его связях. То, что устаревшее пост-советское образование до сих пор затачивается на фактах, вместо того, чтобы раскрывать смысл вещей — это его главная проблема. То, о чем вы говорите — стимулирование мозговой деятельности, улучшение нейронных связей. Этого можно достичь куда более простыми способами, нежели учить дату ледового побоища. Как пример, можно посмотреть на европейское (скажу только за Германию, правда) и американское образование. Они далеко ушли от запоминания формул и дат. Там, конечно, тоже много проблем, но это уже совсем другая история.

Про здоровье.
Я говорил как раз про болезни. Болезни всё равно будут случаться, сколько не «профилактируй». И быстрые антибиотики — это плохой выход. Также, я подчеркнул хронические заболевания (о чем могу говорить с большим опытом). Их лечение (именно лечение, а не профилактика) обычно растягивается на много лет. Но подойти к этому — ох как сложно. Всегда хочется просто принять пилюлю.

Про проект.
Также, категорически не согласен. В марафоне вы не видите финиш и слабо представляете где он будет. Вы только знаете, что рано или поздно, он будет. Также, и в жизни — финиш будет, только никто не знает, как далеко. Горизонт планирования — это что-то сбоку, не пересекающиеся с исходной мыслью. Да, безусловно, важно уметь планировать на разные промежутки, планы весьма серьезно помогают двигаться к цели, позволяют держать мотивацию, но это совершенно другая история.

Собственно, в одном соглашусь, проект похож на жизнь. Только короче. И основная стадия проекта (после всех апробаций и выхода на рынок) — это марафон. Долгий и мучительный. И к нему надо готовиться, если вы хотите не выгорать в длинных enterprise проектах.
Спасибо!

Честно признаюсь, мне сразу понятно не было. Сам ходил восхищенно пересказывая скрам-мастеров, и воспринимая это, как волшебную пилюлю. Но всё приходит с опытом. Теперь понятно, что есть просто огромное количество разнообразных инструментов, и нужно обдуманно понимать, когда и что можно применять.
И по поводу корпоративной культуры. Как раз ценятся именно те менеджеры, которые умеют находить подход к своим подчиненным. Если интересно, на сколько сейчас высоко оценивается умение строить личностные отношения, и на сколько от этого зависит успех всей команды или компании, можете почитать относительно свежие работы по этой теме (eng manager in FB Julie Zhuo — The Making of a Manager или Eric Schmidt — How Google Works).

Информация

В рейтинге
Не участвует
Откуда
Екатеринбург, Свердловская обл., Россия
Дата рождения
Зарегистрирован
Активность