но забудет (или будет не в состоянии) понять что библиотека, которой он пользуется замедляется при удлинении подстрок, не ускоряется?
Ну вообще, я бы в любом случае не доверял теории, а написал benchmark'и и протестировал все библиотеки на разных конфигурациях компьютера и разных длинах строк. Дело в том что теория это хорошо, но практика лучше, так как скажем в Java замечательный в теории метод может создавать огромное количество временных объектов. что будет постоянно вызывать сборщик мусора и в результате метод окажется хуже не такого замечательного в теории метода.
Метазнание тоже можно выучить при необходимости, тут главное чтобы было понимание что если задача про графы, а ты про них ничего не знаешь, то нужно потратить пару часов и прочитать разные алгоритмы графов. Учитывая что такие задачи у многих появляются раз в полгода это оправданая трата времени. Хуже когда программист самоуверенно пытается придумать все сам. Тем более что появляются новые алгоритмы и метазнание 3-5 летней выдержки может быть уже не актуальным.
Мое мнение знать самые основы алгоритмов — нужно: что такое O(n), бинарный поиск, хеш таблицы. Без этого вы не сможете понимать как работает индекс в базе данных или как работает HashMap'а в Java, когда ArrayList лучше LinkedList'a. Это равносильно пользоваться ООП или реляционными базами данными не понимая SQL или полиморфизма. Можно, но будут проблемы с пониманием элементарных вещей и общением с коллегами (если не сможете понять объяснения про O(n) являясь старшим программистом на вас будут смотреть странно). Ну и в конце концов чем же занимались в универе, если грубо говоря высшую математику выучили, а таблицу умножения забыли.
А вот знать наизусть точный алгоритм красно-черного дерева или десяток алгоритмов обхода графой — полезно, но не обязательно. Так как в реальной работе встречается это редко и проще открыть вики (или другой источник) и повторить знания, чем пытаться писать по памяти с риском ошибиться.
ИМХО, не состоит, покер-румы, всякие форбсы и биржы развивают игроманию, да и считающих что он самый хитрый и умный там каждый первый. Да, кто-то умудряется делать на этом деньги, но чтобы кто-то делал деньги кто-то должен их потерять, поэтому активно зазывают новичков в такие игры. В общем, на мой взгляд не стоит тратить на это время и деньги.
Scala — продвигается в основном теми, кому стала тесна Java, а посему всегда будет вторична к ней.
Не обязательно, Java тоже продвигалась теми кому стал тесен C++, в принципе Scala или Kotlin могут со временем заменить Java по принципу та же Java, только лучше. Я бы поставил на Kotlin, ИМХО.
после службы у меня осталось именно такое впечатление
Эхх, как человек два года, отслуживший офицером (по призыву), могу сказать мнение с другого лагеря — быть офицером, ответственным за личный состав (взвод/роту), считается среди офицеров самой собачей работой: за каждый косяк каждого солдата отвечаешь лично ты, ушел солдат в самоволку и нарвался там на нож гопников — виноват офицер, случай суицида — виноват офицер, не дай бог ночью покалечился из-за драки или дедовщины — виноват офицер, всегда. Даже при том что он физически не мог круглые сутки сидеть в казарме и следить за тремя десятками человек.
Когда трем десяткам молодых пацанов нечего делать — они начинают страдать дурью, а как начинают страдать дурью — шанс покалечится или покалечить товарища резко возрастает. В результате, офицеру приходится быть "гадом" и следовать правилу "хороший солдат — за… мученный солдат", просто чтобы не "сесть" самому и не отвечать перед матерями за их сыновей.
P.S. Это не значит, что среди командиров нет "быдла", но часто они "гады" просто потому что иначе не получается… P.P.S. Сам за солдат, к счастью, практически не отвечал, дежурные в нарядах не в счет, пишу со слов старших офицеров-коллег с огромным опытом.
айтишник справлялся с таким проявлением армейской жизни как дедовщина
Служил, когда ещё служили по два года, сталкивался со страшными проявлениями дедовщины — старшие офицеры заставляли разливать водку/пиво и "арендовали" мой пистолет на стрельбах, чтобы свои не чистить. :) Правда, и это закончилось через полгода, когда я получил старлея и уже не был младшим по званию/возрасту. Повезло, что попал в военный институт и сразу зачислили программистом, ну и служил после военной кафедры офицером, с относительно нормальной зар.платой, отпусками и почти теми же льготами что у офицеров-контрактников.
Я не совсем понимаю как в таком случае происходит защита от списывания, кто мешает повесит на стену за монитором шпаргалки или попросит приятеля, который вне действия камеры писать правильные ответы на листке бумаги или искать ответ в гугле и показывать его на планшете? Или от студента требуется показывать камерой всю комнату? Или тест такой что это все равно не поможет, если студент не знает ответов?
вначале он должен быть хорошим программистом. А всё остальное — уже потом
В большинстве случаев это так, хотя знаю несколько компаний, которые под должностью senior'a программиста подразумевали частичное или почти полное исполнение роли архитектора, тим.лида, аналитика, технического менеджера (это не тоже самое что тим.лид, хотя часто путают), иногда даже project manager'a. Должен ли, архитектор или технический менеджер отлично знать базовые алгоритмы… не знаю, вопрос сложный, как должен ли профессор математики идеально считать в уме простые арифметические задачи. Но я бы не сказал, что эти роли совсем незначительные плюшки senior'a для данных компаний, скорее наоборот ключевые…
И вы всерьёз предлагаете описать систему, которая это учитывает, на собеседовании, без подготовки?
Нет, не предлагаю. Никто не просит реальное решение, тут хочется просто понять как человек размышляет, не более того. Кто-то для подобной задачи начнет рисовать архитектуру и рассказывать из каких частей будет система, кто-то будет строить модель, кто-то придумывать хитрые алгоритмы, кто-то рассказывать какую базу и фреймворки возьмет и почему. Важен не результат, а процесс.
Конечно, но никто же не предлагает нанимать человека по ответу на один вопрос. При таком ответе следующий вопрос будет про что-то более конкретное с его реальными обязанностями по написанию кода. Как вариант, дать код джуниора/мидала и попросить сделать code review и как бы он его переписал. Обычно в таком случае быстро становится понятно как у человека с кодированием.
P.S. Кстати, знания алгоритмов на память как раз в реальной работе не всякому программисту нужны, а когда нужны ему достаточно открыть инет. Нет, если более 50% времени программисту требуется писать хитрые алгоритмы — тогда вопросов нет, а если 0.5%? Тогда важнее умение писать свой код и читать чужой.
Отсеивать людей из-за отсутствия жизненного (не профессионального) опыта, конечно, можно, но это никак не связано с их профессиональными качествами.
Прочитайте выше, никто не говорит отсеивать. Если человек просто реализует алгоритм поиска это решение, которое можно обсуждать и пощупать (и спросить почему именно этот алгоритм, а не другой, какие у него плюсы и минусы). Это показывает хорошие навыки кодирования и меньшую склонность к аналитике.
Если человек предложит, например, сделать мобильное приложение, которое будет собирать данные разных пользователей, а потом с помощью машинного обучения выдавать прогнозы на появление пробок/аварий/ремонтов другим пользователям — это другое решение, показывающее большую креативность.
Решений любой реальной задачи может быть много и по тому как человек её решает и как он размышляет можно понять как он будет решать другие задачи и, например, есть ли у него склонность к анализу или нет, к построению своих велосипедов или использование чужих решений. У реальной задачи никогда нет одного правильного решения, иногда вместо огромной системы достаточно формул в Excel файле или чего-то подобного. Важно как человек ищет решение, а не само решение.
Это важно для того чтобы понимать как использовать работника в будущем, если вы набираете не просто винтики в систему/манки кодеров, а специалистов.
Я могу быть не в курсе. Например, если я последний раз пользовался общественным транспортом пять лет назад. Или если я из другой страны.
Можете. И вполне можете забыть, что совсем элементарное вроде как в Java найди вхождение подстроки в строку. Все помнить, а вот это забыть и именно это спросят. В жизни всякая фигня случается, никто не сможет угадать кто и когда что не знает/забудет.
Может быть вы в инете никогда инет магазин не видели, а тут вам задание сделать реализацию личного кабинета в инет магазине… Увы, никто не может влезть в вам в голову и понять что мы можете не знать. Жизнь, увы, не справедлива.
Потом я не говорил, что если бы мне описали крутой алгоритм поиска оптимального пути это был бы провал. Это тоже решение просто показывающее, что человек склонен не к аналитике, а к алгоритмам.
для этого уже надо додумать, что в задаче что-то не указано.
Да, а когда аналитик дает вам требования надо додумать, что будет «если человек сажающий деревья заболеет».
Тогда откуда вы знаете про час пик, или про то, что транспорт может не ходить в определенное время?
А вы не в курсе, что в вашем городе бывает час пик или о том что транспорт не ходит круглые сутки? Или есть кто-то, кто об этом не знает? Я понимаю, если бы вопрос был про оптимизацию онлайн рекламы, тогда можно говорить о не знании предметной области, но уж элементарные знания жизни в городе есть у всех.
Очень опасно подменять умение думать умением додумывать.
Нет, просто прежде чем додумывать, нужно задать вопрос, а так ли это на самом деле.
И некоторые вещи проще «видеть» в коде (пусть и псевдо), нежели на пальцах объяснять.
Проще, но для этого не требуется спрашивать хитрые алгоритмы, можно дать комп, IDE и возможность гуглить с простой задачей из тех что встречаются в работе постоянно. А через полчаса-час посмотреть какой код у кандидата получился в результате. Это будет честнее и проще, чем смотреть как кандидат копипастит из памяти алгоритм быстрой сортировки, который выучил специально перед собеседованием.
Не уверен, хороший senior всегда должен быть немного аналитиком, немного архитектором, немного тимлидом, немного тестером. Конечно, необязательно на уровне каждого из специалистов, но без определенных навыков аналитика, архитектора и тестера, вряд он может считаться хорошим senior'ом.
Ок, ну дайте вполне конкретную задачу под конкретного специалиста: если вы ищете php разработчика — нужно сделать такой-то сайт с такими требования, вы можете выбирать любые технологии и Фреймворки, расскажите по шагам от настройки вебсервера до настройки Фреймворков чтобы вы делали, сколько времени вам потребовалось на том или ином этапе, какие проблемы по вашему могли бы возникнуть на каждом этапе, по каким критериям вы выбрали тот или иной фреймворк/технологию/решение и т.д.
Или это тоже слишком сложно для опытного программиста описать как он бы сам сделал хотя бы простой проект самостоятельно? Тогда как такой программист может называть себе senior'ом, если не способен сделать простой проект по своей специализации от начала и до конца (или хотя бы описать как бы он сделал)?
Если вы думаете, что предметная область построения маршрутов для общественного транспорта всем хорошо известна, то вы зря так думаете.
Мне она тоже совершенно неизвестна, в задаче не требуется ничего кроме как умения думать. А вот знания алгоритма Дийкстры умения подумать не покажет.
Не хотите, задач с предметной областью, спросите у программиста, занимающийся интеграцией, как бы он писал интеграцию с определенным сервисом, как обрабатывал данные, ошибки и т.п., по шагам, просто с размышлениям, использовал ли он бы базы и orm или работа в памяти, как бы парсил, каким образом получал бы данные с сервиса. Если это senior программист, а не просто кодер, это будет сразу видно.
от программиста ожидают выполнения бизнес-анализа
От опытного программиста ожидают умения думать, а не тупо кодировать по паттернам. Если это считать это бизнес-анализом, ну может быть…
Это, на минуточку, задача аналитика, а не программиста.
Нет, хороший программист не должен рассчитывать, что аналитики дадут ему идеальный дизайн, архитекторы придумают идеальную архитектуру системы, а тестеры идеально найдут все его косяки.
В первую очередь, он должен думать, если что будет в час пик, а что будет если пользователь поедет в то время когда половина транспорта уже не ходит. И если, аналитик об этом не подумал и не написал в требованиях (что бывает почти в каждом проекте, мелкие косяки в требованиях бывают почти всегда), то подумать самому и задать вопрос аналитику/клиенту. Иначе постоянно будут ситуации когда один работник вырывает ямки, а второй их закапывает, потому что аналитик забыл предусмотреть ситуацию «работник, который должен сажать деревья, заболел», а программист сделал бездумно.
Да, не алгоритм в такой задаче главное. Для начало, подумает ли кандидат что такое оптимальный маршрут с точки зрения пользователя (наиболее быстрый, с меньшим кол-вом пересадок, самый дешевый, с наименьшим ожиданием транспорта на остановки), учтет что в реальной жизни оптимальный маршрут в час пик будет совсем другим, или если пользователь собирается выйти в 10 вечера транспорт по самому идеальному маршруту он будет ждать до утра.
Потом, если кандидат скажет, что для данной задачи он знает замечательную библиотеку Васи Пупкина, которая отлично ищет идеальный путь в графе, а он просто оптимизирует её для учета пересадок, расписаний транспорта и стоимости проезда — это тоже будет корректным решением. Причем в некотором виде более предпочтительным, так как покажет что кандидат прежде чем делать велосипед, использует уже готовый открытый код. Обратите внимание, в условие задачи нет требования напишите свой велосипед, а именно как вы решили бы эту задачу. И, естественно, задачи должны быть близки к тем что ему придется решать в боевых условиях.
Ну вообще, я бы в любом случае не доверял теории, а написал benchmark'и и протестировал все библиотеки на разных конфигурациях компьютера и разных длинах строк. Дело в том что теория это хорошо, но практика лучше, так как скажем в Java замечательный в теории метод может создавать огромное количество временных объектов. что будет постоянно вызывать сборщик мусора и в результате метод окажется хуже не такого замечательного в теории метода.
Метазнание тоже можно выучить при необходимости, тут главное чтобы было понимание что если задача про графы, а ты про них ничего не знаешь, то нужно потратить пару часов и прочитать разные алгоритмы графов. Учитывая что такие задачи у многих появляются раз в полгода это оправданая трата времени. Хуже когда программист самоуверенно пытается придумать все сам. Тем более что появляются новые алгоритмы и метазнание 3-5 летней выдержки может быть уже не актуальным.
А вот знать наизусть точный алгоритм красно-черного дерева или десяток алгоритмов обхода графой — полезно, но не обязательно. Так как в реальной работе встречается это редко и проще открыть вики (или другой источник) и повторить знания, чем пытаться писать по памяти с риском ошибиться.
ИМХО, не состоит, покер-румы, всякие форбсы и биржы развивают игроманию, да и считающих что он самый хитрый и умный там каждый первый. Да, кто-то умудряется делать на этом деньги, но чтобы кто-то делал деньги кто-то должен их потерять, поэтому активно зазывают новичков в такие игры. В общем, на мой взгляд не стоит тратить на это время и деньги.
Не обязательно, Java тоже продвигалась теми кому стал тесен C++, в принципе Scala или Kotlin могут со временем заменить Java по принципу та же Java, только лучше. Я бы поставил на Kotlin, ИМХО.
Эхх, как человек два года, отслуживший офицером (по призыву), могу сказать мнение с другого лагеря — быть офицером, ответственным за личный состав (взвод/роту), считается среди офицеров самой собачей работой: за каждый косяк каждого солдата отвечаешь лично ты, ушел солдат в самоволку и нарвался там на нож гопников — виноват офицер, случай суицида — виноват офицер, не дай бог ночью покалечился из-за драки или дедовщины — виноват офицер, всегда. Даже при том что он физически не мог круглые сутки сидеть в казарме и следить за тремя десятками человек.
Когда трем десяткам молодых пацанов нечего делать — они начинают страдать дурью, а как начинают страдать дурью — шанс покалечится или покалечить товарища резко возрастает. В результате, офицеру приходится быть "гадом" и следовать правилу "хороший солдат — за… мученный солдат", просто чтобы не "сесть" самому и не отвечать перед матерями за их сыновей.
P.S. Это не значит, что среди командиров нет "быдла", но часто они "гады" просто потому что иначе не получается…
P.P.S. Сам за солдат, к счастью, практически не отвечал, дежурные в нарядах не в счет, пишу со слов старших офицеров-коллег с огромным опытом.
Служил, когда ещё служили по два года, сталкивался со страшными проявлениями дедовщины — старшие офицеры заставляли разливать водку/пиво и "арендовали" мой пистолет на стрельбах, чтобы свои не чистить. :) Правда, и это закончилось через полгода, когда я получил старлея и уже не был младшим по званию/возрасту. Повезло, что попал в военный институт и сразу зачислили программистом, ну и служил после военной кафедры офицером, с относительно нормальной зар.платой, отпусками и почти теми же льготами что у офицеров-контрактников.
В большинстве случаев это так, хотя знаю несколько компаний, которые под должностью senior'a программиста подразумевали частичное или почти полное исполнение роли архитектора, тим.лида, аналитика, технического менеджера (это не тоже самое что тим.лид, хотя часто путают), иногда даже project manager'a. Должен ли, архитектор или технический менеджер отлично знать базовые алгоритмы… не знаю, вопрос сложный, как должен ли профессор математики идеально считать в уме простые арифметические задачи. Но я бы не сказал, что эти роли совсем незначительные плюшки senior'a для данных компаний, скорее наоборот ключевые…
Нет, не предлагаю. Никто не просит реальное решение, тут хочется просто понять как человек размышляет, не более того. Кто-то для подобной задачи начнет рисовать архитектуру и рассказывать из каких частей будет система, кто-то будет строить модель, кто-то придумывать хитрые алгоритмы, кто-то рассказывать какую базу и фреймворки возьмет и почему. Важен не результат, а процесс.
P.S. Кстати, знания алгоритмов на память как раз в реальной работе не всякому программисту нужны, а когда нужны ему достаточно открыть инет. Нет, если более 50% времени программисту требуется писать хитрые алгоритмы — тогда вопросов нет, а если 0.5%? Тогда важнее умение писать свой код и читать чужой.
Прочитайте выше, никто не говорит отсеивать. Если человек просто реализует алгоритм поиска это решение, которое можно обсуждать и пощупать (и спросить почему именно этот алгоритм, а не другой, какие у него плюсы и минусы). Это показывает хорошие навыки кодирования и меньшую склонность к аналитике.
Если человек предложит, например, сделать мобильное приложение, которое будет собирать данные разных пользователей, а потом с помощью машинного обучения выдавать прогнозы на появление пробок/аварий/ремонтов другим пользователям — это другое решение, показывающее большую креативность.
Решений любой реальной задачи может быть много и по тому как человек её решает и как он размышляет можно понять как он будет решать другие задачи и, например, есть ли у него склонность к анализу или нет, к построению своих велосипедов или использование чужих решений. У реальной задачи никогда нет одного правильного решения, иногда вместо огромной системы достаточно формул в Excel файле или чего-то подобного. Важно как человек ищет решение, а не само решение.
Это важно для того чтобы понимать как использовать работника в будущем, если вы набираете не просто винтики в систему/манки кодеров, а специалистов.
Можете. И вполне можете забыть, что совсем элементарное вроде как в Java найди вхождение подстроки в строку. Все помнить, а вот это забыть и именно это спросят. В жизни всякая фигня случается, никто не сможет угадать кто и когда что не знает/забудет.
Может быть вы в инете никогда инет магазин не видели, а тут вам задание сделать реализацию личного кабинета в инет магазине… Увы, никто не может влезть в вам в голову и понять что мы можете не знать. Жизнь, увы, не справедлива.
Потом я не говорил, что если бы мне описали крутой алгоритм поиска оптимального пути это был бы провал. Это тоже решение просто показывающее, что человек склонен не к аналитике, а к алгоритмам.
Да, а когда аналитик дает вам требования надо додумать, что будет «если человек сажающий деревья заболеет».
А вы не в курсе, что в вашем городе бывает час пик или о том что транспорт не ходит круглые сутки? Или есть кто-то, кто об этом не знает? Я понимаю, если бы вопрос был про оптимизацию онлайн рекламы, тогда можно говорить о не знании предметной области, но уж элементарные знания жизни в городе есть у всех.
Нет, просто прежде чем додумывать, нужно задать вопрос, а так ли это на самом деле.
Проще, но для этого не требуется спрашивать хитрые алгоритмы, можно дать комп, IDE и возможность гуглить с простой задачей из тех что встречаются в работе постоянно. А через полчаса-час посмотреть какой код у кандидата получился в результате. Это будет честнее и проще, чем смотреть как кандидат копипастит из памяти алгоритм быстрой сортировки, который выучил специально перед собеседованием.
Ок, ну дайте вполне конкретную задачу под конкретного специалиста: если вы ищете php разработчика — нужно сделать такой-то сайт с такими требования, вы можете выбирать любые технологии и Фреймворки, расскажите по шагам от настройки вебсервера до настройки Фреймворков чтобы вы делали, сколько времени вам потребовалось на том или ином этапе, какие проблемы по вашему могли бы возникнуть на каждом этапе, по каким критериям вы выбрали тот или иной фреймворк/технологию/решение и т.д.
Или это тоже слишком сложно для опытного программиста описать как он бы сам сделал хотя бы простой проект самостоятельно? Тогда как такой программист может называть себе senior'ом, если не способен сделать простой проект по своей специализации от начала и до конца (или хотя бы описать как бы он сделал)?
Мне она тоже совершенно неизвестна, в задаче не требуется ничего кроме как умения думать. А вот знания алгоритма Дийкстры умения подумать не покажет.
Не хотите, задач с предметной областью, спросите у программиста, занимающийся интеграцией, как бы он писал интеграцию с определенным сервисом, как обрабатывал данные, ошибки и т.п., по шагам, просто с размышлениям, использовал ли он бы базы и orm или работа в памяти, как бы парсил, каким образом получал бы данные с сервиса. Если это senior программист, а не просто кодер, это будет сразу видно.
От опытного программиста ожидают умения думать, а не тупо кодировать по паттернам. Если это считать это бизнес-анализом, ну может быть…
Нет, хороший программист не должен рассчитывать, что аналитики дадут ему идеальный дизайн, архитекторы придумают идеальную архитектуру системы, а тестеры идеально найдут все его косяки.
В первую очередь, он должен думать, если что будет в час пик, а что будет если пользователь поедет в то время когда половина транспорта уже не ходит. И если, аналитик об этом не подумал и не написал в требованиях (что бывает почти в каждом проекте, мелкие косяки в требованиях бывают почти всегда), то подумать самому и задать вопрос аналитику/клиенту. Иначе постоянно будут ситуации когда один работник вырывает ямки, а второй их закапывает, потому что аналитик забыл предусмотреть ситуацию «работник, который должен сажать деревья, заболел», а программист сделал бездумно.
Потом, если кандидат скажет, что для данной задачи он знает замечательную библиотеку Васи Пупкина, которая отлично ищет идеальный путь в графе, а он просто оптимизирует её для учета пересадок, расписаний транспорта и стоимости проезда — это тоже будет корректным решением. Причем в некотором виде более предпочтительным, так как покажет что кандидат прежде чем делать велосипед, использует уже готовый открытый код. Обратите внимание, в условие задачи нет требования напишите свой велосипед, а именно как вы решили бы эту задачу. И, естественно, задачи должны быть близки к тем что ему придется решать в боевых условиях.