Предлагаю не обожествлять ТК, который написан ни в интересах работника, ни в интересах работодателя, а исключительно в интересах государства. Зарплата в конверте (то есть кэшем) это кажется такой пережиток прошлого, пока обнал не прикрыли, и это действительно вариант хуже ТК. Для квалифицированного специалиста лучшим и самым здоровым вариантом трудовых отношений является ИП на УСН с кастомным контрактом, просто надо помнить, что вы как работник тоже можете выставлять свои условия. То-есть если вам в контракт хотят впихнуть штрафы, то можно требовать и плюшки. И кстати с ИП платятся соцвзносы, то есть вам начисляются пенсионные баллы.
Ваш работодатель нарушал ТК, потому-что ТК предусматривает неиспользование работником отпуска в течении года только в крайних случаях. Если бы вы брали больничный, то получив за него компенсацию, вы бы очень удивились ее размеру, она очень сильно ограничена сверху и компенсировать разницу между зарплатой и компенсацией вам по ТК никто не обязан. Если бы получали отпускные, то тоже удивились бы что вам пришло в месяц денег меньше зарплаты, а в некоторые особые месяцы существенно меньше.
Ради интереса, вы когда-нибудь получали выплаты за отпуск или больничный по ТК РФ? Вот где настоящее кидалово. Или у вас настолько маленькая зарплата, что выплаты по больничному, кажутся хоть чем-то кроме издевательства? Замечу, что копить неотгуленный отпуск это тоже не по ТК, по ТК отпуск не ваше право, а фактически ваша обязанность.
Ваш код на порядок или два лучше чем то, то в статье. По крайней мере он читается на лету, в отличии от. Код, который приведен как пример грамотного решения в статье, не должен пройти ревью. Да, я считаю, что разработчик, начиная с уровня мидла должен в этом случае попросить контекст, в котором вызывается метод, или явно указать, что он бы в первую очередь попытался бы отрефакторить код снаружи. Насчет входных параметров, если эта функция вызывается из любого места кода, то это просто вопрос времени, когда ее кто-то вызовет с неотсортированными массивами, и тогда первый неоптимальный вариант не является неоптимальным, он будет единственным правильным ответом. Если бы собеседуемый указал на это, это было бы ему в плюс. Насчет прошли бы или нет, это зависело бы от других факторов а не только от того как вы написали эту функцию. Возможно в голове у меня отложилось бы, что вы скорее склонны писать понятный и читаемый код, а автор статьи код пишет тяжелый и неприятный.
По сути нужен не HR, нужен помощник/секретарь, который чуть сократит время работы тимлида, а не зарежет, поржав с девочками, всех релевантных кандидатов. Но, если секретаря нет, то тоже не страшно. Если компания большая, и ее HR саботирует процесс найма, как в этом посте, то я бы попробовал хотя бы некоторым командам дать возможность самим искать себе кадры.
Вот реальный кейс поиска фронтенд (react, mobx, ts) - мидла в noname микро компанию месяц назад.
публикация на hh
200 откликов за первый день, вакансию скрываем - горшочек не вари
Один человек за несколько часов просматривает 100 резюме из присланных, и отправляет либо предложение договориться о собеседовании в телеграмме либо отказ.
Из 100 резюме в воронке, назначено и проведено 17 собеседований.
Собеседование проводится двумя главными разработчиками (тимлидами). Время на собеседование - час. Форма - разговор, с техническими вопросами. После собеседования 15 минут перекур и обсуждение кандидата. 17 собеседований занимают примерно 5 рабочих дней.
Отобрано 2 финалиста. Сделан оффер первому и он принял предложение.
Итого от размещения вакансии до выхода человека на работу прошло 3 недели. Сотрудник с работой справляется, представлению тимлидов о фронтенд мидле соответствует.
В моей картине мира именно по этой вакансии была очередь за забором.
Мой личный опыт (разработчик и внезапный генеральный директор продуктовой микро компании) показывает, что фич, которые приносят деньги и не оттестированы не бывает в природе. В основном они приносят внезапный головняк, что для микро компании чревато срывом сроков по другим продуктам. Поэтому обычно переговоры с разработчиками ведутся по вопросу, как написать фичу без оверинжиниринга, а не о том надо ли ее писать без тестов и под рефакторинг или не надо.
Если продакт менеджер говорит а почему 20, давай 10 и его нужно убеждать в том, что писать новую фичу без тестов и сразу под рефакторинг это плохо, то это говорит о его потенциальной профнепригодности. Адекватный диалог - должен звучать так:
20 часов?
Качественно и с тестами?
Да
Ок, вперед. (Или если во время не укладываемся) Ладно выпустим в следующем релизе.
Бюрократии, возможно, больше, чем в РФ (но я не был в РФ в качестве иностранца, так что не знаю), но она на 99% сидя в кресле дома попивая кофеёк лениво разбираться с онлайн-формами (иногда помощью Google Translate, но опять же я сам виноват в этом), а не часами от руки заполнять бесконечные бланки на подоконнике какого-нибудь госучреждения с очередью недовольных за спиной. ЭТО ДРУГОЕ.
Я ту недавно, в Москве, менял генерального директора в ООО, после внезапной гибели предыдущего гендиректора, который в то-же время являлся владельцем 50% доли этого ООО. Это достаточно неприятный казус в таком сочетании. И ни разу не сидел на подоконниках и не заполнял бланки. В основном процесс построен так, что тебе присылают инструкции, которые ты выполняешь. И даже в этом тяжелом случае, обычный программист, которым я по сути являюсь, справился с возвратом управления компании. Так что как минимум в Москве с бюрократией все замечательно.
Это миф о мифах, за 15 лет работы в постсоветском IT такие подходы к работе я не встречал ни разу. Зато постсоветское IT характеризуется подходом - сначала попытаться разобраться, почитать документацию, погуглить, а потом уже писать вопросы в поддержку. И это отличный, экономящий огромное количество времени подход к работе.
Предлагаю не обожествлять ТК, который написан ни в интересах работника, ни в интересах работодателя, а исключительно в интересах государства. Зарплата в конверте (то есть кэшем) это кажется такой пережиток прошлого, пока обнал не прикрыли, и это действительно вариант хуже ТК. Для квалифицированного специалиста лучшим и самым здоровым вариантом трудовых отношений является ИП на УСН с кастомным контрактом, просто надо помнить, что вы как работник тоже можете выставлять свои условия. То-есть если вам в контракт хотят впихнуть штрафы, то можно требовать и плюшки. И кстати с ИП платятся соцвзносы, то есть вам начисляются пенсионные баллы.
Ваш работодатель нарушал ТК, потому-что ТК предусматривает неиспользование работником отпуска в течении года только в крайних случаях. Если бы вы брали больничный, то получив за него компенсацию, вы бы очень удивились ее размеру, она очень сильно ограничена сверху и компенсировать разницу между зарплатой и компенсацией вам по ТК никто не обязан. Если бы получали отпускные, то тоже удивились бы что вам пришло в месяц денег меньше зарплаты, а в некоторые особые месяцы существенно меньше.
Ради интереса, вы когда-нибудь получали выплаты за отпуск или больничный по ТК РФ? Вот где настоящее кидалово. Или у вас настолько маленькая зарплата, что выплаты по больничному, кажутся хоть чем-то кроме издевательства? Замечу, что копить неотгуленный отпуск это тоже не по ТК, по ТК отпуск не ваше право, а фактически ваша обязанность.
del
Ваш код на порядок или два лучше чем то, то в статье. По крайней мере он читается на лету, в отличии от. Код, который приведен как пример грамотного решения в статье, не должен пройти ревью. Да, я считаю, что разработчик, начиная с уровня мидла должен в этом случае попросить контекст, в котором вызывается метод, или явно указать, что он бы в первую очередь попытался бы отрефакторить код снаружи. Насчет входных параметров, если эта функция вызывается из любого места кода, то это просто вопрос времени, когда ее кто-то вызовет с неотсортированными массивами, и тогда первый неоптимальный вариант не является неоптимальным, он будет единственным правильным ответом. Если бы собеседуемый указал на это, это было бы ему в плюс. Насчет прошли бы или нет, это зависело бы от других факторов а не только от того как вы написали эту функцию. Возможно в голове у меня отложилось бы, что вы скорее склонны писать понятный и читаемый код, а автор статьи код пишет тяжелый и неприятный.
У меня безоговорочный приоритет получил бы кандидат, который, перед тем как писать код задал бы несколько вопросов.
какого размера массивы в параметрах, есть ли смысл тут писать оптимальное решение в ущерб читаемости кода
нет ли возможности отрефакторить, вызывающий код так, чтобы избежать написания алгоритма и обойтись сортировкой из стандартной библиотеки
приватный это метод или публичный, нужна ли проверка на то, что массивы отсортированы
Ну и так далее. Это если конечно мы проверяем "насколько хорошо варит голова кандидата в бою".
По сути нужен не HR, нужен помощник/секретарь, который чуть сократит время работы тимлида, а не зарежет, поржав с девочками, всех релевантных кандидатов. Но, если секретаря нет, то тоже не страшно. Если компания большая, и ее HR саботирует процесс найма, как в этом посте, то я бы попробовал хотя бы некоторым командам дать возможность самим искать себе кадры.
Вот реальный кейс поиска фронтенд (react, mobx, ts) - мидла в noname микро компанию месяц назад.
публикация на hh
200 откликов за первый день, вакансию скрываем - горшочек не вари
Один человек за несколько часов просматривает 100 резюме из присланных, и отправляет либо предложение договориться о собеседовании в телеграмме либо отказ.
Из 100 резюме в воронке, назначено и проведено 17 собеседований.
Собеседование проводится двумя главными разработчиками (тимлидами). Время на собеседование - час. Форма - разговор, с техническими вопросами. После собеседования 15 минут перекур и обсуждение кандидата. 17 собеседований занимают примерно 5 рабочих дней.
Отобрано 2 финалиста. Сделан оффер первому и он принял предложение.
Итого от размещения вакансии до выхода человека на работу прошло 3 недели. Сотрудник с работой справляется, представлению тимлидов о фронтенд мидле соответствует.
В моей картине мира именно по этой вакансии была очередь за забором.
Мой личный опыт (разработчик и внезапный генеральный директор продуктовой микро компании) показывает, что фич, которые приносят деньги и не оттестированы не бывает в природе. В основном они приносят внезапный головняк, что для микро компании чревато срывом сроков по другим продуктам. Поэтому обычно переговоры с разработчиками ведутся по вопросу, как написать фичу без оверинжиниринга, а не о том надо ли ее писать без тестов и под рефакторинг или не надо.
Если продакт менеджер говорит а почему 20, давай 10 и его нужно убеждать в том, что писать новую фичу без тестов и сразу под рефакторинг это плохо, то это говорит о его потенциальной профнепригодности. Адекватный диалог - должен звучать так:
20 часов?
Качественно и с тестами?
Да
Ок, вперед. (Или если во время не укладываемся) Ладно выпустим в следующем релизе.
...кровати двигает
Я ту недавно, в Москве, менял генерального директора в ООО, после внезапной гибели предыдущего гендиректора, который в то-же время являлся владельцем 50% доли этого ООО. Это достаточно неприятный казус в таком сочетании. И ни разу не сидел на подоконниках и не заполнял бланки. В основном процесс построен так, что тебе присылают инструкции, которые ты выполняешь. И даже в этом тяжелом случае, обычный программист, которым я по сути являюсь, справился с возвратом управления компании. Так что как минимум в Москве с бюрократией все замечательно.
Это миф о мифах, за 15 лет работы в постсоветском IT такие подходы к работе я не встречал ни разу. Зато постсоветское IT характеризуется подходом - сначала попытаться разобраться, почитать документацию, погуглить, а потом уже писать вопросы в поддержку. И это отличный, экономящий огромное количество времени подход к работе.