Мне кажется, если приближать алгоритмические задачи к реальной работе, то нужно, как минимум, давать пользоваться поиском. А потом уже найденное решение обсуждать и крутить и вертеть.
Так как в обычной практике, обобщая свой опыт, решение задачи будет выглядеть как:
Посмотреть в стандартной библиотеке
Посмотреть в библиотеке компании (скорее всего со временем такая появляется у всех)
Поискать сторонние библиотеки, которые production ready
Для тех редких случаев, когда перавые три пункта не помогли, то поискать описание реализации алгоритма и использовать его как есть или адаптировать под проект.
И, практически вымирающий вид, когда есть сложная задача, которую никто не решал и нужно с нуля выдумать алгоритм.
Кажется, если человек не готовился к алгоритмам или не увлекается ими, то на собеседовании в текущем виде он попадает в эту редкую последнюю категорию.
А если дать возможность искать решение, то приближаем собеседование к обычной рабочей обстановке и можно смотреть как человек себя ведет, как ищет решение, как адаптирует его к проекту и к изменениеям условий, насколько понимает что тащит в проект и т д.
Думаю, это будет не менее информативно, чем то что в текущем виде, но зато лишает смысла "задрачивать литкод" перед собеседованием.
П.С. не спорю, что есть ниши, где знание сложных алгоритмов и/или математики просто мастхев и каждодневные обязанности, но не уверен что даже в FAANG это нужно для большинства инженеров.
Только для большинства проектов "Уметь за сжатый срок написать оптимизированный код с хорошей асимптоматикой для сложной алгоритмической задачи" будет нишевой задачей, так как все популярные алгоритмы, которые регулярно нужны уже реализованы в стандартной библиотеке или в сторонней, а за написание своих велосипедов без острой обоснованной необходимости нужно бить по рукам.
Конечно, бывает что нужно свою версию написать, но это достаточно редко нужно, чтобы под это затачивать собеседование и ориентироваться как на основной навык.
Убили как-то друг друга программист компьютерной графики и фронтенд-разработчик, споря о том, должен ли программист отлично знать линейную алгебру. Попадают к апостолу Петру и просят рассудить:
– Апостол Пётр, – говорит программист компьютерной графики, – я не выдержал и стал душить его, макаку вебную, ожидая, что он согласится со мной.
– Нет, это я не стерпел и стал душить его, олимпиадника сутулого, ожидая, что он согласится со мной, – перебил фронтенд-разработчик.
Не выдержав, программисты снова сцепились.
– Лучше бы вы дедлоков избегали... – проворчал Пётр.
Во, оказывается я не одинок. Тоже давно, еще до бума жпт ботов заметил, что сначала читаю заголовок, если он интересен иду в комментарии, а если по комментриям статья стоящая, то читаю ее. Но чаще останавливаюсь на комментариях.
Я сейчас регулярно езжу на такси и хожу в кафе и рестораны и в целом не сказать что ограничениваю себя. Но вот действительно, удовольствие это уже особо не приносит, особенно как раньше, когда такое было целым событием.
Стал я от этого несчастным? Вряд ли. Сильно счастливым? Наверное нет, просто уровень забот и проблем увеличился. А уровень счастья примерно одинаковый.
Это мне напоминает закон убывающей ценности чем-то.
Собственно, а зачам наизусть учить весь зоопарк библиотек любого языка? Программировать без доступа к документации - это прям очень специфичные условия работы. А то что регулярно и каждодневно используется и так останется на кончиках пальцев.
Похожее, поэтому я люблю больше заниматься процессами, архитектурой и большими задачами, которые требуют от месяца-двух на реализацию.
А когда изредка нужны какие-то не повседневные алгоритмы, которых нет ни в стандартной библиотеке, ни в production ready сторонних библиотеках, то расчехляю интернет, закрома памяти по алгоритмам и смотрю как реализовать.
Так что я успешно работаю, но практически уверен что завалю алгоритмические собеседования, а чтобы не завалить, нужно прям отдельно месяц-три сидеть каждый день и руку набивать.
Лично у меня за время работы вышло эмпирическое правило, что максимум сконцентрированного времени в день без ущерба для всего остальнго - это часа 4 в день. Бывают состояния потока, когда и 8 часов просижу, но обычно после этих 8 часов чувствую себя выжатым лимоном, не функциональным и хочу только лежать и ничего не делать.
Поэтому стараюсь искать только на 4 часа максимально изолированное, не отвлекающее место. Обычно это отдельная комната в доме, но когда жили в однушке, то и коворкинг справлялся с этой задачей.
А оставшиеся 4 часа уже могу в разных условиях проводить и на них стараюсь ставить дела, не требующие концентрации: звонки рутинные, планировение рутинное, коммуникацию в рабочем чате и прочие нужные для работы вещи.
Спасибо, именно это я и имел в виду, что преждевременная оптимизация - корень всех зол.
Одно дело, если бы решение нужно было бы переписывать сразу или же через пару месяцев после них, тогда да, как в примере комментария о трубах - решение не рабочее и не годится.
Но вот если оно работало несколько лет и справлялось со своей задачей - то все нормально. Скорее всего справлялось бы и дальше, если бы не сменились требования.
Если предыдущее решение, судя по всему, успешно работало несколько лет, то значит оно подходящее. Скорее всего его было легко создать и не заняло много времени и те разработчики освободилась для новых задач.
А сейчас, через несколько лет, нагрузка выросла (и скорее всего и бизнес) и узкие места стали проблемными. Но это нормально, что только сейчас их переписывают более оптимальным способом.
Почему-то о государстве иногда говорят как об отдельной сущности, со своей мотивацией, желанием, волей и прочими аттрибутами одушевленной сущности. Но её нет. Поэтому, как мне кажется, правильнее говорить интересы власть имущих. Тогда получается конфликт интересов между гражданами и власть имущими людьми и все встает на свои места :)
Да, тоже такая же тема была, что несколько часов уходило на ответ. Но в целом считаю это имеет право на жизнь на собеседованих: если спрашивать задания тестовые на кодинг, особенно алгоритмические, то давать возможность пользоваться интернетом. А потом уже от итогового решения отталкиваться и разговаривать. Если человек без опыта, то просто скопирует и ничего не сможет не пояснить, ни поменять толком, ни прикинуть сложность. Из общения будет многое понятно.
В университете у нас был преподаватель, который на экзамене давал пользоваться открыто всем чем угодно: конспектами, лекциями, книгами и интернетом. Принцип простой: предмет сложный и если человек не готовился к предмету заранее, то на экзамене за пару часов ничего не вымучает.
Мне кажется, этот принцип работает и с интервью на позицию инженера. Да и приближено к работе.
Ну, тут дедлоки были про несколько другое (:
Мне кажется, если приближать алгоритмические задачи к реальной работе, то нужно, как минимум, давать пользоваться поиском. А потом уже найденное решение обсуждать и крутить и вертеть.
Так как в обычной практике, обобщая свой опыт, решение задачи будет выглядеть как:
Посмотреть в стандартной библиотеке
Посмотреть в библиотеке компании (скорее всего со временем такая появляется у всех)
Поискать сторонние библиотеки, которые production ready
Для тех редких случаев, когда перавые три пункта не помогли, то поискать описание реализации алгоритма и использовать его как есть или адаптировать под проект.
И, практически вымирающий вид, когда есть сложная задача, которую никто не решал и нужно с нуля выдумать алгоритм.
Кажется, если человек не готовился к алгоритмам или не увлекается ими, то на собеседовании в текущем виде он попадает в эту редкую последнюю категорию.
А если дать возможность искать решение, то приближаем собеседование к обычной рабочей обстановке и можно смотреть как человек себя ведет, как ищет решение, как адаптирует его к проекту и к изменениеям условий, насколько понимает что тащит в проект и т д.
Думаю, это будет не менее информативно, чем то что в текущем виде, но зато лишает смысла "задрачивать литкод" перед собеседованием.
П.С. не спорю, что есть ниши, где знание сложных алгоритмов и/или математики просто мастхев и каждодневные обязанности, но не уверен что даже в FAANG это нужно для большинства инженеров.
Только для большинства проектов "Уметь за сжатый срок написать оптимизированный код с хорошей асимптоматикой для сложной алгоритмической задачи" будет нишевой задачей, так как все популярные алгоритмы, которые регулярно нужны уже реализованы в стандартной библиотеке или в сторонней, а за написание своих велосипедов без острой обоснованной необходимости нужно бить по рукам.
Конечно, бывает что нужно свою версию написать, но это достаточно редко нужно, чтобы под это затачивать собеседование и ориентироваться как на основной навык.
Убили как-то друг друга программист компьютерной графики и фронтенд-разработчик, споря о том, должен ли программист отлично знать линейную алгебру. Попадают к апостолу Петру и просят рассудить:
– Апостол Пётр, – говорит программист компьютерной графики, – я не выдержал и стал душить его, макаку вебную, ожидая, что он согласится со мной.
– Нет, это я не стерпел и стал душить его, олимпиадника сутулого, ожидая, что он согласится со мной, – перебил фронтенд-разработчик.
Не выдержав, программисты снова сцепились.
– Лучше бы вы дедлоков избегали... – проворчал Пётр.
Во, оказывается я не одинок. Тоже давно, еще до бума жпт ботов заметил, что сначала читаю заголовок, если он интересен иду в комментарии, а если по комментриям статья стоящая, то читаю ее. Но чаще останавливаюсь на комментариях.
Я сейчас регулярно езжу на такси и хожу в кафе и рестораны и в целом не сказать что ограничениваю себя. Но вот действительно, удовольствие это уже особо не приносит, особенно как раньше, когда такое было целым событием.
Стал я от этого несчастным? Вряд ли. Сильно счастливым? Наверное нет, просто уровень забот и проблем увеличился. А уровень счастья примерно одинаковый.
Это мне напоминает закон убывающей ценности чем-то.
Ну в смысле там должна храниться информация о тех кто рождается и умирает.
Но вы правы, это учитывает только изменения численности по рождению/смерти и не учитывает миграцию.
Пересечения границы скорее всего тоже хранятся в базах, но погранслужбы. Возможно это решает вопрос с выездом.
Но вот передвижения внутри страны не будут учитываться.
Я думаю, регионы были бы рады, если бы хотя бы НДС снова оставался большей части в самом регионе, а не шел 100% в федеральный бюджет
А разве информация о численности населения не хранится в ЗАГСе?
Элементарный в использовании не означает элементарный в реализации.
Собственно, а зачам наизусть учить весь зоопарк библиотек любого языка? Программировать без доступа к документации - это прям очень специфичные условия работы. А то что регулярно и каждодневно используется и так останется на кончиках пальцев.
Похожее, поэтому я люблю больше заниматься процессами, архитектурой и большими задачами, которые требуют от месяца-двух на реализацию.
А когда изредка нужны какие-то не повседневные алгоритмы, которых нет ни в стандартной библиотеке, ни в production ready сторонних библиотеках, то расчехляю интернет, закрома памяти по алгоритмам и смотрю как реализовать.
Так что я успешно работаю, но практически уверен что завалю алгоритмические собеседования, а чтобы не завалить, нужно прям отдельно месяц-три сидеть каждый день и руку набивать.
Лично у меня за время работы вышло эмпирическое правило, что максимум сконцентрированного времени в день без ущерба для всего остальнго - это часа 4 в день. Бывают состояния потока, когда и 8 часов просижу, но обычно после этих 8 часов чувствую себя выжатым лимоном, не функциональным и хочу только лежать и ничего не делать.
Поэтому стараюсь искать только на 4 часа максимально изолированное, не отвлекающее место. Обычно это отдельная комната в доме, но когда жили в однушке, то и коворкинг справлялся с этой задачей.
А оставшиеся 4 часа уже могу в разных условиях проводить и на них стараюсь ставить дела, не требующие концентрации: звонки рутинные, планировение рутинное, коммуникацию в рабочем чате и прочие нужные для работы вещи.
Спасибо, именно это я и имел в виду, что преждевременная оптимизация - корень всех зол.
Одно дело, если бы решение нужно было бы переписывать сразу или же через пару месяцев после них, тогда да, как в примере комментария о трубах - решение не рабочее и не годится.
Но вот если оно работало несколько лет и справлялось со своей задачей - то все нормально. Скорее всего справлялось бы и дальше, если бы не сменились требования.
Если предыдущее решение, судя по всему, успешно работало несколько лет, то значит оно подходящее. Скорее всего его было легко создать и не заняло много времени и те разработчики освободилась для новых задач.
А сейчас, через несколько лет, нагрузка выросла (и скорее всего и бизнес) и узкие места стали проблемными. Но это нормально, что только сейчас их переписывают более оптимальным способом.
Почему-то о государстве иногда говорят как об отдельной сущности, со своей мотивацией, желанием, волей и прочими аттрибутами одушевленной сущности. Но её нет. Поэтому, как мне кажется, правильнее говорить интересы власть имущих. Тогда получается конфликт интересов между гражданами и власть имущими людьми и все встает на свои места :)
Да, тоже такая же тема была, что несколько часов уходило на ответ. Но в целом считаю это имеет право на жизнь на собеседованих: если спрашивать задания тестовые на кодинг, особенно алгоритмические, то давать возможность пользоваться интернетом. А потом уже от итогового решения отталкиваться и разговаривать. Если человек без опыта, то просто скопирует и ничего не сможет не пояснить, ни поменять толком, ни прикинуть сложность. Из общения будет многое понятно.
Ещё одно подтверждение тезиса, что политические проблемы техническими средствами не решить
В университете у нас был преподаватель, который на экзамене давал пользоваться открыто всем чем угодно: конспектами, лекциями, книгами и интернетом. Принцип простой: предмет сложный и если человек не готовился к предмету заранее, то на экзамене за пару часов ничего не вымучает.
Мне кажется, этот принцип работает и с интервью на позицию инженера. Да и приближено к работе.
Его можно отключить без ущерба для важных звуков :)