А то мне непонятео, что такое дает коммерческий опыт разработки, но чего не может дать самостоятельное изучение языка и средств разработки плюс практическая работа в IT в реальной жизни?
Как минимум, в том, что:
Запросто будет нестандартное API от другой команды, а интегрироваться необходимо.
Выбор библиотек зависит не только от разработчика, но и от департамента (как минимум).
Выбор того, что делать, зависит не от автора, а от заказчика (внутреннего или внешнего).
Есть ненулевая вероятность поработать с legacy.
Сроки более хитрые - они жесткие для определенных вещей, и гибкие для других.
Ну... Там сложно. Есть "на внешних системах" типа сайта или мобильного клиента - там все более-менее стандартно.
Если посмотреть вакансии банков, то 99% разработчиков вообще не будут даже близко касаться таких нишевых технологий. Другими словами, будет стандартный стек как в самой команде, так и в соседних с ней.
Но логично, что, если взять достаточно большую компанию, которая на рынке не один десяток лет, то в ней можно будет найти подобную систему, ибо vendor lock-in случается. Мне казалось, что фирмы стараются уходить от такого, ибо это повышенный риск (в терминологиях банков).
Про выгорание я специально написал. Люди разные, так что кто-то выгорит и с шести часов работы (активная фаза будет короче, конечно), а кто-то и 9 сможет выдерживать.
Плюс ещё коллективы разные, как и преемственность опыта. Я уж не говорю про то, что разные технологии вызывают разное отношение к процессу.
А как же open source и подобные инициативы (включая статьи на хабре)?
Для себя (но я не настаиваю и таком способе мысли) я заметил, что на работе люди получают компенсацию и опыт, который тает с каждым годом. А потому, больше работы - больше опыта.
Но, конечно же, не стоит забывать как о разного рода выгораниях, так и о других подобных последствиях.
Да, Вы полностью правы, я забыл написать стандартное предложение, что не стоит радикализировать моё утверждение.
Понятно, что бывают ситуации, что человек так и так будет жить недалеко от работы, так как супруг/супруга не могут работать удаленно. Плюс бывают ситуации, которые усложняют смену жилья на более удобное (с кабинетом и так далее). Бывают также ситуации, когда домашние не сильно проникаются эмпатией к работающему из дома.
Заодно я сразу скажу, что удаленка подходит не всем офисным сотрудникам. Некоторым юристам запрещено выносить бумаги из офиса, а у трейдеров рабочее место регламентировано строгими законами (которые не сильно одобряют ситуацию, когда муж и жена работают в разных банках, но на схожих позициях, так что, по сути, каждый видит котировки другого банка).
А что мешает проигнорировать и не уведомлять работая в офисе?
Ничего. Человек проигнорирует её в любом случае. Просто более проактивный (в хорошем смысле слова) скорее будет эффективным и дома (создаст комфортные условия и так далее), тогда как более пассивный дома найдет больше способов увильнуть от работы.
Только не стоит на это строго и догматично смотреть, я бы это списал на корреляцию.
Да, всё верно, бывают ограничения. Они же помешают найти работу другом городе (пусть даже в том же штате), кстати говоря.
Продажа и покупка жилья займет около полугода, если цена установлена рыночная и стороны не торопятся. Да и смена школы тоже возможно (но да, тут будут сложности).
С учетом того, что гибридный режим уже 2-3 года (зависит от ситуации), скорректировать жилье уж точно можно. Я уж не говорю про то, что не все жестко прикреплены к квартире/дому.
А можно попросить поподробнее описать сценарий? Насколько я знаю, некоторые серверы (BitBucket, GitHub) имеют настройку "ветка должна быть после rebase", то есть смержить можно будет только если 100% коммитов из мастера присутствуют в ветке с новыми изменениями. И да, это уже реализации серверов, а не просто git клиент.
Я подозреваю, что Вы имеете ввиду что-то другое. А какой сценарий требуется?
Мы же про АйТи говорим, верно? Это вполне себе стандартный подход, по факту-то.
Вроде, стандартный пост про собеседования имеет пару веток про "стоит знать хотя бы базовые и простейшие алгоритмы, или и так сойдет?", что неплохо обосновывает популярность подхода "я знаю в своей узкой области, а дальше не смотрю, пока серьезно не попросят".
Не совсем. Ряд задач намного удобнее решать оффлайн, когда люди в одной комнате, да еще и с маркерной доской. Язык тела тоже никто не отменял, так что разговаривать на чувствительные темы проще с глазу на глаз, а не через видеоконференцию.
Более того, лично у меня было много случаев, когда опытные люди принципиально не могли договориться с помощью email/видеозвонков, но быстро приходили к пониманию в переговорке. Последнее очень важно, так как долгие споры сильно затягивают разработку (особенно, если любой из вариантов решит задачу, но группа людей вживую демонстрируют мысленный эксперимент про Буриданова осла).
Ваше описание - это отличное подтверждение прошлых исследований, что удаленка (а, точнее, гибридный график в стиле "один день в офисе, две недели дома) оказывается очень эффективна для высококвалифицированных и мотивированных людей, однако она же сказывается негативно на людей с малым объемом опыта, а также на тех, кто не хочет работать (и ищет способы этого не делать).
Можно даже попытаться сделать корреляцию с другим поведением. Если, при видя ошибки в чужой библиотеке, вы уведомите создателя (внутри компании, или же на GitHub), то и удаленка для Вас будет более эффективна.
Если же дополнительная задача "уведомить" будет проигнорирована (зачем что-то делать, если можно не делать? Мы же в айти только ради денег, а подобный поход к коллеге только отнимет рабочее время), то и удаленка скажется только негативно на таком сотруднике.
Как слабое свидетельство этого - успех open source, где нередко бесплатное открытое решение работает намного лучше платного и закрытого (но не всегда, конечно, особенно, если речь касается UX).
Интересно посмотреть на соискателя с десятилетиями стажа (с проектами, публикациями, записями в трудовой), который не умеет программировать.
Без проблем, такое бывает в реальности. Самый типичный пример - бывший тимлид, который последние N лет занимался только ревью кода, а до этого был крепким мидлом, но который идёт на должность сеньор разработчика в более серьёзную фирму.
Другой вариант - человек, работающий на смежной с программированием должности в реальности.
Третий вариант - человек, проработавший над той же самой системой N лет, да ещё и в одиночку.
«Публикации» тут помогут слабо, так как не всегда известно, насколько человек сам всё делал, а насколько пересказывал. В резюме может быть схожая схема - никто не мешает приукрасить ситуацию.
Но конкретные примеры (с именами) я приводить не буду, ибо это неэтично.
Тут скорее как если повар, автор нескольких кулинарных бестселлеров
Автор книг не всегда является серьёзным профессионалом. Более того, автор книг для начинающих будет обладать навыками объяснения простых задач джунам, но не факт, что у него будет опыт решения более серьезных вещей.
Этому есть косвенное подтверждение - я не думаю, что многие возьмут человека со статьями на хабре в обход собеседований. И само наличие этих собеседований доказывает, что компания считает вероятность их провала далеко не нулевой.
Если говорить про похожие вещи у поваров, то есть отличный пример - Джеймс Оливер, который прославился книгами и телепередачами, тогда как ресторанный бизнес у него слегка прогорел.
знание алгоритмов проверки чисел на простоту надо сразу бежать
Это слишком примитивный алгоритм, чтобы выдавать его за "знание". Его в школах изучают, ну или на первых курсах, но даже там эта задача слишком простая, чтобы она попала в те же экзаменационные билеты.
И это отличная проверка на то, что человек может выразить примитивные вещи в коде.
Были случаи, что приходит супер-сеньор с опытом 20+
Исходные данные корректны (разве что не хватает деталей по поводу "супер" - оценка базируется по красивому резюме или по наличию, например, премии Тьюринга?)
, нужно отрывать с руками,
Для ответа на этот вопрос создаем интервью
а он не может две строчки кода связать
Эксперимент был поставлен, результаты были выявлены. Вывод: или эксперимент неудачен (например, человек был усталый, задачи были на css, несмотря на опыт в C++ и так далее), или же исходный тезис "нужно отрывать с руками".
Я спросил, реально ли они это используют в работе?
Суть лайвкодинга (и процесса интервью) не в симуляции рабочих условий, а в определении уровня кандидата с наименьшей ошибкой (ложноположительной, ложноотрицательной и так далее).
Например, если оценка профиля на гитхабе позволяет уменьшить ошибку, то компании будут его смотреть, даже несмотря на то, что в работе гитхаб не используется. Если вопросы о предыдущих местах и опыте позволяют уменьшить ошибку, то их будут задавать, даже если в реальной работе они подниматься не будут.
Лайвкодинг позволяет очень хорошо отсеять теоретиков: как новичков, которые заучили ответы, так и тимлидов, которые последние N лет не пишут код, а занимаются "управлением", "ревью кода" и пр., но которые подаются на должность "синьор программиста".
И да, такой подход может давать ошибки, если собеседующий делает сильные ограничения в стиле "используем строго регулярные выражения", "строго Java 11" или "пишем самый идеальный в мире код". Ну и, конечно же, бывают неудачные дни, так что собеседующий должен обладать определенной эмпатией.
Так же, как и таким же экономическим образом отутюжили Японию, СССР, Германию и вот сейчас пытаются сдержать Китай.
А что с Японией и с Германией? Какие на них санкции наложили?
Китай
Разве Китай не создавал серьезные барьеры в импорте-экспорте путем массовых блокировок в информационной сфере, путем запрета экспорта тех же редкоземельных металлов и так далее?
Если Вы используете JVM, то можно писать код на Kotlin. Результатом будет тот же байт-код, а проблема с неудачными конструкциями в Java исчезнет сама собой.
Более того, один и тот же проект может иметь код как на Java, так и на Kotlin (то есть файлы могут соседствовать).
Как минимум, в том, что:
Запросто будет нестандартное API от другой команды, а интегрироваться необходимо.
Выбор библиотек зависит не только от разработчика, но и от департамента (как минимум).
Выбор того, что делать, зависит не от автора, а от заказчика (внутреннего или внешнего).
Есть ненулевая вероятность поработать с legacy.
Сроки более хитрые - они жесткие для определенных вещей, и гибкие для других.
Если посмотреть вакансии банков, то 99% разработчиков вообще не будут даже близко касаться таких нишевых технологий. Другими словами, будет стандартный стек как в самой команде, так и в соседних с ней.
Но логично, что, если взять достаточно большую компанию, которая на рынке не один десяток лет, то в ней можно будет найти подобную систему, ибо vendor lock-in случается. Мне казалось, что фирмы стараются уходить от такого, ибо это повышенный риск (в терминологиях банков).
Про выгорание я специально написал. Люди разные, так что кто-то выгорит и с шести часов работы (активная фаза будет короче, конечно), а кто-то и 9 сможет выдерживать.
Плюс ещё коллективы разные, как и преемственность опыта. Я уж не говорю про то, что разные технологии вызывают разное отношение к процессу.
А как же open source и подобные инициативы (включая статьи на хабре)?
Для себя (но я не настаиваю и таком способе мысли) я заметил, что на работе люди получают компенсацию и опыт, который тает с каждым годом. А потому, больше работы - больше опыта.
Но, конечно же, не стоит забывать как о разного рода выгораниях, так и о других подобных последствиях.
Да, Вы полностью правы, я забыл написать стандартное предложение, что не стоит радикализировать моё утверждение.
Понятно, что бывают ситуации, что человек так и так будет жить недалеко от работы, так как супруг/супруга не могут работать удаленно. Плюс бывают ситуации, которые усложняют смену жилья на более удобное (с кабинетом и так далее). Бывают также ситуации, когда домашние не сильно проникаются эмпатией к работающему из дома.
Заодно я сразу скажу, что удаленка подходит не всем офисным сотрудникам. Некоторым юристам запрещено выносить бумаги из офиса, а у трейдеров рабочее место регламентировано строгими законами (которые не сильно одобряют ситуацию, когда муж и жена работают в разных банках, но на схожих позициях, так что, по сути, каждый видит котировки другого банка).
Ничего. Человек проигнорирует её в любом случае. Просто более проактивный (в хорошем смысле слова) скорее будет эффективным и дома (создаст комфортные условия и так далее), тогда как более пассивный дома найдет больше способов увильнуть от работы.
Только не стоит на это строго и догматично смотреть, я бы это списал на корреляцию.
Да, всё верно, бывают ограничения. Они же помешают найти работу другом городе (пусть даже в том же штате), кстати говоря.
Продажа и покупка жилья займет около полугода, если цена установлена рыночная и стороны не торопятся. Да и смена школы тоже возможно (но да, тут будут сложности).
С учетом того, что гибридный режим уже 2-3 года (зависит от ситуации), скорректировать жилье уж точно можно. Я уж не говорю про то, что не все жестко прикреплены к квартире/дому.
А можно попросить поподробнее описать сценарий? Насколько я знаю, некоторые серверы (BitBucket, GitHub) имеют настройку "ветка должна быть после rebase", то есть смержить можно будет только если 100% коммитов из мастера присутствуют в ветке с новыми изменениями. И да, это уже реализации серверов, а не просто git клиент.
Я подозреваю, что Вы имеете ввиду что-то другое. А какой сценарий требуется?
Мы же про АйТи говорим, верно? Это вполне себе стандартный подход, по факту-то.
Вроде, стандартный пост про собеседования имеет пару веток про "стоит знать хотя бы базовые и простейшие алгоритмы, или и так сойдет?", что неплохо обосновывает популярность подхода "я знаю в своей узкой области, а дальше не смотрю, пока серьезно не попросят".
Эта цена аренды работает в условном часе езды от офисной зоны. Если же работать 1-2 раза в неделю в офисе, то можно жить и в 1.5 часе езды.
Не совсем. Ряд задач намного удобнее решать оффлайн, когда люди в одной комнате, да еще и с маркерной доской. Язык тела тоже никто не отменял, так что разговаривать на чувствительные темы проще с глазу на глаз, а не через видеоконференцию.
Более того, лично у меня было много случаев, когда опытные люди принципиально не могли договориться с помощью email/видеозвонков, но быстро приходили к пониманию в переговорке. Последнее очень важно, так как долгие споры сильно затягивают разработку (особенно, если любой из вариантов решит задачу, но группа людей вживую демонстрируют мысленный эксперимент про Буриданова осла).
Ваше описание - это отличное подтверждение прошлых исследований, что удаленка (а, точнее, гибридный график в стиле "один день в офисе, две недели дома) оказывается очень эффективна для высококвалифицированных и мотивированных людей, однако она же сказывается негативно на людей с малым объемом опыта, а также на тех, кто не хочет работать (и ищет способы этого не делать).
Можно даже попытаться сделать корреляцию с другим поведением. Если, при видя ошибки в чужой библиотеке, вы уведомите создателя (внутри компании, или же на GitHub), то и удаленка для Вас будет более эффективна.
Если же дополнительная задача "уведомить" будет проигнорирована (зачем что-то делать, если можно не делать? Мы же в айти только ради денег, а подобный поход к коллеге только отнимет рабочее время), то и удаленка скажется только негативно на таком сотруднике.
Как слабое свидетельство этого - успех open source, где нередко бесплатное открытое решение работает намного лучше платного и закрытого (но не всегда, конечно, особенно, если речь касается UX).
Это очень похоже на ложную дихотомию. Вы бы ещё спросили: «вам код или умение общаться требуется»?
Ещё в мифическом человекомесяце было описано, почему разница в производительности между специалистами в АйТи запросто достигает десятка раз.
Без проблем, такое бывает в реальности. Самый типичный пример - бывший тимлид, который последние N лет занимался только ревью кода, а до этого был крепким мидлом, но который идёт на должность сеньор разработчика в более серьёзную фирму.
Другой вариант - человек, работающий на смежной с программированием должности в реальности.
Третий вариант - человек, проработавший над той же самой системой N лет, да ещё и в одиночку.
«Публикации» тут помогут слабо, так как не всегда известно, насколько человек сам всё делал, а насколько пересказывал. В резюме может быть схожая схема - никто не мешает приукрасить ситуацию.
Но конкретные примеры (с именами) я приводить не буду, ибо это неэтично.
Автор книг не всегда является серьёзным профессионалом. Более того, автор книг для начинающих будет обладать навыками объяснения простых задач джунам, но не факт, что у него будет опыт решения более серьезных вещей.
Этому есть косвенное подтверждение - я не думаю, что многие возьмут человека со статьями на хабре в обход собеседований. И само наличие этих собеседований доказывает, что компания считает вероятность их провала далеко не нулевой.
Если говорить про похожие вещи у поваров, то есть отличный пример - Джеймс Оливер, который прославился книгами и телепередачами, тогда как ресторанный бизнес у него слегка прогорел.
Это слишком примитивный алгоритм, чтобы выдавать его за "знание". Его в школах изучают, ну или на первых курсах, но даже там эта задача слишком простая, чтобы она попала в те же экзаменационные билеты.
И это отличная проверка на то, что человек может выразить примитивные вещи в коде.
Исходные данные корректны (разве что не хватает деталей по поводу "супер" - оценка базируется по красивому резюме или по наличию, например, премии Тьюринга?)
Для ответа на этот вопрос создаем интервью
Эксперимент был поставлен, результаты были выявлены. Вывод: или эксперимент неудачен (например, человек был усталый, задачи были на css, несмотря на опыт в C++ и так далее), или же исходный тезис "нужно отрывать с руками".
Суть лайвкодинга (и процесса интервью) не в симуляции рабочих условий, а в определении уровня кандидата с наименьшей ошибкой (ложноположительной, ложноотрицательной и так далее).
Например, если оценка профиля на гитхабе позволяет уменьшить ошибку, то компании будут его смотреть, даже несмотря на то, что в работе гитхаб не используется.
Если вопросы о предыдущих местах и опыте позволяют уменьшить ошибку, то их будут задавать, даже если в реальной работе они подниматься не будут.
Лайвкодинг позволяет очень хорошо отсеять теоретиков: как новичков, которые заучили ответы, так и тимлидов, которые последние N лет не пишут код, а занимаются "управлением", "ревью кода" и пр., но которые подаются на должность "синьор программиста".
И да, такой подход может давать ошибки, если собеседующий делает сильные ограничения в стиле "используем строго регулярные выражения", "строго Java 11" или "пишем самый идеальный в мире код". Ну и, конечно же, бывают неудачные дни, так что собеседующий должен обладать определенной эмпатией.
А что с Японией и с Германией? Какие на них санкции наложили?
Разве Китай не создавал серьезные барьеры в импорте-экспорте путем массовых блокировок в информационной сфере, путем запрета экспорта тех же редкоземельных металлов и так далее?
Если Вы используете JVM, то можно писать код на Kotlin. Результатом будет тот же байт-код, а проблема с неудачными конструкциями в Java исчезнет сама собой.
Более того, один и тот же проект может иметь код как на Java, так и на Kotlin (то есть файлы могут соседствовать).