Но в этом и талант руководителя — установить такой срок, который не позволит чрезмерно расслабиться, с одной стороны, и не «гнать коней» — с другой.
Казалось бы, что в этом сложного? Эстимейты огромная область, которую до сих пор не удалось формализовать, чтобы можно было адекватно оценивать проекты. А тут так наивно про талант руководителя. Который чаще всего не вникает в проект настолько, чтобы в деталях понимать что необходимо сделать
Абсолютно точно! Когда пашешь как не в себя весь день, закрываешь таски одну за другой, мозг закипает и креатив абсолютно пропадает, хотя фактически ты супер продуктивен. Но стоит поработать в расслабленном темпе - идеи начинают проходить сами по себе, видишь где что можно улучшить и можешь смотреть на вещи под другим углом
Истина! Хотя в монолите даже хуже. Если один некритичный микросервис упадет - можно жить дальше с ограничениями. Если некритичный кусок кода положит весь монолит, то это уже гораздо хуже
Хороший краткий гайд, но подобное уже было неоднократно. Ожидал увидеть более сложную реализацию. Например реализацию распределенных транзакций упрощенно, реализацию взаимодействия запрос-ответ и обработки сбоев
"В этом и есть суть этих метрик, с ростом recall уменьшается precision, и наоборот."
Всегда ли это так? Лень производить выкладки, но мне кажется если при улучшении модели, будет расти TP за счёт равномерного "изымания" значений из FP и FN, то recall и precision будут расти параллельно. Разве не так?
Фильтр удобный, сам бы пользовался при поиске. Но довольно странно видеть подобную дискриминацию от компании, которая запретила указывать национальные или другие предпочтения в объявлениях. Были ли жалобы со стороны авторов объявление? Что если человек не согласен с решением нейронки?
Сложность не в том, что кто-то не хочет, а в том, что если вкинуть запрос на ревью куда-нибудь в общий чатик, безлично, то велика вероятность что все пройдут мимо в надежде что ревью сделает кто-то другой. Коллективная (без)ответственность, проявляется не только в работе
В Перекладывание ответственности ожидал увидеть ситуацию, что никто не рвется делать ревью, если просить команду, потому что всегда может сделать кто-то другой. Как справляетесь (справились) с этой проблемой? Автоматизированное назначение и оповещение или ручной процесс?
Спасибо! Отличный гайд, добавил в закладки После нынешнего довольно небольшого проекта, читая, оглядываюсь назад и вспоминаю многие решения принятые на одном из прошлых хайлоад проектов. В части кода в особенности, заморочки с избыточностью, сериализацией, бинарными данными и ORM.
Собеседовался на позицию scala разработчика осенью. Не буду говорить о нюансах процесса найма, т.к. тут мнения по большому счету зависит от HR.
Первый этап на знание scala. Сходу вопрос - что делали на scala, какие библиотеки использовали? То есть опыт в целом не интересен, интересно только что делал непосредственно по стеку. В целом понимаю такой подход, но со скалой есть своя специфика - специалистов не так много и многие компании готовы брать людей под переобучение, Тинькофф, насколько мне известно, в том числе. Заранее сообщаю, что работал со скалой, но было дело 1,5 года назад и функциональщиной занимался мало, такой уж проект был. То есть синтаксис знаю, писать могу, но уровень нужно будет немного подтянуть при возвращении на скалу. Да-да, могу и до собеседования подготовится, вспомнить, но рассчитывал на то что Т закроет глаза на некоторые нюансы, раз уж совсем с нуля берут. Едем дальше. Дают задачу, посчитать количество смен знака в последовательности. Решаю, просят пофункциональней. Предлагаю варианты, но недостаточно хардкорные видимо. На каком-то рабочем решении остановились, пошли дальше. Еще одна задача и все то же самое.
Чтобы долго не расписывать, основной момент, который показался странным это полное отсутствие вопросов по смежным темам. Абсолютно. Только Scala, Scala, Scala. Я понимаю, что компания топит за скалу, но отказывать человеку только потому, что он не знает нюансов конкретного ЯП, но готов учиться это точне не FAANG way. Повторюсь, такой подход вполне уместен, раз компании так хочется, но таким образом можно потерять много толковых опытных кандидатов, которые в данный момент не достаточно сильно в конкретной технологии, но спустя месяц будут перформить лучше тех кто приходил со скиллом (не про себя). Не зря же FAANG и вместе с ними куча крутых компании проводят language-agnostic interview
После интервью HR спросила как впечатления, поделился тем же что и выше. На что в ответ получил длинный ответ о том что это правильно, а я не понимаю. Что ж, не понимаю зачем спрашивать впечатление, а потом пытаться его оспорить. Чуть не забыл, интервьюер не дал возможности что-то спросить про компанию, на что HR ответила "Обсуждение компании и задач тоже происходит уже на финальной части, иногда ребята отвечают на вопросы во время технической встречи, но это больше зависит от интервьюера и того, насколько остается время". Время оставалось.
Отказа, кстати, ждал неделю.
П.С. Мне не перестал импонировать Тинькофф как компания или потенциальный работодатель, но в целом опыт был негативный. Предлагали вакансию java, но на тот момент уже был оффер
Делал что-то подобное для себя. Одним из основных критериев было отношение зп в ИТ к средней зп. К примеру в Австрии зп айтишника примерно равна средней зп, что не очень то радует. В то время как в той же Швейцарии отношение примерно 1,5-2,5 к 1.
Не знаю как для Вас, но нам с супругой хотелось бы в будущем жить в собственном жилье. По этому показателю очень большой разброс от города к городу, что стоит тоже учитывать.
И напоследок про метод отсева по количеству ИТ вакансий. К примеру, в Дании есть Убер, Гугл и другие интересные компании, поэтому я бы не стал ее списывать со счетов. По крайней мере оставил бы, как и Вы Германию с Австрией, ради возможного привлекательного оффера
"But it worked with my mocked database ?"
В оригинале все довольно тривиально. Не знаю зачем было калькировать mocked, учитывая, что в подзаголовке используется слово "мок"
Интересное соседство :)
Казалось бы, что в этом сложного? Эстимейты огромная область, которую до сих пор не удалось формализовать, чтобы можно было адекватно оценивать проекты. А тут так наивно про талант руководителя. Который чаще всего не вникает в проект настолько, чтобы в деталях понимать что необходимо сделать
Абсолютно точно! Когда пашешь как не в себя весь день, закрываешь таски одну за другой, мозг закипает и креатив абсолютно пропадает, хотя фактически ты супер продуктивен. Но стоит поработать в расслабленном темпе - идеи начинают проходить сами по себе, видишь где что можно улучшить и можешь смотреть на вещи под другим углом
Первая картинка очень напоминает здание университета Иннополис. Случайно ли?
Истина! Хотя в монолите даже хуже. Если один некритичный микросервис упадет - можно жить дальше с ограничениями. Если некритичный кусок кода положит весь монолит, то это уже гораздо хуже
А, ок. Не обратил внимания, что это перевод
Хороший краткий гайд, но подобное уже было неоднократно. Ожидал увидеть более сложную реализацию. Например реализацию распределенных транзакций упрощенно, реализацию взаимодействия запрос-ответ и обработки сбоев
Спасибо, отличная аналогия для запоминания
"В этом и есть суть этих метрик, с ростом recall уменьшается precision, и наоборот."
Всегда ли это так? Лень производить выкладки, но мне кажется если при улучшении модели, будет расти TP за счёт равномерного "изымания" значений из FP и FN, то recall и precision будут расти параллельно. Разве не так?
Фильтр удобный, сам бы пользовался при поиске. Но довольно странно видеть подобную дискриминацию от компании, которая запретила указывать национальные или другие предпочтения в объявлениях.
Были ли жалобы со стороны авторов объявление? Что если человек не согласен с решением нейронки?
Сложность не в том, что кто-то не хочет, а в том, что если вкинуть запрос на ревью куда-нибудь в общий чатик, безлично, то велика вероятность что все пройдут мимо в надежде что ревью сделает кто-то другой. Коллективная (без)ответственность, проявляется не только в работе
В Перекладывание ответственности ожидал увидеть ситуацию, что никто не рвется делать ревью, если просить команду, потому что всегда может сделать кто-то другой.
Как справляетесь (справились) с этой проблемой? Автоматизированное назначение и оповещение или ручной процесс?
Спасибо! Отличный гайд, добавил в закладки
После нынешнего довольно небольшого проекта, читая, оглядываюсь назад и вспоминаю многие решения принятые на одном из прошлых хайлоад проектов. В части кода в особенности, заморочки с избыточностью, сериализацией, бинарными данными и ORM.
Собеседовался на позицию scala разработчика осенью. Не буду говорить о нюансах процесса найма, т.к. тут мнения по большому счету зависит от HR.
Первый этап на знание scala.
Сходу вопрос - что делали на scala, какие библиотеки использовали?
То есть опыт в целом не интересен, интересно только что делал непосредственно по стеку. В целом понимаю такой подход, но со скалой есть своя специфика - специалистов не так много и многие компании готовы брать людей под переобучение, Тинькофф, насколько мне известно, в том числе.
Заранее сообщаю, что работал со скалой, но было дело 1,5 года назад и функциональщиной занимался мало, такой уж проект был. То есть синтаксис знаю, писать могу, но уровень нужно будет немного подтянуть при возвращении на скалу. Да-да, могу и до собеседования подготовится, вспомнить, но рассчитывал на то что Т закроет глаза на некоторые нюансы, раз уж совсем с нуля берут.
Едем дальше. Дают задачу, посчитать количество смен знака в последовательности. Решаю, просят пофункциональней. Предлагаю варианты, но недостаточно хардкорные видимо. На каком-то рабочем решении остановились, пошли дальше.
Еще одна задача и все то же самое.
Чтобы долго не расписывать, основной момент, который показался странным это полное отсутствие вопросов по смежным темам.
Абсолютно. Только Scala, Scala, Scala.
Я понимаю, что компания топит за скалу, но отказывать человеку только потому, что он не знает нюансов конкретного ЯП, но готов учиться это точне не FAANG way.
Повторюсь, такой подход вполне уместен, раз компании так хочется, но таким образом можно потерять много толковых опытных кандидатов, которые в данный момент не достаточно сильно в конкретной технологии, но спустя месяц будут перформить лучше тех кто приходил со скиллом (не про себя). Не зря же FAANG и вместе с ними куча крутых компании проводят language-agnostic interview
После интервью HR спросила как впечатления, поделился тем же что и выше. На что в ответ получил длинный ответ о том что это правильно, а я не понимаю. Что ж, не понимаю зачем спрашивать впечатление, а потом пытаться его оспорить.
Чуть не забыл, интервьюер не дал возможности что-то спросить про компанию, на что HR ответила "Обсуждение компании и задач тоже происходит уже на финальной части, иногда ребята отвечают на вопросы во время технической встречи, но это больше зависит от интервьюера и того, насколько остается время". Время оставалось.
Отказа, кстати, ждал неделю.
П.С.
Мне не перестал импонировать Тинькофф как компания или потенциальный работодатель, но в целом опыт был негативный. Предлагали вакансию java, но на тот момент уже был оффер
Что касается скалы то они здорово поддерживают немногочисленное коммьюнити, поэтому многие скалисты и рвутся туда
Прошу прощения, Каденция, Шаговые функции и Долговечные функции в примерах оркестрации это автоперевод?
Не знаю как для Вас, но нам с супругой хотелось бы в будущем жить в собственном жилье. По этому показателю очень большой разброс от города к городу, что стоит тоже учитывать.
И напоследок про метод отсева по количеству ИТ вакансий. К примеру, в Дании есть Убер, Гугл и другие интересные компании, поэтому я бы не стал ее списывать со счетов. По крайней мере оставил бы, как и Вы Германию с Австрией, ради возможного привлекательного оффера