Ну нет, типы то я должен расставить, где требуется. Иначе описанная мной схема не работает.
То есть вы рассказываете, что подключив линтер и вручную расставив аннотации типов вы получаете ровно то же самое, что в статически типизированных языках работает само (без линтера и аннотаций).
Да, наверное так и есть. Спасибо за наглядное объяснение преимуществ статически типизированных языков. Стоит еще отметить, что забытая анотация типа не позволит сломать проверку типов в статическом языке.
Сравнивать личный опыт, наверное, не очень показательно.
Вот средние зарплаты из статистики по сотрудникам одной и той же компании на аналогичных позициях (общая компенсация включая бонусы и акции, приведено к долларам):
Младшие: Германия — 137k, США — 175k
Средние: Германия — 182k, США — 250k
Ведущие: Германия — 236k, США — 318k
Для лиц, не достигших совершеннолетия законы требуют явного согласия от правомочных представителей на хранение регистрационных данных. То есть пользоваться ресурсом — можно. Регистрироваться — только с родителями.
Ну зачастую с отставанием реплики ничего делать и не надо. Далеко не всегда нужны строго актуальные данные. В тех же местах, где нужны актуальные данные есть как минимум два варианта:
— использовать принудительное чтение из мастера
— указывать в запросе требуемую метку целостности — в этом случае реплика может либо ждать, когда данные догонятся до нужной точки, либо перенаправить запрос на мастер.
у меня действительно «подгорает», когда мои любимые инструменты задвигают в угол.
А кто, где и что задвигает в угол? В статье говорится только о том, что некоторые претензии к статически типизируемым языкам несостоятельны. Почемы вы воспринимаете это как «задвигание в угол»?
написали cty,
Ну вот я читаю описание cty и в первом абзаце вижу — «The primary intended use is for implementing configuration languages»
Аналогичная ситуация была в паре других проектов, где я варился — люди создавали отдельный язык для конфигурации приложения (то есть ядро системы было написана на одном языке, а для дополнительной конфигурации пользователем предлагался другой). Не знаю, как насчёт cty, но в двух мною наблюдаемых случаях это действительно давало возможность что-то быстренько «сконфигурировать», но помере роста требований к конфигурации и объёма, становилось неуправляемым. Разработчики ядра обычно в таких случаях делали вид, что их это не касается — «в ядре всё хорошо, а кастомизации это уже не наша забота».
Когда вам говорят, что вы чего-то не знаете или не понимаете, а вы приравниваете это к обвинению в глупости − это в вас говорит снобизм или чувство превосходства.
Сначала вы как бы задали вопрос «Зачем?» (правда уже вопрос был сформулирован скорее не как вопрос, а как наезд). Затем вы услышали ответ, но вас он не устроил и вы решили дать свой ответ. Уже в этом месте очевидно, что вы пришли в эту ветку не конструктивно обсуждать, а поспорить и наехать (форма всех реплик только подтверждает это). Достойное желание и как следствие — достойная награда в виде минусов (кстати, я ещё и не минусовал :) )
Вы делаете ничем не обоснованное предположение о мотивах и, базируясь на этом предположении, объявляете разработчиков на статически типизированных языках, по сути, глупцами.
Не вижу в таком варианте дискуссии почвы для содержательного обсуждения.
У нас вообще нет формулировки «señor / middle / junior» в предложении. Вообще.
Заглянул на сайт Кантокса. Увидел позиции
— R Developer/Data Scientist
— IT Support Engineer
— User Researcher Specialist (Fintech)
— Quality Engineer
— Ruby/Rails Software Engineer
— Senior Software Engineers (Ruby on Rails/Elixir)
Вы не уловили главной мысли моего комментария. Мысль следующая — для компании (особенно успешной и привлекательной для потенциальных сотрудников) выгоднее организовать процесс приема так, чтобы планка была заведомо выше, чем это требуется для реальной работы. Завышение планки позволяет допускать меньше ошибочно принятых кандидатов за счет увеличения числа ошибочно непринятых. Несомненно, идеальных процессов не бывает, и реализация идеи зависит от конкретных исполнителей.
1.
Т.к. может существовать система отбора которая одновременно и отсеивает хороших разработчиков и пропускает плохих.
Ваш пример про тимлида мне кажется очень надуманным. Если компания поручает тимлиду наем персонала, то это скорее всего означает, что тимлид имеет достаточно большую ответственность в рамках поставленных задач. А значит его основные приоритеты не избавляться от конкурентов, а добиться выполнния задач. Вполне нормально, что для выполнения задач ему не нужны архитекторы в команду, но крепких разработчиков он не будет отсеивать просто так.
Несомненно, существуют места с очень высоким уровнем внутренней карьерной борьбы, где описанный вами сценарий возможен. Но, честно говоря, буду рад если меня отсеют на собеседовании в такое место. Это сэкономит мне кучу нервов.
2.
-кандидат все же не готов к работе и это не было определено на собесе
-кандидат устраивает фирму но он сам по своей инициативе вскоре уходит.
Оба этих случая я бы отнёс к категории приём плохого разработчика. Хороший разработчик для компании это не «абстрактиный хороший разработчик в вакууме», а разработчик, который принесёт конкретной компании конкретную пользу. Если компания приняла сотрудника, который никакой пользы принести не смог (вне зависимости от причин), то компания приняла плохого сотрудника. И задача собеседования — постараться такого не допустить. Всякие ненавидимые кандидатами дурацкие психологические вопросы часть этого. «Непрофильные вопросы» — тоже. Если человек не готов отвечать на вопросы, котьорые чуть-чуть выходят за рамки его потенциальных обязанностей, то это значит, что он не сможет работать, если ситуация чуть-чуть изменится.
Тестовое задание по сравнение с написанием кода на интервью плохо тем, что отсутствует обратная связь. На интервью всегда можно задать вопрос и уточнить постановку задачи, а при тестовом задании приходится угадывать. И проблемой будет не плохой код, а то, что задание соискателем и компанией понимается по-разному.
Я вот увидев в резюме у человека название какой-то технологии задам риторический вопрос типа «вы работали с этой технологией?» просто для того, чтобы начать разговор. А уж вопрос типа «какие детали этой технологии вы знаете» более чем хороший, если человек заявил, что он с технологией работал.
К сожалению, бОльшая часть текста в резюме малоинформативна для собеседующего. Прочитать можно, но из-за отсутствия информации мало что в голове удерживается. Но и сказать, что стоило бы выкинуть из резюме, — сложно, потому что у каждого собеседующего свои информационные фильтры.
Вы считаете, что на тимлида интроверт не подойдёт, а я тут не согласен. Для менеджера по продажам такое, наверное, верно.
Но не суть. Я хотел отметить то, что для большинства важных характеристик "универсальных критериев" не просто не существует, а их не может существовать. То есть проблема не в том, что кто-то недостаточно организовал процесс и не вычислил критерии, а в том, что такое вычисление в привычном понимании невозможно.
Хотя вот обучат скоро машинный интеллект прием сотрудников проводить. Как он будет решения принимать никто не объяснит, но зато будет универсально :)
Да, наверное так и есть. Спасибо за наглядное объяснение преимуществ статически типизированных языков. Стоит еще отметить, что забытая анотация типа не позволит сломать проверку типов в статическом языке.
Сравнивать личный опыт, наверное, не очень показательно.
Вот средние зарплаты из статистики по сотрудникам одной и той же компании на аналогичных позициях (общая компенсация включая бонусы и акции, приведено к долларам):
Младшие: Германия — 137k, США — 175k
Средние: Германия — 182k, США — 250k
Ведущие: Германия — 236k, США — 318k
Отношение двух чисел сами посчитайте.
Ну сейчас-то именно так и происходит
Спасибо за ссылочку. Посмотрел. У штатов GDP за последние десять лет вырос на 40% и тренд сохраняется. При этом вы пишете, что В России за тот же период рост — 0%.
Если 40% — это медленное умирание, то как назвать 0?
— использовать принудительное чтение из мастера
— указывать в запросе требуемую метку целостности — в этом случае реплика может либо ждать, когда данные догонятся до нужной точки, либо перенаправить запрос на мастер.
Ну вот я читаю описание cty и в первом абзаце вижу — «The primary intended use is for implementing configuration languages»
Аналогичная ситуация была в паре других проектов, где я варился — люди создавали отдельный язык для конфигурации приложения (то есть ядро системы было написана на одном языке, а для дополнительной конфигурации пользователем предлагался другой). Не знаю, как насчёт cty, но в двух мною наблюдаемых случаях это действительно давало возможность что-то быстренько «сконфигурировать», но помере роста требований к конфигурации и объёма, становилось неуправляемым. Разработчики ядра обычно в таких случаях делали вид, что их это не касается — «в ядре всё хорошо, а кастомизации это уже не наша забота».
Вы делаете ничем не обоснованное предположение о мотивах и, базируясь на этом предположении, объявляете разработчиков на статически типизированных языках, по сути, глупцами.
Не вижу в таком варианте дискуссии почвы для содержательного обсуждения.
Очень часто, из-за неумения готовить. Разработчики приходят из Javascript фронтенда в бэк на Java и пытаются там воспроизвести привычный мир.
Заглянул на сайт Кантокса. Увидел позиции
— R Developer/Data Scientist
— IT Support Engineer
— User Researcher Specialist (Fintech)
— Quality Engineer
— Ruby/Rails Software Engineer
— Senior Software Engineers (Ruby on Rails/Elixir)
Так что как минимум «Senior» там присутствует.
1. Ваш пример про тимлида мне кажется очень надуманным. Если компания поручает тимлиду наем персонала, то это скорее всего означает, что тимлид имеет достаточно большую ответственность в рамках поставленных задач. А значит его основные приоритеты не избавляться от конкурентов, а добиться выполнния задач. Вполне нормально, что для выполнения задач ему не нужны архитекторы в команду, но крепких разработчиков он не будет отсеивать просто так.
Несомненно, существуют места с очень высоким уровнем внутренней карьерной борьбы, где описанный вами сценарий возможен. Но, честно говоря, буду рад если меня отсеют на собеседовании в такое место. Это сэкономит мне кучу нервов.
2. Оба этих случая я бы отнёс к категории приём плохого разработчика. Хороший разработчик для компании это не «абстрактиный хороший разработчик в вакууме», а разработчик, который принесёт конкретной компании конкретную пользу. Если компания приняла сотрудника, который никакой пользы принести не смог (вне зависимости от причин), то компания приняла плохого сотрудника. И задача собеседования — постараться такого не допустить. Всякие ненавидимые кандидатами дурацкие психологические вопросы часть этого. «Непрофильные вопросы» — тоже. Если человек не готов отвечать на вопросы, котьорые чуть-чуть выходят за рамки его потенциальных обязанностей, то это значит, что он не сможет работать, если ситуация чуть-чуть изменится.
Вы считаете, что на тимлида интроверт не подойдёт, а я тут не согласен. Для менеджера по продажам такое, наверное, верно.
Но не суть. Я хотел отметить то, что для большинства важных характеристик "универсальных критериев" не просто не существует, а их не может существовать. То есть проблема не в том, что кто-то недостаточно организовал процесс и не вычислил критерии, а в том, что такое вычисление в привычном понимании невозможно.
Хотя вот обучат скоро машинный интеллект прием сотрудников проводить. Как он будет решения принимать никто не объяснит, но зато будет универсально :)