Ну я же не говорю, что собеседование с техническим специалистом совсем не нужно. Граничные случаи отсеиваются и без тестового - просто глядя на то, как человек рассказывает о своем опыте, как отвечает на тех вопросы, какие знания, если спросить "чуть в сторону".
На самом деле тестовое задание - это всего лишь дополнительный этап воронки. Полезно, когда у вас столько кандидатов, что никакие устные собеседования не дают допустимого уровня фильтрации кандидатов. Или если если у вас одно место и вы готовы много месяцев искать для него "топчика". Который свалит через пол года, ибо в разработке хаос, руководители - самодуры, а тут офер на х2 пришел.
Интересная табличка. Если на нее взглянуть с другой стороны (с которой смотрят очень многие), то смысл получается приблизительно такой: если в компании выстроена разработка с тестированием, код ревью, планированием; если у разработчиков лид не названиям переменных обучает, а с людьми работает; если в компании построен онбординг, поэтапно оценивается прохождение испытательного, есть программы обучения, - то никакое тестовое на собеседовании не нужно.
Т.е. тестовое - это признак хаоса в отделе разработке?
Не, кража бонусов это вообще почему должно волновать компанию.
Имхо, проблема в другом.
Далеко не все тратят полученные бонусы, например, просто перестав пользоваться сетью, забыв про существование бонусного счета и тп
А бонусы — это не просто какая-то циферка в базе данных, это долг. Реальный такой долг компании перед клиентами. Когда тратятся бонусы — компания не получает часть дохода. И по мере накопления массы мертвых баллов эта цифра в отчетах начинает всех пугать, инвесторов в первую очередь. Ну отсюда и решение. А попутно можно и "потеряшку" завлечь в магазин сообщением о сгорании баллов.
Да, менеджер расскажет что искать, ибо даже в такой постановке задачи есть два варианта что искать — просто максимальную дату прозвона для каждого клиента или все же дату прозвона у последнего звонка. Эти даты могут отличаться. Те это формулирование начальных и граничных (не у всех звонков может быть дата прозвона) условий. Это как раз умение решать практические задачи, а не алгоритмические.
А после формулирования условий остается написать нужный SQL запрос, что во-первых, тоже не алгоритмическая, а практическая задача, а во-вторых при определенном навыке решения практических задач уже ищется в гугле.
Любой код можно назвать алгоритмом, конечно. Только вот под "алгоритм-меном" подразумеваются совсем другие алгоритмы и люди. И вот "алгорим-мен" может не догадаться, что пришедшую задачу нужно обсудить с постановщиком, а так же с тем, кто пользоваться будет. Ему вообще прикольнее задачки на сайтах решать, а не с менеджерами общаться. А практик сделать может не оптимально, зато формочку удобную нарисовать в итоге и больше профита компании доставить.
Для решения вашей повседневной задачи не нужны алгоритмы, нужно как раз умение решать повседневные задачи, те поговорить с менеджером, выяснить, что достаточно взять последний звонок клиенту и посмотреть дату следующего прозвона для этого звонка. Какие тут алгоритмы?
Автор коммента, на который я ответил, явно не думал, что нужно менять контракт птицы, если это вообще возможно.
А так то да, если у птицы заранее заложено исключение CantFly, то проблемы нет.
В реальности ЗП вообще слабо коррелирует с инфляцией, ибо это рыночная цена определяемая спросом/предложением. В тех нескольких крупных (сотни и тысячи программистов) компаниях, про которые я знаю как там устроено, делают индексацию ЗП на основе изменения вилки на рынке для соответствующей квалификации сотрудника. Инфляция, конечно, оказывает влияние на эту вилку, но не как основной фактор.
Как правило в таких компаниях то, что мы видим — лишь вершина айсберга. Большое количество внутренних продуктов связанных с учетом, работой с партнерами. Плюс конкретно у Нетфликса много платформ для показа, включая всякие телевизоры, тоже требует усилий немалых. Можно просто почитать их течблог для представления, какие проблемы встают и решаются.
Это все решается за деньги. Но я не говорил, что коробка хорошо. И даже не спорил с тем, что заказная разработка даст продукт гораздо более кастомизированный, чем коробка. Я опровергал то, что заказная разработка даст более поддерживаемый и качественно написанный продукт, потому что она просто не заинтересована это делать, ибо оперирует деньгочасами =) И мой опыт работы с заказной разработкой с обеих сторон это подтверждает =)
Ну и заказная разработка точно так же облажается с нагрузкой, ибо там обычно усредненная квалификация и сильных архитекторов нет, которые изначально подложат соломку, а когда упало — быстро составят план как поднять.
И, к слову, локдаун показал это, когда на некоторые магазины, активно использующие аутсорс команды, свалилась огромная нагрузка и одни неделями не могли хоть как-то стабилизировать свои интернет-магазины.
Если вы заказываете разработку с нуля у проверенных и зарекомендовавших себя разработчиков, можете быть уверены в двух вещах:
Этот код легко масштабируется, меняется, поддерживается и дополняется не только теми, кто его писал, но и любыми другими разработчиками.
На практике в этом как раз уверенным быть нельзя. На практике заказчик становится таким же заложником команды, как и в случае коробки. Вот только команда коробки имеет больше стимулов к обеспечению стабильности и качества релизов, чем команда разработки.
Конечно ключевое слово "проверенных и зарекомендовавших себя разработчиков", но это имеет отношение только к тем руководителям, кто создает далеко не первый свой проект, и по каждому он прошел с этой командой долгий путь доработок и решения проблем. И то, даже в этой ситуации нельзя быть уверенным — пришел другой прожект, сменился лид — и из идеальной команды поперло "как у всех"
Мне кажется подразумевается, что от дальних регионов быстрее дойти лазером до станции ближайшей к точкам обмена трафиком, чем спускать трафик сразу, а дальше уже по земле.
В команде был человек, на процессы забивал, его не драйвило, что мы делаем, на обед вместе не ходил, не ходил «на перекур» — не то, что интроверт, но просто остальные члены команды были «не его людьми», мы всячески пытались его привлечь. Ребятам было плохо с ним работать, в итоге его уволили. И это нормально, считай что как будто корпоративная культура, только командная.
Тут не о том, что такие люди бывают или нет, а о том, что таким человеком может стать и вполне себе старый хороший игрок. И задача руководителя 1) увидеть проблему раньше остальных на зачаточной стадии, когда ее можно еще решить, 2) попытаться решить, 3) принять жесткие меры вплоть до увольнения еще до того, как такой человек начнет быть токсичным для команды. если не решается проблема. В идеале — команда должна лишь ощутить легкий ветер этой проблемы и не более того.
И, внезапно, все это — детектирование проблемы и попытка ее решить — есть задача 121. Ибо "со стороны" ты проблему увидишь именно тогда, когда ее увидит вся команда… а это уже поздно.
В моем понимании, seniority так и выражается — если что-то не нравится, и ты сказал/предложил/решил, если что-то не работает, и ты сказал/предложил/решил, а не наоборот — забил до момента пока спросят.
Вы точно не путаете решение рабочих задач и именно личные проблемы какие-то? Например, какие-то субъективные несовместимости с коллегой, раздражающая манера продукта?
Изначально, мы договариваемся о всех процессах.
В смысле "изначально"? Пришел новый человек, его поставили перед фактом. Не может человек, как ему что-то не нравится — бежать сразу с жалобой, ну ок, не вписываешься. Не, ну вариант, конечно, вполне себе… если разработчики толпой валят (обычно это не так).
У меня такое ощущение, что вы выросли в этой команде, уже сработавшейся и стабильной. Там можно много что себе позволить ибо не нужно слаживать команду — это уже сделалось само или кем-то до вас.
В специальный корпоративный чат, тегая всех
Круто, вместо одного человека отвлекли 5… или 10 если команд две.
Я старался выстроить процесс открытости и раннего фидбека. Если тебе жалуются, и уже поздно — человек хочет уйти, потеряли ресурсы, потеряли нервы, — стоит задуматься над компетенциями тех, кто поздно сказал.
Вы компетенции разработчиков меряете их личностными особенностями?
если тебе рассказывают что-то, что должны были рассказывать — напоминаешь о процессах, раннем фидбеке
Вам нравится загонять людей в зону некомфорта? Раз они рассказывают на встрече, но не приходят сами — наверное им так комфортнее?
Бизнес не приходит и не спрашивает за что-то конкретное, могут спросить насколько новое решение эффективнее, либо нет ли блокеров, когда ориентировочно можно ждать.
Так кого он спрашивает, если над решением работает вся команда?
Ну я же не говорю, что собеседование с техническим специалистом совсем не нужно. Граничные случаи отсеиваются и без тестового - просто глядя на то, как человек рассказывает о своем опыте, как отвечает на тех вопросы, какие знания, если спросить "чуть в сторону".
На самом деле тестовое задание - это всего лишь дополнительный этап воронки. Полезно, когда у вас столько кандидатов, что никакие устные собеседования не дают допустимого уровня фильтрации кандидатов. Или если если у вас одно место и вы готовы много месяцев искать для него "топчика". Который свалит через пол года, ибо в разработке хаос, руководители - самодуры, а тут офер на х2 пришел.
Интересная табличка. Если на нее взглянуть с другой стороны (с которой смотрят очень многие), то смысл получается приблизительно такой: если в компании выстроена разработка с тестированием, код ревью, планированием; если у разработчиков лид не названиям переменных обучает, а с людьми работает; если в компании построен онбординг, поэтапно оценивается прохождение испытательного, есть программы обучения, - то никакое тестовое на собеседовании не нужно.
Т.е. тестовое - это признак хаоса в отделе разработке?
Не, кража бонусов это вообще почему должно волновать компанию.
Имхо, проблема в другом.
Далеко не все тратят полученные бонусы, например, просто перестав пользоваться сетью, забыв про существование бонусного счета и тп
А бонусы — это не просто какая-то циферка в базе данных, это долг. Реальный такой долг компании перед клиентами. Когда тратятся бонусы — компания не получает часть дохода. И по мере накопления массы мертвых баллов эта цифра в отчетах начинает всех пугать, инвесторов в первую очередь. Ну отсюда и решение. А попутно можно и "потеряшку" завлечь в магазин сообщением о сгорании баллов.
Да, менеджер расскажет что искать, ибо даже в такой постановке задачи есть два варианта что искать — просто максимальную дату прозвона для каждого клиента или все же дату прозвона у последнего звонка. Эти даты могут отличаться. Те это формулирование начальных и граничных (не у всех звонков может быть дата прозвона) условий. Это как раз умение решать практические задачи, а не алгоритмические.
А после формулирования условий остается написать нужный SQL запрос, что во-первых, тоже не алгоритмическая, а практическая задача, а во-вторых при определенном навыке решения практических задач уже ищется в гугле.
Любой код можно назвать алгоритмом, конечно. Только вот под "алгоритм-меном" подразумеваются совсем другие алгоритмы и люди. И вот "алгорим-мен" может не догадаться, что пришедшую задачу нужно обсудить с постановщиком, а так же с тем, кто пользоваться будет. Ему вообще прикольнее задачки на сайтах решать, а не с менеджерами общаться. А практик сделать может не оптимально, зато формочку удобную нарисовать в итоге и больше профита компании доставить.
Для решения вашей повседневной задачи не нужны алгоритмы, нужно как раз умение решать повседневные задачи, те поговорить с менеджером, выяснить, что достаточно взять последний звонок клиенту и посмотреть дату следующего прозвона для этого звонка. Какие тут алгоритмы?
Автор коммента, на который я ответил, явно не думал, что нужно менять контракт птицы, если это вообще возможно.
А так то да, если у птицы заранее заложено исключение CantFly, то проблемы нет.
Вы что, у себя в контракте перечисляете все исключения, которые не может выбросить метод?
Что нарушает LSP
В реальности ЗП вообще слабо коррелирует с инфляцией, ибо это рыночная цена определяемая спросом/предложением. В тех нескольких крупных (сотни и тысячи программистов) компаниях, про которые я знаю как там устроено, делают индексацию ЗП на основе изменения вилки на рынке для соответствующей квалификации сотрудника. Инфляция, конечно, оказывает влияние на эту вилку, но не как основной фактор.
Отсюда вывод — нужно просить ЗП на 2.45% больше, чем ты стоишь.
Как правило в таких компаниях то, что мы видим — лишь вершина айсберга. Большое количество внутренних продуктов связанных с учетом, работой с партнерами. Плюс конкретно у Нетфликса много платформ для показа, включая всякие телевизоры, тоже требует усилий немалых. Можно просто почитать их течблог для представления, какие проблемы встают и решаются.
Т.е. без опыта работы таксистом 3 года в таксисты не брать!
У меня знакомый с такими же словами molex перевернутым вставлял в диски =)
Это все решается за деньги. Но я не говорил, что коробка хорошо. И даже не спорил с тем, что заказная разработка даст продукт гораздо более кастомизированный, чем коробка. Я опровергал то, что заказная разработка даст более поддерживаемый и качественно написанный продукт, потому что она просто не заинтересована это делать, ибо оперирует деньгочасами =) И мой опыт работы с заказной разработкой с обеих сторон это подтверждает =)
Ну и заказная разработка точно так же облажается с нагрузкой, ибо там обычно усредненная квалификация и сильных архитекторов нет, которые изначально подложат соломку, а когда упало — быстро составят план как поднять.
И, к слову, локдаун показал это, когда на некоторые магазины, активно использующие аутсорс команды, свалилась огромная нагрузка и одни неделями не могли хоть как-то стабилизировать свои интернет-магазины.
На практике в этом как раз уверенным быть нельзя. На практике заказчик становится таким же заложником команды, как и в случае коробки. Вот только команда коробки имеет больше стимулов к обеспечению стабильности и качества релизов, чем команда разработки.
Конечно ключевое слово "проверенных и зарекомендовавших себя разработчиков", но это имеет отношение только к тем руководителям, кто создает далеко не первый свой проект, и по каждому он прошел с этой командой долгий путь доработок и решения проблем. И то, даже в этой ситуации нельзя быть уверенным — пришел другой прожект, сменился лид — и из идеальной команды поперло "как у всех"
Мне кажется подразумевается, что от дальних регионов быстрее дойти лазером до станции ближайшей к точкам обмена трафиком, чем спускать трафик сразу, а дальше уже по земле.
kafka-reassign-partitions утилита
Тут не о том, что такие люди бывают или нет, а о том, что таким человеком может стать и вполне себе старый хороший игрок. И задача руководителя 1) увидеть проблему раньше остальных на зачаточной стадии, когда ее можно еще решить, 2) попытаться решить, 3) принять жесткие меры вплоть до увольнения еще до того, как такой человек начнет быть токсичным для команды. если не решается проблема. В идеале — команда должна лишь ощутить легкий ветер этой проблемы и не более того.
И, внезапно, все это — детектирование проблемы и попытка ее решить — есть задача 121. Ибо "со стороны" ты проблему увидишь именно тогда, когда ее увидит вся команда… а это уже поздно.
Вы точно не путаете решение рабочих задач и именно личные проблемы какие-то? Например, какие-то субъективные несовместимости с коллегой, раздражающая манера продукта?
В смысле "изначально"? Пришел новый человек, его поставили перед фактом. Не может человек, как ему что-то не нравится — бежать сразу с жалобой, ну ок, не вписываешься. Не, ну вариант, конечно, вполне себе… если разработчики толпой валят (обычно это не так).
У меня такое ощущение, что вы выросли в этой команде, уже сработавшейся и стабильной. Там можно много что себе позволить ибо не нужно слаживать команду — это уже сделалось само или кем-то до вас.
Круто, вместо одного человека отвлекли 5… или 10 если команд две.
Вы компетенции разработчиков меряете их личностными особенностями?
Вам нравится загонять людей в зону некомфорта? Раз они рассказывают на встрече, но не приходят сами — наверное им так комфортнее?
Так кого он спрашивает, если над решением работает вся команда?