Комментарии 175
Очень показательно, что для фронтэндеров в итоге накопали один очень мелкий кейс на прямолинейное применение reduce().
Впрочем, до тех пор, пока на собеседованиях фронтэндеров витает «мода» (задаваемая, в том числе, и вами) спрашивать про алгоритмы, структуры данных, паттерны, еще какую угодно хрень, кроме, собственно, фронтэнда — массово отфильтровывать такие компании как неадекватные достаточно легко и непринужденно.
И спасибо коронавирусу, теперь хотя бы мода на написание кода на доске и бумажке сильно уменьшится. И то хорошо.
Впрочем, до тех пор, пока на собеседованиях фронтэндеров витает «мода» (задаваемая, в том числе, и вами) спрашивать про алгоритмы, структуры данных, паттерны, еще какую угодно хрень, кроме, собственно, фронтэнда — массово отфильтровывать такие компании как неадекватные достаточно легко и непринужденно.
И спасибо коронавирусу, теперь хотя бы мода на написание кода на доске и бумажке сильно уменьшится. И то хорошо.
теперь хотя бы мода на написание кода на доске и бумажке сильно уменьшится.
В нормальных компаниях уже давно предлагают писать на ноутбуке. Иногда даже с подсветкой синтаксиса. Но, естественно, без полноценной ide, автодополнения и компилирования. И да — опечатки, перепутанные местами параметры или неточное название библиотечной функции вообще ни на что не влияют. Никто не проверяет код на компилябельность. Смотрят только логику и стиль.
Никто не проверяет код на компилябельность.
Моя практика как раз говорит о том, что хотя и не должны бы — но как раз таки очень часто собеседующий оказывается из тех, кто готов «докапываться до запятых» даже в коде на бумажке (или в notepad).
Ну это какой-то плохой интервьювер. В гугле такой графы в отчете "пишет код без опечаток" нет. Можно в заметках, конечно, написать, что кандидат "запятую не там поставил", но комитет эту часть просто проигнорирует.
Или это кто-то взял и из гугловых интервью сделал карго культ.
Или это кто-то взял и из гугловых интервью сделал карго культ.
О чём тут в комментах в основном и идёт речь.
Тут куча коментов вида "алгоритмы бесполезны и их нельзя спрашивать на интервью". Но на самом деле должно быть "многие компании неправильно справшивают про алгоритмы. Вроде как идею у гугла скопировали, но важные детали потеряли".
Да ну? Прямо «алгоритмы бесполезны»? Не видел таких комментов.
Моя точка зрения, например — «на собеседованиях лучше выяснять способность работать работу, без какого-либо рода экстраполяций и проекций». Работа предполагает крутые алгоритмы? Спрашивайте их. Работа предполагает километры формочек? Спрашивайте, как кандидат организует тысячи формочек.
Гугл, кстати, не особо обосновал, что его идея реально работает и помогает. Вернее — обосновал, сделав это точно так же, как в прошлом обосновывал, почему надо спрашивать про круглые люки. Что, разумеется, вызывает очень много вопросов относительно строгости такого обоснования.
Моя точка зрения, например — «на собеседованиях лучше выяснять способность работать работу, без какого-либо рода экстраполяций и проекций». Работа предполагает крутые алгоритмы? Спрашивайте их. Работа предполагает километры формочек? Спрашивайте, как кандидат организует тысячи формочек.
Гугл, кстати, не особо обосновал, что его идея реально работает и помогает. Вернее — обосновал, сделав это точно так же, как в прошлом обосновывал, почему надо спрашивать про круглые люки. Что, разумеется, вызывает очень много вопросов относительно строгости такого обоснования.
Не видел таких комментов.
Например. Дословно такого, конечно, нет, но во всех темах на интервью всегда куча людей недовольна алгоритмическими интервью.
«на собеседованиях лучше выяснять способность работать работу, без какого-либо рода экстраполяций и проекций»
Вот только как это сделать более менее точно и экономически целесообразно никто еще не придумал.
Работа предполагает километры формочек?
Вот только на вакансию клепателя формочек с соответствующей зарплатой никто не пойдет. Всем подавай разработчика. Да и работадателям это не выгодно. Лучше за в 2 раза большую зарплату нанять специалиста, кто хоть что-то еще умеет. Вдруг послезавтра надо будет не только формочки клепать, а, о ужас, обойти список элементов интерфейса.
Но я согласен, интервью уровня гугла маленьким фирмам с более простыми задачами не нужны. Надо попроще задачки брать.
Дословно такого, конечно, нет
Ну вот и я о том же. И не надо читать это как «алгоритмы бесполезны», там в посте совсем другая мысль прослеживается, и нападок на алгоритмы нет вообще.
Вот только как это сделать более менее точно и экономически целесообразно никто еще не придумал.
Тысячи людей каждую минуту нанимают без особого опроса по алгоритмам — вы всё еще уверены, что «никто не придумал»? Для гугла, куда прёт огромный поток кандидатов — возможно, условия достаточно специфические, чтоб способы контор поменьше были бы неприменимы as is, но кто сказал, что их нельзя адаптировать?
Но есть еще те самые «экономически целесообразно», которые вы упомянули. И встаёт логичный вопрос: процесс найма гугла оптимизирует что именно в первую очередь — экономическую целесообразность процесса найма, или качество сотрудников? Понятно, что первое не приносится совсем в жертву второму и наоборот, но когда и то и другое находится на каком-то приемлемом уровне — что будет «дожиматься», экономия или качество?
Вот только на вакансию клепателя формочек с соответствующей зарплатой никто не пойдет.
Очень любопытное мнение. А я бы вот не позиционировал вакансию, как «клепателя формочек», если этих формочек у меня тысячи. Мне вот с порога очевидно, что тут как раз нужен программист, который умеет сильно больше, чем «могу делать формочки, а могу не делать». Почему я и предлагал выше спрашивать именно про то, как это всё можно организовать.
Но, естественно, без полноценной ide, автодополнения и компилирования.А почему «естественно, без»?) Есть что-то плохое в использовании ide и автодополнения?
Как по мне, пусть хоть гуглом пользуется периодически на собеседовании) Если знает, что искать, и может за минуту-две по докам освежить в памяти и разобраться, как пользоваться той или иной функцией, то вполне нормальный разработчик. Он, как и любой другой, будет этим часто заниматься на работе.
Тут 2 проблемы.
Во первых, у каждого своя любимая ide. Тут и куча гемора в настройке зоопарка систем или разработке собственной, и в итоге все-равно будет не честно, что кому-то достанется любимая ide, а кому-то нет. На текущий момент все кандидаты в одинаковых условиях.
Во вторых, именно отсутствие автодополнения и т.п. позволяет забить на компилябельность кода. В этих условиях естественно игнорировать опечатки типа отсутствующей точки с запятой или перепутанные местами параметры стандартной функции. Это как на письменном экзамене с учебниками у всех будут требовать более полный и детальный ответ, чем на устном без конспектов.
Если вашу идею развить, то она превращается в тестовое задание — пиши в чем хочешь, гугли сколько надо. Но эти тестовые задания отнимают слишком много времени у кандидатов и у интервьюеров (проверять их дольше и сложнее). Кроме того, на этих тестовых заданиях можно, например, привлекать помощь друга.
У большинства свой ноутбук есть. Могут свой принести для удобства. Плюс, для фронтенда есть онлайн редакторы вроде codesandbox.
Ниже, не про проверку знаний алгоритмов.
Я думаю, на собеседованиях кандидату стоит давать возможность показать код своих проектов и проектов, которые не под nda. Обсудить, почему так сделано, что лучше по другому сделать. Все-таки о навыках программиста ничего не может сказать лучше, чем его код. Тут я не имею ввиду код, который пишется в стрессовых условиях на некоторых собеседованиях.
Ниже, не про проверку знаний алгоритмов.
Я думаю, на собеседованиях кандидату стоит давать возможность показать код своих проектов и проектов, которые не под nda. Обсудить, почему так сделано, что лучше по другому сделать. Все-таки о навыках программиста ничего не может сказать лучше, чем его код. Тут я не имею ввиду код, который пишется в стрессовых условиях на некоторых собеседованиях.
У большинства свой ноутбук есть
И будут наезжать на условный гугл с темой "без своего ноутбука к ним не поступишь! Чертова дискриминация на интервью. Нанимают только богатых!!!1" И какой-нибудь иск обязательно будет коллективный.
на собеседованиях кандидату стоит давать возможность показать код своих проектов
Ну, вот приходит к вам чувак, приносит отличный код. Что-то более менее вразумительное про него мямлит, а потом на работе не может условный fizz-buzz написать, или тратит на что-то того же уровня целую неделю, чтобы выдавить из себя 10 строк совершенно ублюдочного кода, попутно задалбывая всех коллег с просьбами о помощи. Потом выясняется что код с интервью — продукт условного парного программирования и 100 итераций код-ревью. Т.е. такого уровня код можно в итоге даже получить, но какой ценой. Об уровне кандидата готовый код далеко не всегда говорит. Чаще — о команде и процессах на прошлой работе. А выучить какое-то внятное объяснение по готовому сниппету не так и сложно.
Вторая проблема вашего подхода, что у многих вообще может не быть кода без nda, кроме студенческих проектов, которые стыдно показывать белому свету.
Ну вы прям крайности приводите в примерах. Совершенно ублюдочный код может писать и эксперт по алгоритмам)
У всего есть недостатки.
Какая ваша цель — поставить всех в одинаковые условия и выбрать тех, кто в поставленных условиях лучше себя покажет? Или просто нанять хорошего разработчика?
Цель собеседуемого — получше себя показать и договориться о большей зарплате. Ему не выгодно, когда его ограничивают в средствах для достижения этого.
У всего есть недостатки.
Какая ваша цель — поставить всех в одинаковые условия и выбрать тех, кто в поставленных условиях лучше себя покажет? Или просто нанять хорошего разработчика?
Цель собеседуемого — получше себя показать и договориться о большей зарплате. Ему не выгодно, когда его ограничивают в средствах для достижения этого.
Вторая проблема вашего подхода, что у многих вообще может не быть кода без nda, кроме студенческих проектов, которые стыдно показывать белому свету.Если нет, ну что поделать. Если есть, почему бы этим не воспользоваться?
Совершенно ублюдочный код может писать и эксперт по алгоритмам)
Да, но вы хотя бы раз видели, как он пишет не ублюдочный код. Ведь решенная задача на собеседовании, это не все. Нужно код вменяемый написать.
Какая ваша цель — поставить всех в одинаковые условия и выбрать тех, кто в поставленных условиях лучше себя покажет? Или просто нанять хорошего разработчика?
В идеале — нанять лучших из возможных кандидатов. Понятно, что если вы год не можете закрыть позицию, то стоит очень сильно понизить планку. Но если у вас достаточно кандидатов, то интервью типа гугловых и яндексовых тут подходят чтобы нанять хорошего разработчика.
Если нет, ну что поделать. Если есть, почему бы этим не воспользоваться?
Потому что это очень ненадежный сигнал. Так можно и просто спрашивать "вы хороший разработчик? только честно!". Единственный способ понять, хорошо ли кандидат пишет код, это увидеть как он этот код пишет. Значит надо дать какое-то задание, которое можно довольно быстро спроектировать и закодить. Вот и получаются задачи вида "разверните список".
Я не говорю, что смотреть старый код кандидата нельзя и это плохо. Но это может быть только дополнительным сигналом, типа образования и дипломов.
Но если у вас достаточно кандидатов, то интервью типа гугловых и яндексовых тут подходят чтобы нанять хорошего разработчика.Ну, при избытке кандидатов, все понятно.
Понятно, что если вы год не можете закрыть позицию, то стоит очень сильно понизить планку.Или доверить собеседовать другому разработчику)
Какие алгоритмы разработчики Яндекса реализовывают каждый день
— Проснулся.
— Сходил в туалет.
— Выпил кофе.
— Сходил в туалет.
— Включил ноутбук.
[...]
То что вы называете «алгоритмический код», я бы назвал «манкикодинг на время») Все приведённые примеры могут выглядеть и в 10 раз хуже, но где тесты? Или сроки не позволяют их использовать?)
НЛО прилетело и опубликовало эту надпись здесь
Обучиться VCS и писать по кодстайлу, а то и вовсе навернуть линтер/автоформат вроде не особо сложно. В сравнении с алгоритмами, которые не всегда можно найти в книжках — сомнительные преимущества. Знание, что существует необходимая литература, конечно, хороший скилл, но едва ли решающий.
Собственно, если я правильно понял ваш посыл, вы предлагаете, нанимать в первую очередь опытных, а не студентов (как делает тот же Netflix, например). А студентам тогда где шишки набивать?
НЛО прилетело и опубликовало эту надпись здесь
Есть Интернет. Мне еще встречались настолько уникальные задачи, что вот прям вообще нигде ничего даже способного направление раскопок подсказать. И такие задачи лучше решать не в одиночку, если решающий не гений
Иными словами, когда адепт теории «все можно найти в интернете» не может что-то найти в интернете, он идет к другому чуваку, который читал книги, которые «не нужны, потому что все можно найти в интернете». Ну, либо этот адепт собирает вокруг себя людей до того момента, пока среди них не найдется тот, который читал.
Вчерашний студент и программист с 11-летним стажем не могут претендовать на одну и ту же вакансию в принципе. Какой смысл сравнивать несравнимое?
Да и похоже на нытье какое-то. По-моему стыдно с таким стажем жаловаться, что у вас спрашивают вопросы на которые студенты отвечают легко. Понятно что в голове может и не быть готового ответа, т.к. редко используются такие знания на практике, но кто сказал, что к собеседованиям готовиться не надо? Если вы собрались в конкретную компанию по общему конкурсу пройти (вы, судя по всему, не известный специалист в своей области, которому без всяких собеседований офферы шлют), то сходите потренируйтесь в другие компании, освежите свои знания.
Вы себя продавать идете людям, которые с вами работать будут. Хочется, чтобы вы с 11летним стажем могли обучать новичков (вчерашних студентов) и быть авторитетом для них, а вы на вопросы по алгоритмам жалуетесь.
Сейчас к программистам и так требования заниженные, т.к. рынок труда в пользу кандидата.
Да и похоже на нытье какое-то. По-моему стыдно с таким стажем жаловаться, что у вас спрашивают вопросы на которые студенты отвечают легко. Понятно что в голове может и не быть готового ответа, т.к. редко используются такие знания на практике, но кто сказал, что к собеседованиям готовиться не надо? Если вы собрались в конкретную компанию по общему конкурсу пройти (вы, судя по всему, не известный специалист в своей области, которому без всяких собеседований офферы шлют), то сходите потренируйтесь в другие компании, освежите свои знания.
Вы себя продавать идете людям, которые с вами работать будут. Хочется, чтобы вы с 11летним стажем могли обучать новичков (вчерашних студентов) и быть авторитетом для них, а вы на вопросы по алгоритмам жалуетесь.
Сейчас к программистам и так требования заниженные, т.к. рынок труда в пользу кандидата.
кто сказал, что к собеседованиям готовиться не надо?
А, простите, зачем?
Если у вас есть цель найти работу любой ценой или попасть любой ценой в конкретную контору Y — тогда да, подготовка к собеседованиям выглядит разумной мерой. Но last time I checked, в мире до сих пор гораздо больше вакансий для нормальных программистов, чем, собственно, нормальных программистов. Даже несмотря на последние месяцы.
Лично я вот сменил работу за апрель, так и не начав рассылать резюме сам. Единственное отличие от более лучших времен — то, что я внутренне был на низком старте относительно необходимости идти стучаться в двери самому, а не ждать рекрутёров. Но нет, не пришлось.
Лично я хочу работать там, куда не всех подряд берут. Более того, я стремлюсь в конкретные команды у конкретных работодателей.
Если вам все равно с кем/на каких условиях/над чем работать, то вас без всяких алгоритмов возьмут обязательно куда-нибудь.
Если вам все равно с кем/на каких условиях/над чем работать, то вас без всяких алгоритмов возьмут обязательно куда-нибудь.
Лично я хочу работать там, куда не всех подряд берут.
Вот чудеса, я тоже.
Впрочем, я ни разу не видел контор, которые в разработчики брали всех подряд. Вы видели? Адресок не подскажете, хочу посмотреть на такое чудо?
Более того, я стремлюсь в конкретные команды у конкретных работодателей.
Ну вот вы и ответили на вопрос, почему вы считаете нужным готовиться к собеседованиям. Но не все «стремятся в конкретные команды у конкретных работодателей».
Если вам все равно с кем/на каких условиях/над чем работать, то вас без всяких алгоритмов возьмут обязательно куда-нибудь.
Тут есть маленькая проблемка: я не вижу никаких исчислимо лучших условий там, где «со всякими алгоритмами» относительно мест «без всяких алгоритмов». Разница, главным образом, именно в этом: одни прям жить не могут без алгоритмов и структур данных на собеседованиях, вторые — могут. В остальном всё плюс-минус похоже.
Я видел. Адресов давать не буду — это неэтично.
Возможно, у меня требования к грамотности специалиста выше, чем у вас. Я давно работаю в командах >10 человек в проектах с >1000 разработчиков.
Брать людей в команду, которые почему-то решили, что могут не готовиться, не заниматься самообразованиям, которые готовы ливнуть в другую контору в любой момент — зачем?
Возможно, у меня требования к грамотности специалиста выше, чем у вас. Я давно работаю в командах >10 человек в проектах с >1000 разработчиков.
Брать людей в команду, которые почему-то решили, что могут не готовиться, не заниматься самообразованиям, которые готовы ливнуть в другую контору в любой момент — зачем?
Понятно, конструктив закончился, пошли соревноваться длиной.
Я тоже работал в команде >10 человек в проекте с >1000 (если считать очень-очень веерно, как, собственно, и вы сделали) разработчиков. Что дальше? Там всё совсем не так, как в очередном стартапчике на коленке? Конечно не так, объективная разница всё-таки огромная. Но с точки зрения адекватности работы — первое не безусловно лучше второго, и наоборот. Адекватность вообще не от размера проекта зависит.
А кто вы такие, чтоб для вас это делать?
Не готовиться к собеседованиям != не заниматься самообразованием. Если вы не делите эти вещи — у вас полная каша в голове.
Всё чудесатее и чудесатее — как вы от «не готовится к собеседованиям» переходите к «готов ливнуть»? Здесь нет логической связи, ни прямой, ни даже опосредованной.
Возможно, у меня требования к грамотности специалиста выше, чем у вас. Я давно работаю в командах >10 человек в проектах с >1000 разработчиков.
Я тоже работал в команде >10 человек в проекте с >1000 (если считать очень-очень веерно, как, собственно, и вы сделали) разработчиков. Что дальше? Там всё совсем не так, как в очередном стартапчике на коленке? Конечно не так, объективная разница всё-таки огромная. Но с точки зрения адекватности работы — первое не безусловно лучше второго, и наоборот. Адекватность вообще не от размера проекта зависит.
Брать людей в команду, которые почему-то решили, что могут не готовиться
А кто вы такие, чтоб для вас это делать?
не заниматься самообразованиям
Не готовиться к собеседованиям != не заниматься самообразованием. Если вы не делите эти вещи — у вас полная каша в голове.
которые готовы ливнуть в другую контору в любой момент
Всё чудесатее и чудесатее — как вы от «не готовится к собеседованиям» переходите к «готов ливнуть»? Здесь нет логической связи, ни прямой, ни даже опосредованной.
Понятно, конструктив закончился, пошли соревноваться длиной.
Даже не знаю почему вы так интерпретировали мои слова.
Я тоже работал в команде >10 человек в проекте с >1000 (если считать очень-очень веерно, как, собственно, и вы сделали) разработчиков. Что дальше? Там всё совсем не так, как в очередном стартапчике на коленке? Конечно не так, объективная разница всё-таки огромная. Но с точки зрения адекватности работы — первое не безусловно лучше второго, и наоборот. Адекватность вообще не от размера проекта зависит.
Я не понял, что вы именно пытаетесь этим сказать.
Лично я говорю про большую развитую инфраструктуру, где много узких мест и поломка может стоить дороже, чем ответственный программист за год заработает. А еще где много команд, много ответственностей и зависимостей, где важны сроки и качество кода. Мне важно, чтобы коллеги были грамотными профессионалами, а не раздолбаями.
А кто вы такие, чтоб для вас это делать?
Работодатель — это тот благодаря кому сотрудник кушает каждый день и крышу над головой имеет. Но собеседует, обычно, не работодатель, а коллеги будущие. Те, с кем вы, возможно, бок о бок будете трудиться, выполнять планы и т.д. Не хотите с нами работать? Ну работайте где-то еще, никто не возражает, мы лучше еще поищем.
Не готовиться к собеседованиям != не заниматься самообразованием. Если вы не делите эти вещи — у вас полная каша в голове.
Вы все на личности пытаетесь перепрыгнуть :) Это вы как-то слова через запятую в одно понятие склеиваете, не надо мне это приписывать.
Про самообразование конкретно я имел в виду, что не учит алгоритмы. Вообще, самообразование, конечно, бывает разное, например, можно танцевать учиться. Но вот мне на собеседовании интересно про алгоритмы с кандидатом поговорить больше, чем о чем-то не относящемся к работе или о том, что и так все знают.
А про подготовку: ну если человек не желает подготовиться к собеседованию, то захочет ли он готовится к демонстрациям, сроки выполнять, делать задачи которые нужно делать, а не хочется? Мы тут работаем, у нас должна быть дисциплина. Смешно объяснять даже, что к встречам в принципе готовиться надо, не только к собеседованиям.
Вы сами набирали людей в команду когда-нибудь?
Всё чудесатее и чудесатее — как вы от «не готовится к собеседованиям» переходите к «готов ливнуть»? Здесь нет логической связи, ни прямой, ни даже опосредованной.
Никак я от этого не переходил. Это вы сказали, что не все хотят работать у конкретного работодателя. Из этого вывод, что человек наверняка ливнет, когда столкнется с задачей, которая его не устроит. Он ведь даже подготовиться к собеседованию (которое между прочим почти везде похожее и легкое) не желает.
Я бы не брал человека, которому все-равно где работать и который не может осилить элементарно повторить алгоритмы уровня университета перед собесом, т.к. не уверен в его профессионализме.
Лично я говорю про большую развитую инфраструктуру, где много узких мест и поломка может стоить дороже, чем ответственный программист за год заработает.
Это не имеет никакого отношения к размеру проекта, команд, и тому подобного. Даже странно, что вам приходится это объяснять. Есть большие дорогие проекты, есть большие дешевые, есть маленькие дорогие, есть маленькие дешевые. Более того, в каждом проекте есть места, дорогие в поломке, а есть дешевые.
А еще где много команд, много ответственностей и зависимостей, где важны сроки и качество кода.
Это всё ортогональные друг другу и размеру проекта вещи. Более того, некоторые вещи из этого списка конфликтуют с другими. Дорогой код и высокая ответственность? Добро пожаловать в махровое легаси, которое «работает и не трогай». И так далее.
Мне важно, чтобы коллеги были грамотными профессионалами, а не раздолбаями.
А алгоритмы тут каким боком? Тот, кто на бумажке пишет пять сортировок — в пять раз менее раздолбай, чем тот, кто только пузырёк?
Работодатель — это тот благодаря кому сотрудник кушает каждый день и крышу над головой имеет.
Нет, работодатель — это тот, который благодаря сотрудникам вообще имеет какую-то сущность. Работодатель без сотрудника — лишь условная юридическая конструкция.
Но собеседует, обычно, не работодатель, а коллеги будущие. Те, с кем вы, возможно, бок о бок будете трудиться, выполнять планы и т.д.
Конечно. Именно поэтому на собеседованиях обычно царит махровая клановость и не более того. Не «вы должны готовиться к собеседованиям», а «я считаю, что к моим собеседованиям должны готовиться, а кто не готовится — говно и отстой, и я с такими работать не буду». Я, собственно, нисколько не против — я просто не люблю, когда мне начинают это впихивать как некий критерий «лучшести», «лучшей работы», и так далее. Нанимайте как угодно, хоть тех, кто жонглирует десятью предметами, это ваше право. Только не называйте это «мы нанимаем лучших».
Впрочем, в больших конторах, за которые вы топите — «коллеги» собеседуют как максимум после большого толстого общеконторского фильтра, и выходит как с тем же яндексом — «собеседование по алгоритмам — только одно из многих», но вот только не прошедшие его выкидываются сразу же, и на все остальные просто не идут.
Вы все на личности пытаетесь перепрыгнуть :)
Как, собственно, и вы.
Про самообразование конкретно я имел в виду, что не учит алгоритмы.
А зачем учить алгоритмы? Чтоб ночью разбудили и всё рассказал?
А про подготовку: ну если человек не желает подготовиться к собеседованию, то захочет ли он готовится к демонстрациям, сроки выполнять, делать задачи которые нужно делать, а не хочется?
А что заставляет вас думать, что нет? Я, например, уже более 10 лет работу работаю, а к собеседованиям не готовлюсь, не собираюсь, и помашу ручкой тем, кто будет пытаться мне доказать обратное. Мотивации к выполнению работы у меня предостаточно, а вот какая у меня должна быть мотивация для подготовки? Страсть как хотеть работать именно с этими людьми? Но, как я выше уже писал, это не для всех работает. Мир большой, людей много.
Впрочем, для вашего образа мышления целая статья википедии есть.
Смешно объяснять даже, что к встречам в принципе готовиться надо, не только к собеседованиям.
Конечно надо, если есть мотивация. Проблема в том, что делать это ради собеседования а) мотивации нет вплоть до тех пор, пока вы не стремитесь к конкретным людям, проводящим такие собеседования, к которым вам надо готовиться; б) более того, есть мотивация этого не делать, так как любое приукрашивание реальности на собеседовании, как со стороны конторы, так и со стороны кандидата — повышает шансы попасть в коллектив, работать в котором будет в дальнейшем неприятно.
Вы сами набирали людей в команду когда-нибудь?
Я собеседовал людей в команду как техспециалист, да.
Из этого вывод, что человек наверняка ливнет, когда столкнется с задачей, которая его не устроит.
У вас какая-то статистика есть, или это всё «я художник, я так вижу»?
Просто с позиции художника я вам ровно противоположный вывод легко сделаю: если человек готов ради работы с вами подпрыгивать строго на заданную вами высоту, то он точно так же готов будет подпрыгивать ради следующего предложения о работе, чуть круче вашего по важным для него параметрам (которые он вам не скажет, разумеется) — чуть больше денег, чуть больше престижа у позвавшей его конторы, и тому подобное — и вот он сразу же с вами прощается.
Я бы не брал человека, которому все-равно где работать
Дополнительно обращаю ваше внимание на то, что отсутствие «хочу работать конкретно у вас до дрожи в коленках» не означает «всё равно где работать». Просто вы, как работодатель — один из многих и многих тысяч тех, кто кандидата устраивает по его внутреннему фильтру.
Впрочем, я вашу позицию понял. Другое дело, что я её не разделяю, и работать с подобными вам — не собираюсь, благо хватает работодателей гораздо адекватнее. И пока вы не пытаетесь выдать ваши критерии найма за «поиск лучших» — даже и спорить не буду, каждый пляшет как хочет.
Это не имеет никакого отношения к размеру проекта, команд, и тому подобного. Даже странно, что вам приходится это объяснять. Есть большие дорогие проекты, есть большие дешевые, есть маленькие дорогие, есть маленькие дешевые. Более того, в каждом проекте есть места, дорогие в поломке, а есть дешевые.
Я опять не понял, что вы хотите сказать :) Я имею дело с большими проектами, большим кол-вом вовлеченных людей и цена ошибок — большая. Процессы в большой компании с большим кол-вом сотрудников и клиентов отличаются от каких-нибудь стартапов. Я работал и в маленьких конторах и там о многом можно не париться. Влияет ли это все на процесс найма разработчиков? Конечно влияет.
Это всё ортогональные друг другу и размеру проекта вещи. Более того, некоторые вещи из этого списка конфликтуют с другими. Дорогой код и высокая ответственность? Добро пожаловать в махровое легаси, которое «работает и не трогай». И так далее.
Здравствуйте :D Уж не знаю где как, но сейчас все адекватные люди переходят на гибкие методологии разработки, модульные архитектуры, девопсы всякие внедряют. Если так не делать — через 10 лет станешь неконкурентноспособным. Как вы думаете, что происходит с махровым легаси, которое лучше не трогать?
А алгоритмы тут каким боком? Тот, кто на бумажке пишет пять сортировок — в пять раз менее раздолбай, чем тот, кто только пузырёк?
Вы когда-нибудь экзамены сдавали?
Вот простая, понятная, универсальная тема с кучей литературы и от предметной области практически не зависит. Я, программист swift, могу собеседовать программиста C по алгоритмам. О них очень просто говорить, просто готовиться. Почему бы на собесе не поговорить именно о них? Потому что кандидату лень книжку полистать? Ну и почему я должен хотеть работать с ним?
Нет, работодатель — это тот, который благодаря сотрудникам вообще имеет какую-то сущность. Работодатель без сотрудника — лишь условная юридическая конструкция.
Даже не знаю что сказать на это. Ну это так, да. Только почему-то деньгами и работой рулит работодатель. И все сотрудники на него работают. Как-то все условности пропадают, когда на зарплаты смотришь. Если у вас это условность, то я на вашем месте убрал бы эту условность и распределил освободившиеся деньги.
Конечно. Именно поэтому на собеседованиях обычно царит махровая клановость и не более того. Не «вы должны готовиться к собеседованиям», а «я считаю, что к моим собеседованиям должны готовиться, а кто не готовится — говно и отстой, и я с такими работать не буду». Я, собственно, нисколько не против — я просто не люблю, когда мне начинают это впихивать как некий критерий «лучшести», «лучшей работы», и так далее. Нанимайте как угодно, хоть тех, кто жонглирует десятью предметами, это ваше право. Только не называйте это «мы нанимаем лучших».
Впрочем, в больших конторах, за которые вы топите — «коллеги» собеседуют как максимум после большого толстого общеконторского фильтра, и выходит как с тем же яндексом — «собеседование по алгоритмам — только одно из многих», но вот только не прошедшие его выкидываются сразу же, и на все остальные просто не идут.
Принимаем тех, в ком уверены, что они справятся с задачами. Алгоритмы — понятный критерий для отбора людей. Если человек настолько хорош, что повторить алгоритмы и ответить на вопросы для него слишком затратно, или какие там причины этого не делать, то да, фильтр его отсеит. Когда набор людей бесконечный, не страшно потерять пару действительно хороших, но ленивых кандидатов, важнее выстроить надежную систему приема подходящих людей на постоянной основе.
А зачем учить алгоритмы? Чтоб ночью разбудили и всё рассказал?
Затем, что это развивает мышление и общую профессиональной грамотность, например. Зачем учить таблицу умножения, алфавит, английский язык? Глупый вопрос, на самом деле.
Я не буду вас учить как вам жить. Считаете, что можете работать программистом и утверждать, что знание алгоритмов бесполезно? Это ваше право на личное мнение.
А что заставляет вас думать, что нет? Я, например, уже более 10 лет работу работаю, а к собеседованиям не готовлюсь, не собираюсь, и помашу ручкой тем, кто будет пытаться мне доказать обратное. Мотивации к выполнению работы у меня предостаточно, а вот какая у меня должна быть мотивация для подготовки? Страсть как хотеть работать именно с этими людьми? Но, как я выше уже писал, это не для всех работает. Мир большой, людей много.
1) Я не знаю кто вы и как работаете;
2) Возможно, что вы гордый гений и изучение алгоритмов для вас бесполезно. Ну поздравляю, вы не пройдете такой собес. И это совершенно не страшно для большой конторы, так же как и для вас в текущей экономической ситуации. Так что вы так нервничаете по этому поводу, если все всех устраивает?
Впрочем, для вашего образа мышления целая статья википедии есть.
Ох уж эти интернетные экстрасенсы…
Конечно надо, если есть мотивация. Проблема в том, что делать это ради собеседования а) мотивации нет вплоть до тех пор, пока вы не стремитесь к конкретным людям, проводящим такие собеседования, к которым вам надо готовиться; б) более того, есть мотивация этого не делать, так как любое приукрашивание реальности на собеседовании, как со стороны конторы, так и со стороны кандидата — повышает шансы попасть в коллектив, работать в котором будет в дальнейшем неприятно.
Ну так вот у вас нет мотивации готовиться к собеседованию с людьми, которые на вас свое рабочее время тратят. И на вас, конечно же, надо потратить еще больше времени, прежде чем выяснится, что у вас работать тут мотивации нет? Глупость какая-то. Вы свою важность преувеличиваете из-за ситуации на рынке труда. Вангую, что если вы доживете до момента, когда такая нужда в программистах упадет — вам станет не очень комфортно.
Я собеседовал людей в команду как техспециалист, да.
В большую контору? Как совмещали рабочие задачи с собеседованиями? Сколько кандидатов в неделю собеседовали? Как отчитывались о кандидатах? Сколько длились собеседования?
У вас какая-то статистика есть, или это всё «я художник, я так вижу»?
Просто с позиции художника я вам ровно противоположный вывод легко сделаю: если человек готов ради работы с вами подпрыгивать строго на заданную вами высоту, то он точно так же готов будет подпрыгивать ради следующего предложения о работе, чуть круче вашего по важным для него параметрам (которые он вам не скажет, разумеется) — чуть больше денег, чуть больше престижа у позвавшей его конторы, и тому подобное — и вот он сразу же с вами прощается.
Если человек пришел на встречу, где оценивают его профессиональные навыки, не подготовившись к ней и покажет, что эта работа ему особо-то и не нужна, т.к. другой много, то вывод будет о нем примерно как я написал без всякой статистики. Вы, как художник, можете видеть это как угодно со своей стороны.
Дополнительно обращаю ваше внимание на то, что отсутствие «хочу работать конкретно у вас до дрожи в коленках» не означает «всё равно где работать». Просто вы, как работодатель — один из многих и многих тысяч тех, кто кандидата устраивает по его внутреннему фильтру.
Про дрожь в коленках, это вы как художник придумали, я так не говорил.
Если кандидат думает, что за ним бегать и упрашивать работать должны — я бы по возможности с таким не связывался.
Впрочем, я вашу позицию понял. Другое дело, что я её не разделяю, и работать с подобными вам — не собираюсь, благо хватает работодателей гораздо адекватнее. И пока вы не пытаетесь выдать ваши критерии найма за «поиск лучших» — даже и спорить не буду, каждый пляшет как хочет.
Если что — я не работодатель.
«Поиск лучших» вы сами придумали. Я говорил про адекватный постоянный поиск подходящих кандидатов, как в крупных конторах типа Яндекса.
Вы очень активно не спорите уже который комментарий, утверждая свое право ничего не делать для устройства на работу.
Лучше вместо этих потоков добра в мою сторону, вы бы придумали рабочую многократно повторяемую систему найма, может быть денег на этом заработали даже.
Вот простая, понятная, универсальная тема с кучей литературы и от предметной области практически не зависит. Я, программист swift, могу собеседовать программиста C по алгоритмам. О них очень просто говорить, просто готовиться. Почему бы на собесе не поговорить именно о них?
Почему бы не о погоде на Марсе? Ну или если вы всерьез делите где-то по грани вычислительной техники, почему бы не поговорить о логическом устройстве CPU? Что вы, что программист на C — на всё тех же процессорах работаете, тема универсальнее некуда.
А серьезный ответ на этот вопрос очень простой: если вам нужен человек делать некоторую работу, вам за короткое время собеседования стоит выяснять главным образом то, справится ли человек с этой работой. «Олимпиадные задачки» проверяют, справляется ли человек с решением таких задачек. Для каких-то очень узких случаев проверять будет нужно именно это, но обычно энтерпрайз-программист занимается таки совсем другой работой. Статья выше наших комментариев, кстати, это прекрасно демонстрирует, хотя написана была вроде даже для утверждения обратного ¯\_(ツ)_/¯
Затем, что это развивает мышление и общую профессиональной грамотность, например.
Мышление развивает примерно 100500 самых разных вещей, так что совершенно неясно, почему из этих 100500 выбираем алгоритмы. «Общая профессиональная грамотность» — пустой беспредметный баззворд, в который, опять же, можно вписать 100500 совершенно разных вещей, и непонятно, почему алгоритмы тут какие-то особенные.
Зачем учить таблицу умножения, алфавит, английский язык? Глупый вопрос, на самом деле.
Действительно. Вас, кстати, очень хорошо этот ответ раскрывает: я ведь не зря выделил «учить» болдом в прошлом сообщении. «Учить» не означает «изучать», не означает «пользоваться», и вообще много чего не означает. Однако вы упираете именно в «учить».
Так вот, ответ на ваш вопрос очень простой, на самом деле: таблицу умножения учить не нужно, и более того, абсолютно вредно. Нужно разобраться с принципами работы умножения. Алфавит учить не нужно, большая часть знаний об алфавите придёт из изучения языка, тогда же и будет сформирован необходимый контекст знаний. А алфавитный порядок букв потом как-нибудь уже зафиксируется по ходу дела, тем более, что намеренно запихивать его в память нет необходимости. Иностранные языки «учить» не нужно, и даже вредно. Их нужно «изучать».
Возвращаясь к алгоритмам, алгоритмы как максимум нужно «изучать» (а не «учить»), если ваша работа очень плотно связана именно со сложными алгоритмами; а как минимум — знать о классификации тех или иных вычислительных приёмов, о простых и сложных оптимизационных задачах, и тому подобных вещах. Всё для того, чтоб, если вам заковыристые алгоритмы в жизни таки станут потребны в какой-то редкий момент — вы бы смогли с помощью гугла и такой-то матери найти для себя нужные ответы.
И подавляющему большинству программистов нужен скорее минимум, чем максимум.
«Поиск лучших» вы сами придумали.
Ну нет. Наше обсуждение началось с вашего «кто сказал, что готовиться не надо?», а потом вы немедленно начали продвигать тему, что если где-то вас собеседуют в хвост и гриву — то это признак хорошей работы, крутых коллег, и так далее. Это и есть «поиск лучших», только сформулированный как «раз требуют алгоритмы — значит там круто».
Лучше вместо этих потоков добра в мою сторону, вы бы придумали рабочую многократно повторяемую систему найма, может быть денег на этом заработали даже.
Зачем придумывать то, что уже прекрасно существует? Я надеюсь, вы осознаете, что далеко не все крупные конторы собеседуют как FAANG (и как яндекс, который на них пытается быть похожим)?
Почему бы не о погоде на Марсе? Ну или если вы всерьез делите где-то по грани вычислительной техники, почему бы не поговорить о логическом устройстве CPU? Что вы, что программист на C — на всё тех же процессорах работаете, тема универсальнее некуда.
Я могу хоть о чем из этого на собеседовании говорить :) Тем не менее, алгоритмы самая универсальная тема.
А серьезный ответ на этот вопрос очень простой: если вам нужен человек делать некоторую работу, вам за короткое время собеседования стоит выяснять главным образом то, справится ли человек с этой работой. «Олимпиадные задачки» проверяют, справляется ли человек с решением таких задачек. Для каких-то очень узких случаев проверять будет нужно именно это, но обычно энтерпрайз-программист занимается таки совсем другой работой. Статья выше наших комментариев, кстати, это прекрасно демонстрирует, хотя написана была вроде даже для утверждения обратного ¯\_(ツ)_/¯
Открою секрет: когда вам дают олимпиадную задачку, то смотрят не на то как правильно вы ее решите. Я думаю вы вообще не понимаете проблемную область найма сотрудников и не пытаетесь понять.
Мышление развивает примерно 100500 самых разных вещей, так что совершенно неясно, почему из этих 100500 выбираем алгоритмы. «Общая профессиональная грамотность» — пустой беспредметный баззворд, в который, опять же, можно вписать 100500 совершенно разных вещей, и непонятно, почему алгоритмы тут какие-то особенные.
Потому что в выч. технике так или иначе постоянно используются. Это удобно для собесов, потенциально полезно и близко для общего знаменателя для разных сортов программистов. Вы действительно хотите про устройство процессоров говорить, их регистры и т.д.?
Действительно. Вас, кстати, очень хорошо этот ответ раскрывает: я ведь не зря выделил «учить» болдом в прошлом сообщении. «Учить» не означает «изучать», не означает «пользоваться», и вообще много чего не означает. Однако вы упираете именно в «учить».
Опять интернетная экстрасенсорика и переход на личности :)
Я вам идею закину — разберите эти слова в стиле Задорнова, наверняка, там еще что-то зашифровано обо мне :)
Так вот, ответ на ваш вопрос очень простой, на самом деле: таблицу умножения учить не нужно, и более того, абсолютно вредно. Нужно разобраться с принципами работы умножения. Алфавит учить не нужно, большая часть знаний об алфавите придёт из изучения языка, тогда же и будет сформирован необходимый контекст знаний. А алфавитный порядок букв потом как-нибудь уже зафиксируется по ходу дела, тем более, что намеренно запихивать его в память нет необходимости. Иностранные языки «учить» не нужно, и даже вредно. Их нужно «изучать».
Отчасти игра словами (учить/изучать), отчасти, простите, бред. Алфавитный порядок у вас «как-нибудь» зафиксируется, принципы умножения тоже, видимо, «как-нибудь» изучатся… Я пару лет репетитором по физике/математике/программированию походил, насмотрелся я на этот принцип «как-нибудь». Надеюсь, что когда ваших детей «как-нибудь» выучат, у вас проснется понимание, что «как-нибудь» — это никак.
Ну нет. Наше обсуждение началось с вашего «кто сказал, что готовиться не надо?», а потом вы немедленно начали продвигать тему, что если где-то вас собеседуют в хвост и гриву — то это признак хорошей работы, крутых коллег, и так далее. Это и есть «поиск лучших», только сформулированный как «раз требуют алгоритмы — значит там круто».
Эти эпитеты вы сами придумали. Я сводил к оценке кандидата, к уверенности, что он справится с задачами. Когда вы постоянно проводите собесы, а параллельно занимаетесь другими важными вещами — нужна какая-то линейка/метод для оценки кандидатов объективно, а не субъективно. Вы этого упорно не понимаете.
Зачем придумывать то, что уже прекрасно существует? Я надеюсь, вы осознаете, что далеко не все крупные конторы собеседуют как FAANG (и как яндекс, который на них пытается быть похожим)?
Для рекрутеров найм айтишников — это открытая проблема. Если вы придумаете лучший способ — вы можете на этом заработать. Они так собеседуют не потому что они глупее вас. Может, если бы вы изучали алгоритмы, то вам было бы проще понять почему так происходит.
А еще вам про мягкое говорят, а вы про теплое думаете. Алгоритмы полезно знать, но, явно, не обязательно. Если хотите работать на Яндекс — соберите свой десятилетний опыт в кулак и повторите базовые алгоритмы или не тратьте их время на собеседование — оно дорогое между прочим.
Тем не менее, алгоритмы самая универсальная тема.
Нет, не самая.
Открою секрет: когда вам дают олимпиадную задачку, то смотрят не на то как правильно вы ее решите.
Открою секрет: когда вам говорят, что не смотрят на то, правильно ли вы решили задачу — вам банально лгут. Всегда, в 100% случаев.
Как максимум, смотреть могут не только на правильность решения.
Я думаю вы вообще не понимаете проблемную область найма сотрудников и не пытаетесь понять.
И этот же человек говорит о переходе на личности, ага.
Про проблемную область найма сотрудников я вам выше всё написал: когда вы нанимаете сотрудника делать работу — проверяйте, может ли он делать эту работу. Не более и не менее. Любые попытки строить проекции (от обсуждения алгоритмов до чего угодно) — заведомо менее полезные, чем прямые проверки, и работают только в условиях неиссякаемого потока кандидатов.
Вы действительно хотите про устройство процессоров говорить, их регистры и т.д.?
Да нет, это вы хотите о чём-то «общем» упорно поговорить. Я на собеседованиях говорю исключительно о частностях, никогда не было потребности нанимать «программиста в широком смысле слова», знаете ли.
А вот раз вы хотите поговорить об общем — я вам предложил еще более общее, чем алгоритмы, но вы почему-то не в восторге. Почему?
Я пару лет репетитором по физике/математике/программированию походил
Оно и видно, что вы прям «душой лежите» к экзаменам, ага. Насчёт бреда — спасибо, я уже в жизни много работал с «отличниками», которые заучили в десять раз больше, чем я способен в голове держать, вот только применять это заученное могут только со страшным скрипом и наводящими пинками, а не сами по себе. А один из самых страшных авралов в моей жизни случился из-за необходимости срочного переписывания куска кода рук двух блестящих решателей олимпиадных задачек, которые устроили безумный оверинжиниринг на ровном месте.
Эти эпитеты вы сами придумали. Я сводил к оценке кандидата, к уверенности, что он справится с задачами.
Мне важно, чтобы коллеги были грамотными профессионалами, а не раздолбаями.
Ну-ну.
Для рекрутеров найм айтишников — это открытая проблема. Если вы придумаете лучший способ — вы можете на этом заработать. Они так собеседуют не потому что они глупее вас. Может, если бы вы изучали алгоритмы, то вам было бы проще понять почему так происходит.
Какой-то поток сознания, простите. Кто глупее кого, при чём тут рекрутёры и алгоритмы?
Гугл и прочие нанимают именно так, потому что могут. Наличие постоянного входящего потока кандидатов позволяет устанавливать какой угодно входной фильтр, чтоб проходил только небольшой процент. Как это делать — не так уж и важно, смахивать 99 из 100 резюме в корзину — тоже отличный фильтр, например.
Ну и не забывайте, что гугл стал гуглом задолго до того, как начал устанавливать повальные входящие фильтры для новых сотрудников. Это к вопросу об «успешности» тех или иных стратегий найма: судить об этом по успешности самой компании довольно бесполезно, связь этих двух вещей очень опосредована и между ними большая временная задержка.
Нет, не самая.
Предлагайте.
Открою секрет: когда вам говорят, что не смотрят на то, правильно ли вы решили задачу — вам банально лгут. Всегда, в 100% случаев.
Как максимум, смотреть могут не только на правильность решения.
Опять чудеса интернет-экстрасенсорики :)
Я не буду углубляться, но есть случаи, когда кандидат вообще не решает предложенную задачу (или решает каким-то читерским способом) и успешно проходит собес. Пускай это будет лично моя практика :)
Вообще, вот вы ниже написали, что вы у себя задачи давали кандидатам. Вы какие-то «правильные» задачи давали?
Полно людей, которые могут рассказать алгоритмы, а вот задачу решить не могут. Как к этому вы относитесь?
И этот же человек говорит о переходе на личности, ага.
И почему я не могу отметить про вас что-то очевидное, если вы про меня не стесняясь пишите? :)
Про проблемную область найма сотрудников я вам выше всё написал: когда вы нанимаете сотрудника делать работу — проверяйте, может ли он делать эту работу. Не более и не менее. Любые попытки строить проекции (от обсуждения алгоритмов до чего угодно) — заведомо менее полезные, чем прямые проверки, и работают только в условиях неиссякаемого потока кандидатов.
Я вам про неиссякаемый поток кандидатов и пишу. Их нужно фильтровать постоянно и постоянно искать новых. У Яндекса, например, как раз так. Удивительно, почему они алгоритмы спрашивают, совпадение, наверно. А еще они зазнались и вообще во всем не правы :)
Да нет, это вы хотите о чём-то «общем» упорно поговорить. Я на собеседованиях говорю исключительно о частностях, никогда не было потребности нанимать «программиста в широком смысле слова», знаете ли.
А вот раз вы хотите поговорить об общем — я вам предложил еще более общее, чем алгоритмы, но вы почему-то не в восторге. Почему?
Т.е. вы в частности программист, а в общем нет? :)
Да я то не против поговорить об общем. Я могу и математику спрашивать и физику. Могу про биологию поговорить, про философию тоже немного могу :)
Еще раз, алгоритмы — удобная тема.
Оно и видно, что вы прям «душой лежите» к экзаменам, ага. Насчёт бреда — спасибо, я уже в жизни много работал с «отличниками», которые заучили в десять раз больше, чем я способен в голове держать, вот только применять это заученное могут только со страшным скрипом и наводящими пинками, а не сами по себе. А один из самых страшных авралов в моей жизни случился из-за необходимости срочного переписывания куска кода рук двух блестящих решателей олимпиадных задачек, которые устроили безумный оверинжиниринг на ровном месте.
И что вы своим примером доказали? Видимо, теперь все отличники плохие, а вы хороший? Я про отличников вообще ничего не писал, между прочим.
Вообще, вы постоянно с темы съезжаете в какие-то крайности, личности, еще что-то. Тут у вас отличники теперь неправильные. Я так думаю, что все, кто больше вас знает — нехорошие.
Ну-ну.
Что «ну-ну»? Это моя ценность: «мне важно, чтобы коллеги были грамотными профессионалами, а не раздолбаями». Исходя из своей ценности я оцениваю кандидата. Допустим, кандидат не знает алгоритмов, а у меня есть вопросы на алгоритмы. Значит ли это объективно, что он «раздолбай»? Нет, но может и значить. Зато если кандидат подготовился к вопросам, выразил знания о продукте/компании/команде/докладе/митапе в компании, ну очевидно, что он замотивирован, готов что-то учить, а первый — хз. Кого надо нанять по вашему?
Какой-то поток сознания, простите. Кто глупее кого, при чём тут рекрутёры и алгоритмы?
Гугл и прочие нанимают именно так, потому что могут. Наличие постоянного входящего потока кандидатов позволяет устанавливать какой угодно входной фильтр, чтоб проходил только небольшой процент. Как это делать — не так уж и важно, смахивать 99 из 100 резюме в корзину — тоже отличный фильтр, например.
Да у вас все само собой происходит в мире. Вы, видимо, думаете, что в гугле не умеют деньги считать и, видимо, поэтому у них их столько? А вам не приходила в голову мысль, что дело не в том, что «могут», а в том, что по-другому не могут? Может к ним настолько дохрена спецов ломится, что они не могут ничего лучше придумать? И не кажется ли вам, что это действительно рабочая стратегия и там действительно крутые спецы работают, а не те «отличники» про которых вы писали?
Ну и не забывайте, что гугл стал гуглом задолго до того, как начал устанавливать повальные входящие фильтры для новых сотрудников. Это к вопросу об «успешности» тех или иных стратегий найма: судить об этом по успешности самой компании довольно бесполезно, связь этих двух вещей очень опосредована и между ними большая временная задержка.
Да при чем тут вообще стратегия найма, гугл разбогател, потому что клиентам услугу успешно продал, а не потому что как-то особенно людей нанимал.
Другой вопрос, это возникшая проблема с наймом, когда туда люди ломанулись. Ну вот так они ее решают. У вас лучшее решение есть? В конце концов, если хотите работать в такой компании, вам нужно знать теоритический минимум по computer science (в гугле вас не только по алгоритмам прогонят). Нравится вам это, не нравится, используете ли вы все это в работе — на этапе собеседований это фильтрационные задачи. Не можете такое осилить? Ну значит вам не подходит такая компания. Я понять не могу вашего нытья.
Полезно ли это в работе? Любое знание полезно. Раньше ныли на то, что заставляли книжки по научному коммунизму учить в универах :D
А тут алгоритмы :) Извините, мне уже смешно этот диалог продолжать :)
Предлагайте.
Я уже. У вас, впрочем, сразу сомнения какие-то пошли.
Я не буду углубляться, но есть случаи, когда кандидат вообще не решает предложенную задачу (или решает каким-то читерским способом) и успешно проходит собес.
Я вместо этого предлагаю вам углубляться в чтение: я нигде и не утверждал, что не решивший задачу кандидат не пройдет собеседование. Попробуйте читать то, что вам пишут, а не что вы придумываете поверх этого.
И что вы своим примером доказали?
Ковровые обобщения в нашей беседе — это по вашей части, так что не спрашивайте меня, что я «доказываю» примерами. Я ими не доказываю, только лишь иллюстрирую то, что в жизни бывает.
Радикальные выводы в духе «был плохой случай с N» -> «все N плохие» — тоже по вашей части, кстати. Так что сами себе и ответьте.
Вообще, вы постоянно с темы съезжаете в какие-то крайности, личности, еще что-то.
Всего лишь веду беседу с вами вашими же риторическими приёмами. Это очень часто почему-то не нравится людям.
Что «ну-ну»?
Если вам настолько лень отмотать комментарии вверх (это особенно сильно выглядит на фоне заявлений о подготовке) — я напомню, что именно «ну-ну»: ваши заявления о том, что я «сам придумал эпитеты» о хорошести мест, где собеседуют с алгоритмами и по полной программе. Ваш тезис, о том, что это всё ради фильтрации раздолбаев — он ваш, и эпитеты а-ля «раздолбай» — тоже ваши.
А вам не приходила в голову мысль, что дело не в том, что «могут», а в том, что по-другому не могут?
Чтоб можно было дать на это ответ — должны, очевидно, быть попытки делать по-другому. Если вы их не видели, и ничего про них не слышали, то этому есть очень простое объяснение — их, собственно, и не было. Благо нанимательная активность гугла довольно неплохо освещается, и её история довольно простая: обычный найм спецов под конкретные проблемы -> найм по знакомствам и репутации -> найм через «круглые люки» -> найм через алгоритмы (найм по знакомствам и репутации относительно недавно был сильно прикрыт, и все идут стандартным путём). Ну и параллельно с этим остаётся «найм» через покупку вашей компании гуглом, с этим путем, кстати, связаны все без исключения последние финансово интересные проекты гугла. Наверное это о чём-то говорит. Или нет.
И не кажется ли вам, что это действительно рабочая стратегия и там действительно крутые спецы работают, а не те «отличники» про которых вы писали?
Возможно и рабочая. Этого мы всё равно никогда не узнаем, потому что натурный эксперимент провести не удастся. Может и стратегия рабочая, а может просто пока удаётся успешно покупать хорошие конторы, откуда и приходит основная добавочная стоимость, пока нанятые стандартным путем работники никаких особых прорывов не показывают.
Я понять не могу вашего нытья.
Я понять не могу, почему вы разговор за кривой найм считаете «нытьем». Впрочем, учитывая, что с аргументами у вас так себе (выкатить «а может по другому никак?», учитывая то, что каких-то заметных попыток делать по-другому и не было — ну, такое) — то да, наверное остаётся только пускаться в риторику.
ЗЫ: А, да. Один из «тех отличников», за которым я потом подтирал — ушел из моей тогдашней конторы именно в гугл, в 2014 году. Такой вот забавный фактик. Не знаю, задержался он там или нет, но ушел именно туда. Про второго ничего не знаю, может и он тоже.
Я пару лет репетитором по физике/математике/программированию походил
Можно я покажу вам разницу между учить и изучать? Вот интересно, знаете ли вы, как так вышло, что в Си в законе Кулона коэффициент 1/(4*пи), а в СГС этого коэффициента нет? И чем является в Си вектор электрической индукции, что у него даже размерность с напряжённостью поля не совпадает (в СГС совпадает)? Это такие занятные вопросы, которые, обычно, не изучают, когда эти формулы учат, и узнать о них можно разве что если где-то на них наткнётесь (например, у Китайгородского).
А по математике — почему скалярное произведение функций считается как интеграл их произведения? На лекциях как-то не освещают этот вопрос. Чем является определитель матрицы? Просто формулой? Тоже забывают рассказать студентам, обычно. Там много фишек, если начать задумываться над тем, что, собственно, происходит.
И что вы показали мне по вашему? :)
Что, не нужно формулы учить? Что образовательная программа не включает все полезные знания и надо продолжать изучение самостоятельно? Ваш поинт в чем?
Я вот уверенно могу заявлять, что куча народа даже умножать, даже по памяти не умеет, не говоря уже про вычисление по формулам. Это потому что они не изучали или не учились?
Обучение начинается с, в том числе, обычной зубрежки у детей. Чтобы что-то изучать в голове должен быть какой-то базис.
Надо ли учиться? Надо. Надо ли, что-то глубоко изучать? Тоже надо, если мозгов хватает.
Я искренне не понимаю, какую разницу и для чего вы мне тут показывать собрались. Я вижу только словоблудство: «учить/изучать». Есть еще слова: исследовать, постигать, понимать, вникать, разбираться. Давайте, найдите и покажите еще и с ними разницу :)
А так все адекватные люди и так понимают, что есть какие-то нюансы, которые не описаны в конкретной книге. Всем так же понятно, что наличие знания не говорит об умении его применения.
А еще всем понятно что нужно учиться. И, конкретно, знание алгоритмов на любом уровне лучше их полного незнания, особенно для программиста.
Что, не нужно формулы учить? Что образовательная программа не включает все полезные знания и надо продолжать изучение самостоятельно? Ваш поинт в чем?
Я вот уверенно могу заявлять, что куча народа даже умножать, даже по памяти не умеет, не говоря уже про вычисление по формулам. Это потому что они не изучали или не учились?
Обучение начинается с, в том числе, обычной зубрежки у детей. Чтобы что-то изучать в голове должен быть какой-то базис.
Надо ли учиться? Надо. Надо ли, что-то глубоко изучать? Тоже надо, если мозгов хватает.
Я искренне не понимаю, какую разницу и для чего вы мне тут показывать собрались. Я вижу только словоблудство: «учить/изучать». Есть еще слова: исследовать, постигать, понимать, вникать, разбираться. Давайте, найдите и покажите еще и с ними разницу :)
А так все адекватные люди и так понимают, что есть какие-то нюансы, которые не описаны в конкретной книге. Всем так же понятно, что наличие знания не говорит об умении его применения.
А еще всем понятно что нужно учиться. И, конкретно, знание алгоритмов на любом уровне лучше их полного незнания, особенно для программиста.
Воспринимайте это как проверку знания алгоритмов для репетитора. ;) Потому что такие вопросы — базис, на котором построена физика и математика. Если вы о базисе без понятия, то вы именно, что заучили предмет и в сущности выполняете операции над символами («производная — это штрих, вычисляется вот так...»).
Не понимаете? Жаль. Грань тонкая, но она есть. Видимо, поэтому периодически встречаются кандидаты и доктора наук, оперирующие тем, чего не понимают дальше формул, списанных у предшественника. Они делают свои выводы в статьях, но основы своей науки не понимают и не знают и не хотят знать. Следующий такой же выученный воспользуется их результатами и так далее по цепочке. Но сути процесса не понимает никто в этой цепочке. Вот это подход обученных, а не изучающих.
Вот только дьявол, как обычно, кроется в деталях. Если оперировать тем, чего не постигаешь, то и результаты будут туманны. Скажем, вот вам задачка: Есть астероид (пускай масса миллион тонн), он летит со скоростью 100 км/ч относительно Земли и есть я на нём, который толкает его с силой 1Н. Знаете, какая будет моя работа за 1 час в системе координат Земли? Путь на силу. Сила у нас приложена в 1 Н, а путь практически 100 км (масса огромная, моя сила почти не влияет на скорость). Перемножаем. Фига себе я монстр, наработал. :)
С чего начинается не важно, важно, что не сводится.
Не учиться, а изучать. Обученная обезьяна всё ещё только обученная обезьяна. :)
Вам же уже говорили: «Только ситхи всё возводят в абсолют»?
Я искренне не понимаю, какую разницу и для чего вы мне тут показывать собрались.. Я вижу только словоблудство: «учить/изучать». Есть еще слова: исследовать, постигать, понимать, вникать, разбираться. Давайте, найдите и покажите еще и с ними разницу :)
Не понимаете? Жаль. Грань тонкая, но она есть. Видимо, поэтому периодически встречаются кандидаты и доктора наук, оперирующие тем, чего не понимают дальше формул, списанных у предшественника. Они делают свои выводы в статьях, но основы своей науки не понимают и не знают и не хотят знать. Следующий такой же выученный воспользуется их результатами и так далее по цепочке. Но сути процесса не понимает никто в этой цепочке. Вот это подход обученных, а не изучающих.
А так все адекватные люди и так понимают, что есть какие-то нюансы,
Вот только дьявол, как обычно, кроется в деталях. Если оперировать тем, чего не постигаешь, то и результаты будут туманны. Скажем, вот вам задачка: Есть астероид (пускай масса миллион тонн), он летит со скоростью 100 км/ч относительно Земли и есть я на нём, который толкает его с силой 1Н. Знаете, какая будет моя работа за 1 час в системе координат Земли? Путь на силу. Сила у нас приложена в 1 Н, а путь практически 100 км (масса огромная, моя сила почти не влияет на скорость). Перемножаем. Фига себе я монстр, наработал. :)
Обучение начинается с, в том числе, обычной зубрежки у детей.
С чего начинается не важно, важно, что не сводится.
А еще всем понятно что нужно учиться.
Не учиться, а изучать. Обученная обезьяна всё ещё только обученная обезьяна. :)
И, конкретно, знание алгоритмов на любом уровне лучше их полного незнания, особенно для программиста.
Вам же уже говорили: «Только ситхи всё возводят в абсолют»?
Еще раз: что вы мне доказываете? Что на зубрежке учеба не заканчивается? Думаете это открытие для кого-то? Это просто лучше, чем ничего, но безусловно учеба не сводится к этому.
Я вам доказываю, что знание чего-либо наизусть не говорит о том, что человек изучал данное и способен придумать своё.
Так я это отрицал разве?
Изначально я говорил о том, что:
1. Программисту с 10 годами опыта должно быть стыдно ныть, из-за того что работодатель спрашивает алгоритмы на собеседовании, т.к. не составляет никакого особого труда это повторить/заучить;
2. Требования к программистам и так заниженные, т.к. дефицит кадров на рынке.
Никто не требует и не проверяет глубоких познаний в этой теме (конечно же, специалист с глубокими алгоритмическими знаниями будет пользоваться авторитетом в этой области).
Как по мне, отбор и так предельно халявный, хотелось бы проверять именно глубокие знания, но, в данный момент, так не получается, т.к.:
1. Такая проверка сама по себе тяжело формализуется и => дорогая;
2. Ситуация на рынке труда не позволяет так напрягать кандидатов, когда они, действительно, могут пойти в любое место на те же условия еще халявнее.
Ну и в итоге имеем некоторый компромис между проверкой знаний/умений и тяжестью процедуры. Если человек может хотя бы зазубрить что-то перед собесом, то, предполагается, что он сможет выполнять свои задачи.
Изначально я говорил о том, что:
1. Программисту с 10 годами опыта должно быть стыдно ныть, из-за того что работодатель спрашивает алгоритмы на собеседовании, т.к. не составляет никакого особого труда это повторить/заучить;
2. Требования к программистам и так заниженные, т.к. дефицит кадров на рынке.
Никто не требует и не проверяет глубоких познаний в этой теме (конечно же, специалист с глубокими алгоритмическими знаниями будет пользоваться авторитетом в этой области).
Как по мне, отбор и так предельно халявный, хотелось бы проверять именно глубокие знания, но, в данный момент, так не получается, т.к.:
1. Такая проверка сама по себе тяжело формализуется и => дорогая;
2. Ситуация на рынке труда не позволяет так напрягать кандидатов, когда они, действительно, могут пойти в любое место на те же условия еще халявнее.
Ну и в итоге имеем некоторый компромис между проверкой знаний/умений и тяжестью процедуры. Если человек может хотя бы зазубрить что-то перед собесом, то, предполагается, что он сможет выполнять свои задачи.
Вот именно, что вы этого не понимаете. Помните, что способность учиться связана с забыванием?
Ничего подобного. Итак, я летом два месяца реализовывал свёрточную нейросеть на Си++. С нуля. По тем крупицам общей информации, что описаны в инете. Знаете, сколько там было ошибок и нюансов, в этих крупицах? Но выяснил, как надо. Заработало как-то. Так вот, на тот момент, я кое-что понимал в том, как это реализовывается. Сейчас я уже не вспомню, как это работало. А чтобы повторить тот же результат потребуется как минимум несколько недель. Такая же точно история со всеми алгоритмами, с которыми я встречался — от текструрирования произвольной плоскости до поисков по массиву. И вряд ли у кого-то иначе.
С чего вы это взяли? По вашим меркам я должен быть где-то в самом низу по квалификации. Я не решу сейчас олимпиадную задачу. И то, что тут яндекс делает не сделаю (наверное :) ). Но при этом я решаю другие задачи, связанные, например, с управлением оружием, с обеспечением живучести системы уровня «терминатор-2» (когда его ломали на заводе в конце). Но ваши собеседования я точно не пройду.
Ну да, зато требует решения шаблонных задач. Которые легко ищутся в инете.
Это предположение ошибочное, хотя бы потому, что живое мышление ничего просто так заучивать не будет. Кстати, у Фейнмана про Бразилию не читали?
т.к. не составляет никакого особого труда это повторить/заучить;
Ничего подобного. Итак, я летом два месяца реализовывал свёрточную нейросеть на Си++. С нуля. По тем крупицам общей информации, что описаны в инете. Знаете, сколько там было ошибок и нюансов, в этих крупицах? Но выяснил, как надо. Заработало как-то. Так вот, на тот момент, я кое-что понимал в том, как это реализовывается. Сейчас я уже не вспомню, как это работало. А чтобы повторить тот же результат потребуется как минимум несколько недель. Такая же точно история со всеми алгоритмами, с которыми я встречался — от текструрирования произвольной плоскости до поисков по массиву. И вряд ли у кого-то иначе.
Требования к программистам и так заниженные, т.к. дефицит кадров на рынке.
С чего вы это взяли? По вашим меркам я должен быть где-то в самом низу по квалификации. Я не решу сейчас олимпиадную задачу. И то, что тут яндекс делает не сделаю (наверное :) ). Но при этом я решаю другие задачи, связанные, например, с управлением оружием, с обеспечением живучести системы уровня «терминатор-2» (когда его ломали на заводе в конце). Но ваши собеседования я точно не пройду.
Никто не требует и не проверяет глубоких познаний в этой теме
Ну да, зато требует решения шаблонных задач. Которые легко ищутся в инете.
Если человек может хотя бы зазубрить что-то перед собесом, то, предполагается, что он сможет выполнять свои задачи.
Это предположение ошибочное, хотя бы потому, что живое мышление ничего просто так заучивать не будет. Кстати, у Фейнмана про Бразилию не читали?
Заучивание на пользу не идёт
Что касается образования в Бразилии, то у меня был очень интересный опыт. Я вел группу студентов, которые впоследствии должны были стать преподавателями, так как возможностей для научной работы в Бразилии в то время почти не было. Мои студенты прошли уже много предметов, а это должен был быть их самый серьезный курс по электричеству и магнетизму — уравнения Максвелла и т.д.
Университет располагался в нескольких зданиях, разбросанных по городу, и я вел свои занятия в здании, окна которого выходили на залив. Я обнаружил очень странное явление: я задавал вопрос, и студенты отвечали, не задумываясь. Hо когда я задавал вопрос еще раз — на ту же тему и, как мне казалось, тот же самый вопрос, они вообще не могли ответить!
Hапример, однажды я рассказывал о поляризации света и раздал им всем кусочки поляроида.
Поляроид пропускает свет только с определенным направлением поляризации. Поэтому я объяснил, как определить направление поляризации света по тому, темный поляроид или светлый.
Сначала мы взяли две полоски поляроида и вращали их до тех пор, пока они не пропустили максимум света. Теперь мы могли сказать, что две полоски пропускают свет, поляризованный в одном направлении: что пропускает один поляроид, может пройти и через второй. Hо потом я спросил, можно ли, имея всего один кусок поляроида, определить, в каком направлении он поляризует свет. Они совершенно не представляли себе.
Я знал, что это требует известной доли находчивости, поэтому я подсказал: «Посмотрите на залив. Как от него отражается свет?»
Все молчат. Тогда я сказал:
— Вы когда-нибудь слышали об угле Брюстера?
— Да, сэр. Угол Брюстера — это угол, отражаясь под которым от преломляющей среды, свет полностью поляризуется.
— В каком направлении свет поляризуется при отражении?
— Свет поляризуется перпендикулярно плоскости падения, сэр.
Даже теперь я не могу этого понять. Они знали все наизусть. Они знали даже, что тангенс угла Брюстера равен показателю преломления! Я сказал: «Hу?»
По-прежнему, ничего. Они только что сказали мне, что свет, отражаясь от преломляющей среды, как, например, воды в заливе, поляризуется. Они даже сказали, в каком направлении он поляризуется. Я сказал: «Посмотрите на залив через поляроид. Теперь поворачивайте поляроид».
— О-о-о, он поляризован! — воскликнули они.
После длительного расследования я, наконец, понял, что студенты все запоминали, но ничего не понимали. Когда они слышали «свет, отраженный от преломляющей среды», они не понимали, что под средой имеется в виду, например, вода. Они не понимали, что «направление распространения света» — это направление, в котором видишь что-то, когда смотришь на него, и т.д. Все только запоминалось, и ничего не переводилось в осмысленные понятия. Так что, если я спрашивал: «Что такое угол Брюстера?», я обращался к компьютеру с правильными ключевыми словами. Hо если я говорил: «Посмотрите на воду», — ничего не срабатывало. У них ничего не было закодировано под этими словами.
Позже я посетил лекцию в Инженерном институте. Проходила она так:
«Два тела… считаются эквивалентными… если равные вращательные моменты… производят… равное ускорение. Два тела считаются эквивалентными, если равные вращательные моменты производят равное ускорение». Студенты сидели и записывали под диктовку, а когда профессор повторял предложение, они проверяли, все ли правильно записано. Потом они писали следующее предложение и еще одно, и еще одно. Только я один знал, что профессор говорил о телах с одинаковыми моментами инерции, а уяснить это было трудно.
Я не понимал, как они смогут разобраться во всем этом. Вот речь шла о моменте инерции, но не было никакого обсуждения хотя бы такого примера: ты хочешь открыть дверь и толкаешь ее с одной стороны, а с другой стороны ее подпирают грузом то с краю, то у самых петель. Hасколько труднее будет открыть ее в первом случае, чем во втором?
После лекции я спросил одного студента:
— Вы ведете все эти записи. Что вы с ними делаете?
— О, мы их заучиваем. У нас будет экзамен.
— А какой будет экзамен?
— Очень простой. Я могу Вам прямо сейчас назвать один из вопросов, — он заглянул в тетрадь и сказал: «В каком случае два тела считаются эквивалентными?». А ответ: «Два тела считаются эквивалентными, если равные вращательные моменты производят равные ускорения».
Так что, как видите, они могли сдавать экзамены, и «учить» все это, и не знать абсолютно ничего, кроме того, что они вызубрили.
Потом я был в Инженерном институте на вступительном экзамене. Экзамен был устный, и мне разрешили послушать. Один абитуриент был просто великолепен. Он отлично отвечал на все вопросы. Его спросили, что такое диамагнетизм. Он ответил совершенно правильно. Потом его спросили: «Что происходит с лучом света, когда он проходит под определенным углом через слой материала определенной толщины и с определенным показателем преломления?»
— Он выходит, сместившись параллельно самому себе, сэр.
— А на сколько он сместится?
— Я не знаю, сэр, но я могу посчитать.
Он посчитал. Все было прекрасно. Hо у меня к этому времени уже были подозрения.
После экзамена я подошел к блестящему молодому человеку и объяснил, что я из Соединенных Штатов и хочу задать несколько вопросов, которые никак не повлияют на результат экзамена. Для начала я спросил, может ли он привести какой-нибудь пример диамагнетика.
— Hет.
Тогда я сказал: «Представьте себе, что эта книга стеклянная, и я смотрю сквозь нее на что-нибудь на столе. Что случится с изображением, если наклонить стекло?»
— Изображение повернется, сэр, на угол, в 2 раза превышающий угол наклона.
— А вы не путаете с зеркалом?
— Hет, сэр.
Он только что сказал на экзамене, что луч света сместится параллельно самому себе, и, следовательно, изображение сдвинется в сторону, но не будет поворачиваться ни на какой угол. Он даже вычислил, насколько изображение сдвинется, но он не понимал, что кусок стекла — это и есть материал с показателем преломления и что его вычисления имели самое непосредственное отношение к моему вопросу.
В Инженерном институте я читал курс «Математические методы в физике», в котором старался научить студентов решать задачи методом проб и ошибок. Этого обычно не знают, и я начал с простых арифметических примеров. Я был удивлен, когда из восьмидесяти с лишним студентов только восемь сдали первое задание. Я произнес настоящую речь о том, что надо пробовать самим, а не просто сидеть и смотреть, как я решаю.
После лекции ко мне подошла небольшая делегация. Мне объяснили, что я недооцениваю их подготовку, что они могут учиться, и не решая задач, что арифметику они давно уже прошли и что заниматься такими простыми вещами ниже их достоинства.
Мы продолжали заниматься, и, независимо от того, насколько сложным становился материал, они никогда не сдавали ни одной работы. Конечно, я понимал, отчего: они не могли ничего решить.
Еще одного я не мог от них добиться — вопросов. В конце концов один студент объяснил мне: «Если я задам Вам вопрос во время лекции, потом все будут говорить: „Зачем ты отнимаешь у нас время на занятиях? Мы стараемся что-то узнать. А ты прерываешь лекцию, задавая вопросы“.
Это было какое-то непостижимое высокомерие, так как никто ничего не понимал в происходящем, и все только делали вид, что понимают. Они притворялись, что им все ясно. И если кто-то задавал вопрос, признавая тем самым, что ему не все понятно, на него смотрели сверху вниз и говорили, что он отнимает время.
Я объяснял, как полезно работать сообща, обсуждать все проблемы, все до конца выяснять, но они этого не делали, потому что, задав вопрос, они уронили бы свое достоинство. Бедняги! Разумные люди, и сколько труда они тратили, но вот усвоили этот нелепый, извращенный взгляд на вещи и сделали свое „образование“ бессмысленным, полностью бессмысленным. В конце учебного года студенты попросили меня сделать доклад о моем преподавании в Бразилии. Hа докладе должны были присутствовать не только студенты, но и профессора и правительственные чиновники, так что я взял с них обещание, что я смогу говорить все, что захочу. Мне сказали: „О чем речь! Конечно. Это же свободная страна“.
И вот я пришел, захватив элементарный учебник физики, по которому учились на первом курсе колледжа. Эта книга считалась особенно хорошей, так как в ней использовались разные шрифты. Самые важные для запоминания вещи печатались жирным черным шрифтом, менее важные — побледнее и т.д.
Кто-то сразу же спросил: „Вы не собираетесь ругать этот учебник? Здесь находится автор, и все считают, что это хороший учебник“.
— Вы обещали, что я могу говорить все, что хочу.
Зал был полон. Я начал с определения науки. Hаука — это понимание законов природы. Потом я спросил: „Зачем развивать науку? Конечно, ни одна страна не может считаться цивилизованной, если она не… и т.д., и т.п.“ Все сидели и кивали, потому что, я знал, так именно они и думали. Тогда я сказал: „Это, конечно, абсурдно. Почему мы должны стремиться подражать другой стране? Для занятия наукой должна быть другая, веская, разумная, причина; нельзя развивать науку просто потому, что так делают в других странах“. Потом я отметил практическую пользу научных исследований, вклад науки в улучшение условий жизни человека, и все такое — я их немного подразнил.
Потом я сказал: „Основная цель моего доклада — показать, что в Бразилии нет научной подготовки“.
Смотрю: они заволновались: „Как? Hет науки? Чушь какая-то! У нас учится столько студентов!“
Тут я рассказал им, что, приехав в Бразилию, я был поражен, как много в книжных магазинах младших школьников, покупающих книги по физике. В Бразилии очень много детей занимаются физикой, причем начинают гораздо раньше, чем дети в Соединенных Штатах. Поэтому удивительно, что мы не видим в Бразилии большого числа физиков. Отчего? Столько детей трудится изо всех сил, но все впустую.
И я привел такую аналогию: ученый занимается греческим языком и любит его. В его стране не много детей, изучающих греческий язык. Hо вот он приезжает в другую страну и с радостью видит, что все учат греческий, даже самые маленькие дети в начальных школах. Он приходит на выпускной экзамен и спрашивает студента, будущего специалиста по греческому языку:
— Как Сократ понимал взаимоотношение Истины и Красоты? — Студент не может ответить. Тогда ученый спрашивает: „Что Сократ сказал Платону в Третьей беседе?“ Студент сияет и начинает: „Тр-р-р...“ — и на прекрасном греческом языке повторяет слово в слово все, что сказал Сократ.
Hо в Третьей беседе Сократ как раз и говорил о взаимоотношении Истины и Красоты.
Hаш ученый обнаружил, что в этой стране греческий язык учат так: сначала учатся произносить звуки, потом слова, а потом предложения и целые абзацы. Студенты могли повторять наизусть, слово за словом, что сказал Сократ, не отдавая себе отчета в том, что все эти слова действительно что-то значат. Для них все это только звуки. Hикто никогда не переводил их на понятный студентам язык.
Я сказал: „Вот как я представляю себе обучение детей “науке» здесь, в Бразилии". (Сильный удар, правда?)
Потом я поднял учебник, которым они пользовались: «В этой книге в одном единственном месте упоминаются экспериментальные результаты. Я имею в виду описание опыта с шариком, катящимся по наклонной плоскости. Сообщается, как далеко он укатится через одну секунду, две секунды, три секунды и т.д. Эти числа содержат „ошибки“, т.е. на первый взгляд, кажется, что видишь экспериментальные данные. Все числа немного ниже или выше теоретических оценок. В книге даже говорится о необходимости учитывать экспериментальные ошибки — очень хорошо. Беда в том, что если вы станете вычислять величину ускорения свободного падения при помощи этих чисел, то получите правильный ответ. Hо если шарик действительно катится по наклонной плоскости, он непременно крутится, и, если вы на самом деле ставите такой опыт, это дает пять седьмых правильного ответа, так как часть энергии расходуется на вращение шарика. Так что эти единственные в книге „экспериментальные данные“ — фальсификация. Hикто не запускал шарик, иначе невозможно было бы получить такие результаты.
— Я обнаружил кое-что еще, — продолжал я. — Hаугад листая страницы и останавливаясь в любом произвольно выбранном месте, я могу показать вам, почему это не наука, а заучивание во всех случаях, без исключения. Я рискну прямо сейчас, в этой аудитории перелистать страницы, остановиться в произвольном месте, прочитать и показать вам.
Так я и сделал. Тррррр-ап — мой палец остановился на какой-то странице, и я начал читать: „Триболюминесценция. Триболюминесценция — это излучение света раздробленными кристаллами...“.
Я сказал: „Вот, пожалуйста. Есть здесь наука? Hет! Здесь есть только толкование одного слова при помощи других слов. Здесь ни слова не сказано о природе: какие кристаллы испускают свет, если их раздробить? Почему они испускают свет? Вы можете представить, чтобы хоть один студент пошел домой и попро6овал это проверить? Они не могут. Hо если бы вместо этого вы написали: “Если взять кусок сахара и в темноте расколоть его щипцами, вы увидите голубоватую вспышку. То же самое происходит и с некоторыми другими кристаллами. Hикто не знает, почему. Это явление называется триболюминесценцией. Тогда кто-нибудь проделал бы это дома, и это было бы изучением природы». Я использовал для доказательства этот пример, но мог взять и любой другой, — вся книга была такая.
Hаконец, я сказал, что не понимаю, как можно получить образование при такой саморазвивающейся системе, когда одни сдают экзамены и учат других сдавать экзамены, но никто ничего не знает. Однако я, должно быть, ошибаюсь. В моей группе было два студента, которые учились очень хорошо. И я знаю одного физика, получившего образование исключительно в Бразилии. Так что, хотя система и очень плоха, некоторые все же ухитряются пробиться. После доклада глава департамента научного образования поднялся и сказал: «То, что сообщил нам мистер Фейнман, тяжело слышать. Hо я думаю, что он действительно любит науку и искренне озабочен. Поэтому мы должны прислушаться к его мнению. Я пришел сюда, зная, что наша система образования поражена каким-то недугом. Здесь я узнал, что у нас рак», — и он сел. После такого выступления и другие стали свободно высказываться.
Поднялось большое волнение. Все вставали и вносили предложения. Студенты организовали комитет по предварительному размножению лекций и еще другие комитеты для разных целей.
А потом случилось нечто совершенно неожиданное. Один из упомянутых мною двух студентов встал и сказал: «Я учился не в Бразилии, а в Германии. А в Бразилию я приехал только в этом году».
Второй студент сказал что-то подобное. А названный мной профессор сказал: «Я учился здесь, в Бразилии, во время войны. Тогда все профессора, к счастью, покинули университет, и я учился самостоятельно, по книгам. Так что, на самом деле, я учился не по бразильской системе». Этого я не ожидал. Я знал, что система никуда не годится, но что на все 100 процентов — это было ужасно!
Я ездил в Бразилию в рамках программы, финансируемой правительством Соединенных Штатов. Поэтому в Госдепартаменте меня попросили написать отчет о моей работе в Бразилии. Я составил отчет из основных положений недавно произнесенной речи. Позже до меня дошли слухи, что некто в Госдепартаменте отреагировал так: «Вот видите, как опасно посылать в Бразилию такого наивного человека. Глупец, он может вызвать только неприятности. Он не понимает всех сложностей». Как раз наоборот. Мне кажутся наивными рассуждения этого деятеля из Госдепартамента, потому что он представлял себе университет только по бумажкам и описаниям. Вот так.
Ну теперь вы хотя бы по теме написали.
Первостепенная задача собеседование — это нанять человека, желательно лучшего из выборки, но главное — подходящего. В крупных компаниях процесс найма сотрудников не останавливается. В итоге его формализуют насколько возможно и вводят какие-то объективные критерии для выбора кандидатов.
Просто так? Пройти собеседование и устроиться туда, куда хотел — это не просто так.
Да и учат, проходят собесы, на практике это видно. Может вы считаете, что у этих людей уже не живое мышление?
И еще вопрос: вы хотите сказать своим комментарием, что процесс отбора не идеален и хорошие спецы отфильтровываются постоянно? Это хорошо известно. Предложите лучшую схему отбора кадров, это всем на пользу пойдет.
Первостепенная задача собеседование — это нанять человека, желательно лучшего из выборки, но главное — подходящего. В крупных компаниях процесс найма сотрудников не останавливается. В итоге его формализуют насколько возможно и вводят какие-то объективные критерии для выбора кандидатов.
Это предположение ошибочное, хотя бы потому, что живое мышление ничего просто так заучивать не будет.
Просто так? Пройти собеседование и устроиться туда, куда хотел — это не просто так.
Да и учат, проходят собесы, на практике это видно. Может вы считаете, что у этих людей уже не живое мышление?
И еще вопрос: вы хотите сказать своим комментарием, что процесс отбора не идеален и хорошие спецы отфильтровываются постоянно? Это хорошо известно. Предложите лучшую схему отбора кадров, это всем на пользу пойдет.
В итоге его формализуют насколько возможно и вводят какие-то объективные критерии для выбора кандидатов.
Ну, объективность любых критериев отлично описывает вот это:
Пусть Берта и Мартино — Когда пред ними праведник и вор,-
Два голоса сливая воедино,
Не произносят скорый приговор,
Чтоб в дураках однажды не остаться,
Поскольку нам известно с давних пор:
Один способен пасть, другой — подняться.
Поэтому они вводят не объективные, а субъективные критерии. Никогда не знаешь, чем будет кандидат. Чужая душа — потёмки.
Просто так? Пройти собеседование и устроиться туда, куда хотел — это не просто так.
…
Может вы считаете, что у этих людей уже не живое мышление?
Да, считаю. Я в моём НИИ постоянно вижу такие кадры. Весь обвешанный дипломами, званиями и кучей статей, но суть вопроса никогда его не волновало — одно жонглирование формулами и карьеризм. По сути, не учёный, а импотент от науки. В статьях мало что понятно, зато наукообразно. На практике, правда, не применимо :). Вам такие нужны? Ну что ж, каждому по вере.
вы хотите сказать своим комментарием, что процесс отбора не идеален и хорошие спецы отфильтровываются постоянно?
Я хочу сказать, что зацикливаться на неком наборе «объективных» правил оценки (заучивание алгоритмов, например) как минимум неправильно, а как максимум работает отрицательным фильтром.
Предложите лучшую схему отбора кадров, это всем на пользу пойдет.
Попробуйте хотя бы расширить критерии оценки, не ограничиваясь уверенность, что "кандидат должен и обязан знать A (не связанное по существу с вашей задачей напрямую)". Ну и приведите требования к кандидату в соответствие с решаемой вами задачей.
К тому же, кандидат, не помнящий того же алгоритма дейкстры, может знать и уметь много чего другого, чего вам и не снилось и, что характерно, могло бы быть вами использовано.
Так критериев и не один и даже не два :)
Просто конкретно от каждого всегда у кого-то боли в известном месте вызываются :)
Критерии именно объективные, а не субъективные. Хотя и субъективная оценка тоже есть.
Люди нужны разные. Карьеристы тоже отлично работают и мотивированны, другое дело, что их энергию надо в полезное русло направлять. Ну как и у других типов сотрудников.
А еще вы так просто ярлыки сами же навешиваете. Вот почему вы считаете, что все, кто проходит такой фильтр — карьеристы и у них мышление «не живое»? Вы сами рядом утверждали, что «Чужая душа — потёмки».
Жалобы постоянны. Кто-то на субъективность жалуется, кто-то на объективность, кто-то на алгоритмы, кто-то на фреймворки и т.д. Всем не угодишь. А задача не в том, чтобы кандидатов радовать, а в том, чтобы закрывать эффективно позиции.
Ваш совет ничего не меняет. Да и тут мало совета, это огромная работа должна быть проведена, чтобы придумать что-то принципиально лучшее в плане отбора людей.
Просто конкретно от каждого всегда у кого-то боли в известном месте вызываются :)
Критерии именно объективные, а не субъективные. Хотя и субъективная оценка тоже есть.
Люди нужны разные. Карьеристы тоже отлично работают и мотивированны, другое дело, что их энергию надо в полезное русло направлять. Ну как и у других типов сотрудников.
А еще вы так просто ярлыки сами же навешиваете. Вот почему вы считаете, что все, кто проходит такой фильтр — карьеристы и у них мышление «не живое»? Вы сами рядом утверждали, что «Чужая душа — потёмки».
Жалобы постоянны. Кто-то на субъективность жалуется, кто-то на объективность, кто-то на алгоритмы, кто-то на фреймворки и т.д. Всем не угодишь. А задача не в том, чтобы кандидатов радовать, а в том, чтобы закрывать эффективно позиции.
Ваш совет ничего не меняет. Да и тут мало совета, это огромная работа должна быть проведена, чтобы придумать что-то принципиально лучшее в плане отбора людей.
Вот почему вы считаете, что все, кто проходит такой фильтр — карьеристы и у них мышление «не живое»? Вы сами рядом утверждали, что «Чужая душа — потёмки».
А я про объективность моих критериев и не говорил. :) Но такой контингент, который рвёт жопу чтобы куда-то просто попасть и сделает ради этого что угодно (в данном случае зазубрит), вряд ли то, что вам нужно.
А задача не в том, чтобы кандидатов радовать, а в том, чтобы закрывать эффективно позиции.
Вы ниже уже написали, какие у вас позиции. Грузы таскать не нужно? :)
чтобы придумать что-то принципиально лучшее в плане отбора людей.
Бедняги, столетия отбора, а не придумали. :) Ну хотя бы испытательный срок вам зачем?
А я про объективность моих критериев и не говорил. :) Но такой контингент, который рвёт жопу чтобы куда-то просто попасть и сделает ради этого что угодно (в данном случае зазубрит), вряд ли то, что вам нужно.
Еще раз: с чего вы взяли, что эти люди именно такие?
Вы ниже уже написали, какие у вас позиции. Грузы таскать не нужно? :)
Нужно. Но для этого не привлекаются квалифицированные кадры. Квалифицированной работы очень много.
Бедняги, столетия отбора, а не придумали. :) Ну хотя бы испытательный срок вам зачем?
Вы это всерьез про испытательный срок? Если убрать фильтры и брать всех подряд — работа встанет, а квалифицированные подходящие кадры все равно пройдут мимо.
Предлагаю закончить диалог. Вы вообще не представляете о чем говорите. Лучше идите работать, вы там в своем НИИ больше пользы принесете, чем в этом обсуждении.
Еще раз: с чего вы взяли, что эти люди именно такие?
С того, что я их насмотрелся множество. Это, безусловно, необъективно, но тем не менее.
Квалифицированной работы очень много.
Просто интересно, какой? :) Вы тут где-то упоминали «бизнес». Вот это к вам как относится? Оно самое? Или вы там реально что-то значимое творите и вам вот прям алгоритмы край как необходимы? Мне просто интересно, а многострадальный фильтр Калмана, указанный в этом всём тексте выше (пусть и не вами) как алгоритм, вы лично можете сделать? Не открывая поиск, разумеется.
Вы это всерьез про испытательный срок? Если убрать фильтры и брать всех подряд — работа встанет, а квалифицированные подходящие кадры все равно пройдут мимо.
А я разве так говорил? Я вам говорил про адаптацию фильтров к реальной задаче + испытательный срок. Вы на этом сроке не можете определить, что вот этот, пусть и без алгоритмов, с работой справляется, а вот тот, хоть и с алгоритмами нет?
Вы вообще не представляете о чем говорите.
В таких фразах всегда логическое противоречие: я не могу говорить, не представляя, иначе что бы я описывал? :) Но, возможно, это представление не совпадает с вашим. Но тут уж как повезёт.
С того, что я их насмотрелся множество. Это, безусловно, необъективно, но тем не менее.
Так и есть. Вы не знаете кто у нас работает.
Просто интересно, какой? :) Вы тут где-то упоминали «бизнес». Вот это к вам как относится? Оно самое? Или вы там реально что-то значимое творите и вам вот прям алгоритмы край как необходимы?
Я не могу раскрывать детали моей работы. Но вы и ваше окружение так или иначе пользуетесь результатами нашей работы, если живете в РФ.
Мне просто интересно, а многострадальный фильтр Калмана, указанный в этом всём тексте выше (пусть и не вами) как алгоритм, вы лично можете сделать? Не открывая поиск, разумеется.
Не открывая поиск — не могу. Надеюсь это повысит вашу самооценку хотя бы.
А я разве так говорил? Я вам говорил про адаптацию фильтров к реальной задаче + испытательный срок. Вы на этом сроке не можете определить, что вот этот, пусть и без алгоритмов, с работой справляется, а вот тот, хоть и с алгоритмами нет?
Фильтры в текущем виде уже адаптированы. Вы из неверной предпосылки исходите. В текущей схеме найма принципиально ничего не докрутить — смиритесь. Думать нужно в сторону изменения самой схемы. Но пока как есть.
Испытательный срок замечателен и он применяется. Брать больше чем берем — работа встанет, т.к. новички много ресурсов съедают.
В таких фразах всегда логическое противоречие: я не могу говорить, не представляя, иначе что бы я описывал? :) Но, возможно, это представление не совпадает с вашим. Но тут уж как повезёт.
Ваше представление не совпадает с действительностью.
Так и есть. Вы не знаете кто у нас работает.
Зато я знаю, кто работает сейчас, например, в World of Tanks из тех, кого я знаю. И кто с радостью зазубрит что угодно лишь бы пройти.
Я не могу раскрывать детали моей работы.
Детали это что? Я разве где-то говорил «детали»? Вроде бы нет.
Но вы и ваше окружение так или иначе пользуетесь результатами нашей работы, если живете в РФ.
Это сомнительная рекомендация. Я не припомню, чтобы хоть что-то из того, чем я пользуюсь на территории РФ не вызывало, скажем так, неоднозначных ощущений. :) Поэтому лучше считать, что я этим не пользуюсь вовсе.
Не открывая поиск — не могу. Надеюсь это повысит вашу самооценку хотя бы.
А должно повысить? :) А для чего?
текущей схеме найма принципиально ничего не докрутить — смиритесь.
Сейчас речь не о фильтрах в вашей конторе. Разговор с вами и фактически о ваших фильтрах. Вы ведь сейчас вашу фирму не представляете, верно?
Ваше представление не совпадает с действительностью.
Звучит солидно, конечно, но, что если в данном случае именно сознание определяет бытие? Иными словами, вы видите то, что сами находите и тех кандидатов, которых сами создали своими фильтрами и подходом.
Это сомнительная рекомендация. Я не припомню, чтобы хоть что-то из того, чем я пользуюсь на территории РФ не вызывало, скажем так, неоднозначных ощущений. :) Поэтому лучше считать, что я этим не пользуюсь вовсе.
Я ничего не рекомендовал. Вы дали ссылку на коммент, где про программный мусор писали. Нашим кодом пользуются, это не мусор.
А должно повысить? :) А для чего?
Вы же спрашивали для чего-то это. Я не знаю зачем.
Сейчас речь не о фильтрах в вашей конторе. Разговор с вами и фактически о ваших фильтрах. Вы ведь сейчас вашу фирму не представляете, верно?
Я описывал мое понимание фильтров в больших конторах.
Звучит солидно, конечно, но, что если в данном случае именно сознание определяет бытие? Иными словами, вы видите то, что сами находите и тех кандидатов, которых сами создали своими фильтрами и подходом.
Мы выставляем требования на позицию и ищем соответствующего человека путем применения некоторой методики на том рынке труда, который имеется. Конечно же, требования крупных работодателей и применяемые методы поиска оказывают влияние на рынок труда, во многом и формируют его. Очевидная мысль.
Вы же спрашивали для чего-то это. Я не знаю зачем.
Ну, наверное, это как-то надо связать с вашим желанием чтобы кандидат помнил массу алгоритмов на память? Ну так вот, самый главный (для систем управления) вы уже не знаете, как видите. Отсюда плавно подходим к мысли, что, может быть, умение помнить не главное? Я нисколько не сомневаюсь, что вы сможете после периода изучения реализовать этот самый фильтр, но формально вы уже знаете, что данный алгоритм вам не известен и это никак не помешало бы вам его сделать.
С чего вы взяли что мы спрашиваем нечто экзотическое для нашей предметной области?
Если бы мы хотели так делать, то мы бы предупредили кандидатов.
Если бы мы хотели так делать, то мы бы предупредили кандидатов.
А какие алгоритмы вы спрашиваете? Сортировки? Cordic? Умножение Карацубы (кто-то когда-то уверял меня, что его использовал и резко увеличилась скорость вычислений (!),. Я очень удивился тогда, а чем занят FPU — кушает электричество?), балансировки деревьев? И где вы всё это применяете постоянно (программа всё же из этих стандартных алгоритмов состоит хорошо если на 0.001%)?
Ну, объективность любых критериев отлично описывает вот это:
Как раз это — самые что ни на есть объективные критерии: задачу решил? Алгоритм работает? Работает достаточно хорошо? Крайние случаи рассмотрел? Подсказки нужны были?
Можно спорить насколько эти критерии коррелируют с субъективной крутизной программиста или пользой, которую этот кандидат принесет работодателю.
А всякие "поговорить с кандидатом по душам", "спросить что он думает о X" — вот это субъективные оценки.
задачу решил? Алгоритм работает? Работает достаточно хорошо? Крайние случаи рассмотрел? Подсказки нужны были?
Ничего это не говорит о том, что с задачами по работе кандидат справится. Вот вообще ничего. Напомню, задача про одно, а занимается компания совсем другим (об этом диссонансе, собственно, и речь). Если вам нужен алгоритмист, то, действительно, нанимайте алгоритмиста. Если нужен прикладной математик — его и нанимайте. А если вам нужен программист сделать очередное мусорное приложение, то и нанимайте программиста. Это разные вещи. Тот же фильтр Калмана (вы вроде бы упоминали выше?) присобачить к изделию уже требуются математики (в моём случае — гироскописты-математики), а не программисты. Дело программиста эти формулы реализовать в устройстве.
Попробуйте хотя бы расширить критерии оценки, не ограничиваясь уверенность, что «кандидат должен и обязан знать A (не связанное по существу с вашей задачей напрямую)». Ну и приведите требования к кандидату в соответствие с решаемой вами задачей.
Хочу отдельно на это ответить. У нас если берут человека, то у него нет четкой должностной инструкции. Есть возможность довольно просто менять команды, роли и выполнять самую разную работу. Поэтому спрашивать лучше всего общую базу. Мы больше всего заинтересованны именно в программистах, а не в людях освоивших какую-то платформу, IDE, пару фреймворков и утверждающих, что они могут работу работать. У нас, чтобы работу работать, сначала работу думают, а потом оказывается, что программист swift должен писать скрипты на груви для систем сборок, например. Или нужно написать кросс-платформенную библиотеку для обработки картинок. Да бизнес вообще с чем угодно может в любой момент придти и надо уметь сделать и сделать нормально и быстро.
Спрос на фундаментальные знания сейчас, фреймворки использовать любая обезьяна, по вашей терминологии, умеет.
Вот как не задать вопросов по алгоритмам программисту, скажите? :)
У нас, чтобы работу работать, сначала работу думают, а потом оказывается, что программист swift должен писать скрипты на груви для систем сборок, например.
А не подскажете, как вопросы по алгоритмам помогают выяснить, сможет ли данный конкретный программист swift пойти и написать скрипт на груви?
Для друга интересуюсь.
У вас, похоже, у самого в голове каша :)
Где вы прочли конкретно это утверждение? Или вы снова, как художник, все придумали? :)
Вопросы мы задаем разные, в том числе и задачи, в том числе и на алгоритмы.
Нам неинтересно узнать, может ли кандидат конкретно со свифта пересесть на груви.
Мы смотрим базу. Если база есть, то, мы предполагаем, что когда нечто подобное случится, он должен будет справиться. Как и с другими возможными ситуациями.
Алгоритмы часть базовых знаний.
Где вы прочли конкретно это утверждение? Или вы снова, как художник, все придумали? :)
Вопросы мы задаем разные, в том числе и задачи, в том числе и на алгоритмы.
Нам неинтересно узнать, может ли кандидат конкретно со свифта пересесть на груви.
Мы смотрим базу. Если база есть, то, мы предполагаем, что когда нечто подобное случится, он должен будет справиться. Как и с другими возможными ситуациями.
Алгоритмы часть базовых знаний.
Нам неинтересно узнать, может ли кандидат конкретно со свифта пересесть на груви.
Спасибо, это всё, что я хотел узнать.
У вас сотрудники часто пересаживаются по технологиям, но разбираться, могут ли они пересаживаться (не конкретно, а вообще) — вы не хотите.
Выключите художника наконец :)
Где написано, что часто? Вы сочиняете ерунду, потому что не знаете как и что на самом деле происходит, но уверены, видимо, что во всем разбираетесь :)
Все проще — вот есть у нас ios команда. У этой команды есть задачи, например, наладить сборку на CI, тесты еще что-нибудь — эту задачу берешь и делаешь.
Вы считаете, что мы должны спросить все то, что предполагается потенциально делать? Мы и сами не все предположить можем, и где-то у нас компетенций нет. Что мы делаем? Учимся и делаем. От кандидата мы в том числе ждем понимания основ программирования, умение и желание учиться новому. И мы это выясняем на собесе.
Давайте уже прекращать наш диалог :) Нам же не работать вместе в конце-концов :)
Где написано, что часто? Вы сочиняете ерунду, потому что не знаете как и что на самом деле происходит, но уверены, видимо, что во всем разбираетесь :)
Все проще — вот есть у нас ios команда. У этой команды есть задачи, например, наладить сборку на CI, тесты еще что-нибудь — эту задачу берешь и делаешь.
Вы считаете, что мы должны спросить все то, что предполагается потенциально делать? Мы и сами не все предположить можем, и где-то у нас компетенций нет. Что мы делаем? Учимся и делаем. От кандидата мы в том числе ждем понимания основ программирования, умение и желание учиться новому. И мы это выясняем на собесе.
Давайте уже прекращать наш диалог :) Нам же не работать вместе в конце-концов :)
Где написано, что часто?
Вы уделили этому очень много внимания при описании вашего найма. Стало быть, это для вас важно — если бы это не случалось с высокой периодичностью, едва ли это удостоилось бы отдельного внимания.
Вы считаете, что мы должны спросить все то, что предполагается потенциально делать?
Разумеется. Не в мелких подробностях, конечно, потому что на такое никакого собеседования не хватит. Но по общим принципам — как вообще делаются тесты, CI, и вот это всё — поговорить можно очень продуктивно, и понять, насколько человек вообще в теме.
От кандидата мы в том числе ждем понимания основ программирования, умение и желание учиться новому.
Это все ждут. Разница только в том, что конкретные люди понимают под каждым из этих красивых слов, потому что все понимают совсем разное.
Вы вот что конкретно понимаете под «кандидат понимает основы программирования»?
Вы уделили этому очень много внимания при описании вашего найма. Стало быть, это для вас важно — если бы это не случалось с высокой периодичностью, едва ли это удостоилось бы отдельного внимания.
Это ваша рефлексия. Очень странная. Я просто взял задачу, которую обсуждал недавно :)
Разумеется. Не в мелких подробностях, конечно, потому что на такое никакого собеседования не хватит. Но по общим принципам — как вообще делаются тесты, CI, и вот это всё — поговорить можно очень продуктивно, и понять, насколько человек вообще в теме.
Мы так и делаем в сжатых временных рамках.
Да и нам конкретная тема не так важна, нам важнее, чтобы человек при необходимости въезжал в новые темы.
Алгоритмы — часть собеседования. Они не какие-то сильно хитрые — их в универах проходят. Кандидат может их полностью завалить, но все равно попасть к нам (нехорошо, конечно, но всякое бывает, да мы и джунов в том числе набираем).
Это все ждут. Разница только в том, что конкретные люди понимают под каждым из этих красивых слов, потому что все понимают совсем разное.
Вы вот что конкретно понимаете под «кандидат понимает основы программирования»?
Алгоритмы и структуры данных/БД/многопоточность/архитектура ПО/платформа с которой работать планируется.
Алгоритмы и структуры данных/БД/многопоточность/архитектура ПО/платформа с которой работать планируется.
Об этом можно проговорить пару недель нонстоп. Еще раз, что конкретно вы понимаете под «кандидат понимает основы программирования»? Из того, что реально выяснить за час беседы, а не за день или неделю?
Я уже ответил вам :)
На любую тему можно говорить сколько угодно.
У нас есть блоки вопросов по разным темам. Кандидаты либо знают о чем речь, либо нет. Это не тест и грамотных людей несложно отличить, они не пытаются скрывать знания.
На любую тему можно говорить сколько угодно.
У нас есть блоки вопросов по разным темам. Кандидаты либо знают о чем речь, либо нет. Это не тест и грамотных людей несложно отличить, они не пытаются скрывать знания.
Я уже ответил вам :)
Вы не ответили ничего конкретного, в этом вся проблема. Вы весь этот топик сыплете общими словами и очень далекоидущими выводами, но к конкретике не перешли ни разу.
Я ответил вполне конкретно в контексте обсуждаемого вопроса. Та конкретика, которую вы просите — ситуативная и плавает в зависимости от разных условий, а, следовательно, неадекватна в общем случае.
Мы:
1) Набираем людей разных уровней;
2) Набираем людей в разные команды с разными ответственностями;
3) Пытаемся говорить с кандидатом больше о том что он знает, а не знает. Не знает алгоритмы? Мы потратим час времени на другие вопросы;
4) Мы оцениваем разные качества кандидата в том числе и софт-скиллы.
Мы:
1) Набираем людей разных уровней;
2) Набираем людей в разные команды с разными ответственностями;
3) Пытаемся говорить с кандидатом больше о том что он знает, а не знает. Не знает алгоритмы? Мы потратим час времени на другие вопросы;
4) Мы оцениваем разные качества кандидата в том числе и софт-скиллы.
многопоточность
Это интересно. Скажите пожалуйста, почему когда я работаю с прерываниями, я делаю переменную volatile, чтобы компилятор не оптимизировал её доступ из разных исполняемых блоков. Но если я использую мютекс при многопоточности, то почему-то volatile использовать для такой переменной не надо. Почему компилятор внезапно понимает, что переменная может измениться внезапно. При том, что мютекс к этой переменной не привязан — он чистая условность. Почему бы такая печаль? :)
А, забыл. Речь про Си++.
Да успокойте себя уже :)
То, что мы спрашиваем на собеседованиях — мы делаем для решения конкретной производственной необходимости — найма людей. У нас нет целей кого-то оскорбить, своими знаниями похвастаться или что-то такое. Мы коллег будущих ищем.
А какую задачу вы сейчас решаете? Ищете возможность подковырнуть лично меня и потешить свое эго? Выглядит глупо и жалко, вне зависимости от того могу я ответить на ваш вопрос или нет.
То, что мы спрашиваем на собеседованиях — мы делаем для решения конкретной производственной необходимости — найма людей. У нас нет целей кого-то оскорбить, своими знаниями похвастаться или что-то такое. Мы коллег будущих ищем.
А какую задачу вы сейчас решаете? Ищете возможность подковырнуть лично меня и потешить свое эго? Выглядит глупо и жалко, вне зависимости от того могу я ответить на ваш вопрос или нет.
А какую задачу вы сейчас решаете? Ищете возможность подковырнуть лично меня и потешить свое эго? Выглядит глупо и жалко, вне зависимости от того могу я ответить на ваш вопрос или нет.
Да нет, моё эго мне тешить поздно. Мне не 25 и не 35. К такому сроку уже, обычно, есть масса сделанного, которое и так греет и не требует кого-то подковыривать или ещё что. Но мне действительно интересно узнать, на какие из довольно простых вопросов вы можете ответить. Зачем? Да просто вы заявили массу знаний и умений (репетиторство по ряду дисциплин; вопросы по интересным мне тематикам). Я не являюсь крупным специалистом в этих тематиках и, ручаюсь, истинный глубокий профессионал мгновенно прокатает меня на них. И вот мне интересно, в какой мере таким профессионалом являетесь вы. Вы спрашиваете кандидата про многопоточность? Ух ты, интересно, а вы сами-то как глубоко знаете, как оно там работает? Что там ещё можно спросить интересного? Диспетчеризация потоков, например, интересная тема? Инверсия приоритетов и защита от неё? Знаете? Или вы детально не вникали, и ваши слова про низкую планку к кандидатам действительно являются правдой, и кандидаты и впрямь никогда не интересовались, как всё это работает и знают только общие слова? Тогда, быть может, и впрямь, кроме алгоритмов нечего спрашивать? Поправка: кроме известных вам алгоритмов. Но тогда это какая-то игра в одни ворота и фильтр у вас и впрямь крайне однобокий. Вот поэтому я и спрашиваю вас в разных областях, где я и сам не являются специалистом (хм, ладно, ладно, моя специальность — квантовая электроника, там я кое-что ещё помню), но кое-что интересное в них выявил в процессе изучения, а не заучивания.
Я знаю и за диспетчеризацию и за инверсию приоритетов (и вообще-то это знают и должны знать многие студенты, это есть в университетском курсе операционных систем), вот только не понимаю какое отношение это имеет к дискуссии и почему она перешла на личности и довольно унылые попытки взять оппонента «на слабо». Унылые — потому что ничего глубокого и особо интересного в запрашиваемых знаниях нет.
Очень рад за вас. Правда. Но вопросы я задавал тому, кто набирает кандидатов по знанию алгоритмов.
А вот это не так. Спор идёт с концепцией. Но через представителя этой концепции.
Когда будете делать ПО атомной станции, вы посмотрите на это немного иначе. :) К том же есть подозрение, что и этих знаний не подразумевается у кандидатов. Вот я и спрашиваю.
и почему она перешла на личности
А вот это не так. Спор идёт с концепцией. Но через представителя этой концепции.
Унылые — потому что ничего глубокого и особо интересного в запрашиваемых знаниях нет.
Когда будете делать ПО атомной станции, вы посмотрите на это немного иначе. :) К том же есть подозрение, что и этих знаний не подразумевается у кандидатов. Вот я и спрашиваю.
У нас тоже набирают кандидатов в том числе по знанию университетского курса алгоритмов и структур данных. Который предполагает изучение подходов к анализу и построение алгоритмов, а не зазубривание стандартных сортировок как тут пытаются представить.
Это так.
Т. е. любой студент айтишной специальности обладает достаточными знаниями о многопоточке, чтобы делать ПО для атомной станции?
Кстати, это тоже переход на личности и хамство. Вы не знаете кто я и чем занимаюсь, но уже что-то предположили и пытаетесь со мной чем-то померяться. Спасибо, но мне неинтересно.
А вот это не так.
Это так.
Когда будете делать ПО атомной станции, вы посмотрите на это немного иначе. :)
Т. е. любой студент айтишной специальности обладает достаточными знаниями о многопоточке, чтобы делать ПО для атомной станции?
Кстати, это тоже переход на личности и хамство. Вы не знаете кто я и чем занимаюсь, но уже что-то предположили и пытаетесь со мной чем-то померяться. Спасибо, но мне неинтересно.
Который предполагает изучение подходов к анализу и построение алгоритмов, а не зазубривание стандартных сортировок как тут пытаются представить.
Потому что так и есть. Если вам нужны алгоритмисты, то вы и нанимаете алгоритмистов. Это само-собой разумеется. Но вот если они вам не нужны, но вы эти самые алгоритмы спрашиваете…
но уже что-то предположили и пытаетесь со мной чем-то померяться.
:O Честное слово, ничем я ни с кем не предлагаю меряться. Да и как я с вами могу меряться? Я же указал выше свою специальность — вообще с IT не связана. Я ничего того, что проходили вы, в институте не изучал (быть может, разве что кроме численных методов). Я вам просто достаточно иронично (посмотрите, там смайлик даже есть) сказал, что когда вы будете делать ПО атомной станции, всё что вы назвали унылым и не особо интересным, окажется вдруг крайне важным и очень интересным (например, когда стержни застрянут, потому что процесс их перемещения, например, висит на заблокированном мютексе).
У нас, чтобы работу работать, сначала работу думают, а потом оказывается, что программист swift должен писать скрипты на груви для систем сборок, например.
О, еще одни любители Gradle для сборки iOS.
Любопытства ради: а чего не Fastlane? Он хотя бы на Ruby, как и CocoaPods.
//del
Ну или если вы всерьез делите где-то по грани вычислительной техники, почему бы не поговорить о логическом устройстве CPU?
Если нужно поговорить о низкоуровневой (да и высокоуровневой иногда) многопоточке, то и о CPU неплохо знать.
вот действительно бомбит кого то :)
В большую контору? Как совмещали рабочие задачи с собеседованиями? Сколько кандидатов в неделю собеседовали? Как отчитывались о кандидатах? Сколько длились собеседования?
— В большую.
— Как обычно — когда есть кого собеседовать, собеседуем, выделяя под это время.
— Максимум — пятерых, по человеку в день.
— Кратким резюме по собеседованию, по трем параметрам: как сделал задачку (на минут 15 максимум), как рассказал о прошлом опыте, как вообще вёл себя как человек. По каждой из категорий можно поставить «вето», твёрдое «не берем». Оценки от техспеца и HR уходят тимлиду, тимлид на основании этих двух оценок и собственной — берет или не берет.
— Час на собеседование, еще час на предварительную подготовку — резюме посмотреть, ссылки на гитхаб или упомянутые конторы потыкать.
Принимаем тех, в ком уверены, что они справятся с задачами. Алгоритмы — понятный критерий для отбора людей. Если человек настолько хорош, что повторить алгоритмы и ответить на вопросы для него слишком затратно, или какие там причины этого не делать, то да, фильтр его отсеит
А что за компания, про которую вы все рассказываете, не подскажите? Я ее hr'ов сразу в спам фильтр добавлю, чтобы время не тратить
Такие штуки не разглашаются без разрешения, очевидно.
Просто спрашивайте у hr, какие этапы и вопросы вас ожидают или сразу предупреждайте, что алгоритмы не знаете и отвечать не будете, делов-то.
Просто спрашивайте у hr, какие этапы и вопросы вас ожидают или сразу предупреждайте, что алгоритмы не знаете и отвечать не будете, делов-то.
Такие штуки не разглашаются без разрешения, очевидно.
А чего это? Сомнения в эффективности такого подхода есть?
или сразу предупреждайте, что алгоритмы не знаете и отвечать не будете, делов-то.
Сами-то много алгоритмов знаете?) И что вы вкладываете в слово «знать»?
Пока вся эта история с алгоритмами на собесах выглядит как карго-культ, а вы — как душный сноб, который критику не приемлет. Вы и на работе также с людьми общаетесь?
А чего это? Сомнения в эффективности такого подхода есть?
Очевидно, что у работодателя есть стратегия для своего пиара и специально обученные сотрудники.
Сами-то много алгоритмов знаете?) И что вы вкладываете в слово «знать»?
Достаточно. Что-то на память, что-то забывается со временем. Иногда повторяю.
Знать — уметь объяснить и реализовать.
Пока вся эта история с алгоритмами на собесах выглядит как карго-культ, а вы — как душный сноб, который критику не приемлет. Вы и на работе также с людьми общаетесь?
У нас с вами разное понятие о критике :) Я тут критики никакой вообще не увидел. Я вижу нытье взрослых, казалось бы, людей, которые себя, видимо, профессионалами считают, но при этом отказываются понимать, как работает система найма крупных компаний и почему именно так.
Ну и просто искренне смешно, когда программисты пытаются доказывать, что знать алгоритмы им не надо.
Вам все люди с не такой точкой зрения как у вас душными снобами кажутся?
Про меня тут уже наговорили гадостей, и про мое мышление и про качества мои деловые и еще что-то было. Не стесняйтесь, высказывайтесь дальше, вы же в интернете :)
Да я как раз прекрасно понимаю, по какому принципу найм в больших компаниях происходит: конвейер собеседований с прицелом на поиск лояльных соискателей, согласных работать за прайс ниже, чем рынок может им предложить и не требующих потом регулярного повышения зарплаты.
Маленькие компании тоже так хотят, но они на то и маленькие, что при прочих равных вынуждены платить больше.
Расскажите про кейсы, когда вам в работе это пригодилось (именно реализация алгоритмов). Какие именно алгоритмы были, зачем вам их приходилось реализовывать и как часто. Я пока конкретики никакой не видел, только общие слова. Да и само слово «алгоритм» предельно абстрактно, можно что угодно подразумевать
Маленькие компании тоже так хотят, но они на то и маленькие, что при прочих равных вынуждены платить больше.
Знать — уметь объяснить и реализовать
Расскажите про кейсы, когда вам в работе это пригодилось (именно реализация алгоритмов). Какие именно алгоритмы были, зачем вам их приходилось реализовывать и как часто. Я пока конкретики никакой не видел, только общие слова. Да и само слово «алгоритм» предельно абстрактно, можно что угодно подразумевать
1) Я не утверждал, что программист не может обойтись без знаний алгоритмов. Полно примеров, что может;
2) Про лояльных соискателей и низкие зп, ну хз, крупные компании разные есть, они тоже друг от друга отличаются;
Алгоритмы — это определенные паттерны для решения определенной задачи. Сразу видно костыли, когда человек реализует уже известный алгоритм из г*вна и палок, хотя можно проще. Так что самый частый кейс — кодревью. Вы можете усомниться в полезности этого кейса, но я считаю, что это самый полезный постоянно работающий кейс, который спасает от корявых велосипедов, легаси будущего и т.п.
Дальше: написание своих библиотек. Во-первых, ты сам можешь велосипед придумывать, хотя уже все придумано было, а ты просто не знаешь. Во-вторых, полно популярных фреймворков, а в них дыры, утечки и всякое нехорошее. Почему? Потому что автор не шарит и его никто не проверил.
Время запуска приложений деградирует в приложениях, приложения больше весят, жрут батарею — это проявления в том числе и отсутствия у автора понятия об алгоритмах.
Совсем тупые примеры — с хэшами постоянно работа идет, часто вижу ошибки в их использовании, потому что нет понимания что это вообще.
Это все вроде мелочи, но их много.
Ну и вообще алгоритмы, паттерны, архитектуры, предметные области — все надо знать. Ну если развиваться в профессии хочешь и создавать что-то действительно новое, а не использовать чужие наработки, для решения однотипных задач.
2) Про лояльных соискателей и низкие зп, ну хз, крупные компании разные есть, они тоже друг от друга отличаются;
Алгоритмы — это определенные паттерны для решения определенной задачи. Сразу видно костыли, когда человек реализует уже известный алгоритм из г*вна и палок, хотя можно проще. Так что самый частый кейс — кодревью. Вы можете усомниться в полезности этого кейса, но я считаю, что это самый полезный постоянно работающий кейс, который спасает от корявых велосипедов, легаси будущего и т.п.
Дальше: написание своих библиотек. Во-первых, ты сам можешь велосипед придумывать, хотя уже все придумано было, а ты просто не знаешь. Во-вторых, полно популярных фреймворков, а в них дыры, утечки и всякое нехорошее. Почему? Потому что автор не шарит и его никто не проверил.
Время запуска приложений деградирует в приложениях, приложения больше весят, жрут батарею — это проявления в том числе и отсутствия у автора понятия об алгоритмах.
Совсем тупые примеры — с хэшами постоянно работа идет, часто вижу ошибки в их использовании, потому что нет понимания что это вообще.
Это все вроде мелочи, но их много.
Ну и вообще алгоритмы, паттерны, архитектуры, предметные области — все надо знать. Ну если развиваться в профессии хочешь и создавать что-то действительно новое, а не использовать чужие наработки, для решения однотипных задач.
Алгоритмы — это определенные паттерны для решения определенной задачи
слишком широкое определение. В принципе вообще любой код можно алгоритмом считать, но когда вы говорите, что спрашиваете «алгоритмы» на собеседовании — вы же явно имеете в виду, что не про паттерны спрашиваете, а про алгоритмы в более узком понимании, которые скорее больше про олимпиадные задачи и реализации стандартных библиотек
Ну и вообще алгоритмы, паттерны, архитектуры, предметные области — все надо знать.
так может и задавать вопросы надо про паттерны, архитектуры и предметные области, а не про алгоритмы для олимпиадных задачек? По обсуждению складывается впечатление, что вас только последнее интересует.
Ну и опять примера реального нет, как вы на практике применяли именно то, про что спрашиваете на интервью.
Расскажите про кейсы, когда вам в работе это пригодилось
Немного вклинюсь. Я в гугле задаю на собеседовании практически ровно ту задачу, что мне пришлось решать в моей повседневной работе. Чуть-чуть абстрагированную, чтобы не грузить кандидата предметной областью и кучей деталей. Но алгоритм хочется услышать того же уровня, что и закомичен в репозиторий.
Приходилось писать линейные регрессии, фильтры Калмана, динамическое программирование, бинарный поиск, moving max. Не каждый день, конечно, но раз в месяц вылезает задача, где приходится алгоритм применить. На прошлой работе нужно было работать с переплетенными в клубок двусвязными списками и кучами.
При чем во многих из этих задач можно было сделать тупой перебор какой-нибудь. Код был бы в 5 раз длиннее, менее понятный и на порядки медленнее. Кое что без этих самых алгоритмов сделать не возможно было вообще никак.
ну большинству программистом не надо с фильтрами Калмана работать и писать линейные регрессии. Если конкретная вакансия это требует, то естественно надо по-максимуму спрашивать про используемые на проекте алгоритмы или те, которые могут потенциально пригодиться, но это же не значит, что именно это надо знать все остальным?)
Да, именно эти темы далеко не всем нужны. Но как узнать, какие вещи потенциально могут пригодится? Вот, в моем случае — разработчик chrome. Вот вам очевидно, что тут понадобится фильтр калмана и линейные регрессии? Кто и как будет составлять списки, что должны кандидаты знать на каждую позицию?
С другой стороны, если человек проходит алгоритмические интервью, то с огромной долей вероятности, он поймет, что вот тут надо впендюрить какой-то математический фильтр, чтобы вот так и так сглаживать значения. Немного гуглежа и будет найден и реализован фильтр калмана, например.
Без этой базы и мысли такой тут не возникнет, будет тупо браться нефильтрованное значение или среднее.
Но как узнать, какие вещи потенциально могут пригодится? Вот, в моем случае — разработчик chrome
по-моему, вы на свой же вопрос и ответили сейчас
Я отвечал на это ваше утверждение:
Если конкретная вакансия это требует, то естественно надо по-максимуму спрашивать про используемые на проекте алгоритмы
Или Вам очевидно, что всех кандидатов в разработчики хрома надо спрашивать про линейные регрессии, фильтры калмана и еще сотню-другую весьма продвинутых вещей, которые уже есть в коде и которых там никогда не было, но они, может, потенциально пригодятся?
Про меня тут уже наговорили гадостей, и про мое мышление и про качества мои деловые и еще что-то было. Не стесняйтесь, высказывайтесь дальше, вы же в интернете :)
Вы совершенно правильно все пишете. Но совсем бессмысленно спорить с людьми, у которых срабатывает защитная реакция на то, что они (совершенно неправильно) воспринимают как снобизм и попытку вытащить из уютного мирка, где знания не нужны, а неудачи легко объяснить тайным заговором больших компаний.
Вы совершенно правильно все пишете. Но совсем бессмысленно спорить с людьми, у которых срабатывает защитная реакция на то, что они (совершенно неправильно) воспринимают как снобизм и попытку вытащить из уютного мирка, где знания не нужны, а неудачи легко объяснить тайным заговором больших компаний.
Ловко вы приравняли «знания не нужны» и «не надо спрашивать на собеседовании всех подряд разработчиков про алгоритмы, которые им в принципе не нужны конкретно в их предметной области и используемых ими технологиях».
Я вот не думаю, что вы мне на вопросы ответите по атомной физике и логике, т.к. с последней у вас явно не все хорошо.
Любой код — это алгоритм и его нужно уметь анализировать системно, и именно это изучают студенты, и именно это проверяют на собеседованиях. А не знание конкретных алгоритмов, хотя общая база все равно должна быть, просто для того чтобы люди называли одни и те же вещи одними и те ми же словами и не испытывали проблем с коммуникацией.
Спасибо за предложение, оно очень ценное, но мне неинтересно с вами общаться ни про атомную физику, ни про логику.
И, да, если вам так легче и вы себя от этого почувствуете лучше, то мне не жалко — да, я считаю, что вы гораздо лучше и умнее меня, красавчик и вообще молодец.
Спасибо за предложение, оно очень ценное, но мне неинтересно с вами общаться ни про атомную физику, ни про логику.
И, да, если вам так легче и вы себя от этого почувствуете лучше, то мне не жалко — да, я считаю, что вы гораздо лучше и умнее меня, красавчик и вообще молодец.
Я немного вклинюсь в ваш диалог) Сначала представлюсь: я мобильный разработчик, с 2013-го года под Android несколько лет, последние годы ObjC/Swift. По фану, как и многие, наверное, пишу на других языках что-то для сервера, могу настроить nginx, или поправить код на сервере, если вдруг почему-то серверные разработчики отсутствуют/не успевают (да, работаю в большой компании, но такое пару раз случалось). А ещё я несколько лет занимался олимпиадным программированием ради интереса (привет, ЛКШ!). Так вот, к чему это всё:
во-первых, по моему опыту, кандидат НЕ ДОЛЖЕН знать алгоритмы. Он не должен уметь писать сортировку кучей с закрытыми глазами, а потом писать фор-фор-фор (думаю, вы поняли, о чем я :)). Если кандидат о них знает – прекрасно, если он умеет их писать с закрытыми глазами – хорошо (замечу, что не замечательно).
во-вторых, много чего зависит от сферы деятельности, которой придется заниматься кандидату: если он будет писать сервера, ему, скорее всего, действительно нужно знать алгоритмы и уметь их писать. Если это мобильный разработчик, то знать наизусть алгоритмы ему скорее всего не нужно, более того, редко где придется писать что-то сложнее бинарного поиска.
Другое дело, что кандидат должен уметь думать. И для этого ему не нужно знать все алгоритмы мира и даже стандартные, хотя очень хорошо, если он будет знать об их существовании в принципе. В зависимости от уровня притязаний компании можно ограничиться вопросами «сколько вагонов в метро?» (кстати, хороший вопрос), стандартными задачками из серии «какого числа не хватает в неупорядоченном массиве...» или чем-то чуть более сложным, где кандидату надо будет написать алгоритм, по которому можно будет понять, умеет ли он, например, в бин.поиск, понимает ли сложность алгоритмов, не создает ли 10 лишних массивов и не проходится ли он по ним лишние 10 раз вместо единого прохода без или с минимальным количеством доп. памяти.
Вопрос, нужно ли готовиться к собеседованиям, также зависит от того, куда идти и зачем. Например, все новомодные вопросы про DI, Clean architecture и т.д. для мобильных разработчиков я воспринимаю как некоторое унижение: я могу написать хороший абстрактный код, который будет быстро работать, при этом мне совершенно не нужно знать, что я здесь использовал какой-то из принципов программирования. Увы, всё больше компаний предпочитают задавать такие вопросы (в том числе «пользовались ли вы этой библиоткой, с которой разобраться – дело двух дней? нет, тогда до свидания), нежели проверять, умеет ли кандидат думать. Лично я проводил собеседования, и довольно много: важнее умение думать, чем знания чего-либо. Тем не менее, приходилось „готовиться“ к дурацким собеседованиям, увы. Тому, кто это всё знает, готовиться не нужно в большинство компаний. Алгоритмическую задачу мне дали в 1 месте из 10, остальное было – знаете ли вы всякую дребедень и чем плох сферический конь в вакууме. А вот именно готовиться – повторять алгоритмы, порешать алгоритмические задачи – это Яндекс и Гугл.
Отсутствие подготовки полностью – да, трата времени обоих, согласен, тем не менее, если у человека есть большой релевантный опыт, то как-то он готов. И в таком случае, даже если кажется, что именно к именно вашему собеседованию (а не к работе) он не очень готов, не обязательно он не готов к работе у вас. И это не значит, что как только он встретит трудную задачу или ему станет скучно — он уйдет. Возможно по статистике и так, но за себя могу сказать, что я не люблю готовиться к тому, что не относится к конкретно работе, но по работе мне приходится выполнять любые задачи – сложные и скучные, сложные и интересные, легкие и скучные, легкие и интересные. Да и проекты я люблю доводить до логического конца. То есть суждение „не подготовился – свинтит в другую компанию“ заведомо ложное :)
во-первых, по моему опыту, кандидат НЕ ДОЛЖЕН знать алгоритмы. Он не должен уметь писать сортировку кучей с закрытыми глазами, а потом писать фор-фор-фор (думаю, вы поняли, о чем я :)). Если кандидат о них знает – прекрасно, если он умеет их писать с закрытыми глазами – хорошо (замечу, что не замечательно).
во-вторых, много чего зависит от сферы деятельности, которой придется заниматься кандидату: если он будет писать сервера, ему, скорее всего, действительно нужно знать алгоритмы и уметь их писать. Если это мобильный разработчик, то знать наизусть алгоритмы ему скорее всего не нужно, более того, редко где придется писать что-то сложнее бинарного поиска.
Другое дело, что кандидат должен уметь думать. И для этого ему не нужно знать все алгоритмы мира и даже стандартные, хотя очень хорошо, если он будет знать об их существовании в принципе. В зависимости от уровня притязаний компании можно ограничиться вопросами «сколько вагонов в метро?» (кстати, хороший вопрос), стандартными задачками из серии «какого числа не хватает в неупорядоченном массиве...» или чем-то чуть более сложным, где кандидату надо будет написать алгоритм, по которому можно будет понять, умеет ли он, например, в бин.поиск, понимает ли сложность алгоритмов, не создает ли 10 лишних массивов и не проходится ли он по ним лишние 10 раз вместо единого прохода без или с минимальным количеством доп. памяти.
Вопрос, нужно ли готовиться к собеседованиям, также зависит от того, куда идти и зачем. Например, все новомодные вопросы про DI, Clean architecture и т.д. для мобильных разработчиков я воспринимаю как некоторое унижение: я могу написать хороший абстрактный код, который будет быстро работать, при этом мне совершенно не нужно знать, что я здесь использовал какой-то из принципов программирования. Увы, всё больше компаний предпочитают задавать такие вопросы (в том числе «пользовались ли вы этой библиоткой, с которой разобраться – дело двух дней? нет, тогда до свидания), нежели проверять, умеет ли кандидат думать. Лично я проводил собеседования, и довольно много: важнее умение думать, чем знания чего-либо. Тем не менее, приходилось „готовиться“ к дурацким собеседованиям, увы. Тому, кто это всё знает, готовиться не нужно в большинство компаний. Алгоритмическую задачу мне дали в 1 месте из 10, остальное было – знаете ли вы всякую дребедень и чем плох сферический конь в вакууме. А вот именно готовиться – повторять алгоритмы, порешать алгоритмические задачи – это Яндекс и Гугл.
Если человек пришел на встречу, где оценивают его профессиональные навыки, не подготовившись к ней и покажет, что эта работа ему особо-то и не нужна, т.к. другой много, то вывод будет о нем примерно как я написал без всякой статистики
Отсутствие подготовки полностью – да, трата времени обоих, согласен, тем не менее, если у человека есть большой релевантный опыт, то как-то он готов. И в таком случае, даже если кажется, что именно к именно вашему собеседованию (а не к работе) он не очень готов, не обязательно он не готов к работе у вас. И это не значит, что как только он встретит трудную задачу или ему станет скучно — он уйдет. Возможно по статистике и так, но за себя могу сказать, что я не люблю готовиться к тому, что не относится к конкретно работе, но по работе мне приходится выполнять любые задачи – сложные и скучные, сложные и интересные, легкие и скучные, легкие и интересные. Да и проекты я люблю доводить до логического конца. То есть суждение „не подготовился – свинтит в другую компанию“ заведомо ложное :)
Алгоритмическую задачу мне дали в 1 месте из 10, остальное было – знаете ли вы всякую дребедень и чем плох сферический конь в вакууме.
Кстати, очень забавно, что у вас, как у мобильного разработчика, всё вот так выходило. Я просто когда тут недавно собеседовался (фронтэндер): у меня всякую фронтэндерскую дребедень, то, что вообще-то и стоит спрашивать, т.к. это как раз то, с чем ты постоянно возишься (вёрстка, стили, тесты, архитектура UI, как фреймворки работают, вот это всё) — по-хорошему спросили один раз, и к этим людям я в итоге и пошел работать. Зато до этого аж три другие конторы очень хотели выяснить, что я знаю про хешмапы, сортировки, и big O, с одними из которых собеседование зашло аж в яву («ну у вас же был опыт в прошлом») и в описание устройства хеш-таблиц в яве на пальцах.
Как это относится к фронтэнду — я до сих пор гадаю ¯\_(ツ)_/¯
Ну, на самом деле, я собеседовался под Android и под iOS (Android как-то снова начал интересовать). Вот под Android спрашивали то, что к разработке, казалось бы, не относится, и в некоторых местах отказывали, потому что не знаю какие-то библиотеки (возможно, у плохих разработчиков и правда проблемы с быстрым освоением библиотек, не знаю, как ещё объяснить такое). Только в Ситимобил меня спрашивали конкретно про сам Android и про стандартные структуры данных (первое, я понял, что помню уже плохо, а второе – прекрасно). Под iOS было лучше – меньше глупостей спрашивали, но сложно сказать, как на деле дела обстоят – у меня было всего 3-4 собеседования под iOS (два было под обе платформы), и после двух мне сделали предложения.
Ну, честно говоря, про фронт я без понятия, что нужно знать разработчику, но вероятно там спрашивают про структуры данных и алгоритмы для понимания вообще в принципе, кто перед ними (мы так тоже людей как-то собеседовали). Но вот я знаю 100%, что айосник, который не знаком с алгоритмами и не знает их сложность, пишет всякую дичь. То есть ты приходишь и видишь, что люди в проекте о производительности вообще не думают никак, не думают, что сейчас у них тестовых данных 100 элементов, а на практике может быть 1000, где квадрат – это уже 100 раз медленнее, и пользователю будет грустно. И в целом год менее аккуратный. А уж непонимание структур данных типа HashMap/HashSet приводит совсем к грустным последствиям.
Ну, честно говоря, про фронт я без понятия, что нужно знать разработчику, но вероятно там спрашивают про структуры данных и алгоритмы для понимания вообще в принципе, кто перед ними (мы так тоже людей как-то собеседовали). Но вот я знаю 100%, что айосник, который не знаком с алгоритмами и не знает их сложность, пишет всякую дичь. То есть ты приходишь и видишь, что люди в проекте о производительности вообще не думают никак, не думают, что сейчас у них тестовых данных 100 элементов, а на практике может быть 1000, где квадрат – это уже 100 раз медленнее, и пользователю будет грустно. И в целом год менее аккуратный. А уж непонимание структур данных типа HashMap/HashSet приводит совсем к грустным последствиям.
Ваш ответ, кажется, единственным адекватным в этой ветке :)
Думаю, что кандидат, отправляя резюме в яндекс/гугл должен понимать через какую воронку ему придется пройти и готовиться к этому и к вопросам, которые там спрашивают. Это техническая необходимость для принятия на работу, так же как экзамены при обучении, какими бы глупыми они иногда не были.
На собесе сидят не звери и не роботы, а такие же люди как вы.
Мне выше писали про кучу предложений на рынке и что готовиться вообще не надо. Если кандидат не готовится потому что уже готов, то он готов :)
Если на собесе видишь неготового кандидата, который выражает готовность работать где угодно и вы ему не сильно интересны (а примерно это мне и описывали), то тогда такой вывод. Он уже показал, что не будет напрягаться в вашей компании. Конечно, в каких-то случаях это будет ошибкой, но это ошибка со стороны кандидата так себя вести.
Думаю, что кандидат, отправляя резюме в яндекс/гугл должен понимать через какую воронку ему придется пройти и готовиться к этому и к вопросам, которые там спрашивают. Это техническая необходимость для принятия на работу, так же как экзамены при обучении, какими бы глупыми они иногда не были.
На собесе сидят не звери и не роботы, а такие же люди как вы.
Отсутствие подготовки полностью – да, трата времени обоих, согласен, тем не менее, если у человека есть большой релевантный опыт, то как-то он готов. И в таком случае, даже если кажется, что именно к именно вашему собеседованию (а не к работе) он не очень готов, не обязательно он не готов к работе у вас. И это не значит, что как только он встретит трудную задачу или ему станет скучно — он уйдет.
Мне выше писали про кучу предложений на рынке и что готовиться вообще не надо. Если кандидат не готовится потому что уже готов, то он готов :)
Если на собесе видишь неготового кандидата, который выражает готовность работать где угодно и вы ему не сильно интересны (а примерно это мне и описывали), то тогда такой вывод. Он уже показал, что не будет напрягаться в вашей компании. Конечно, в каких-то случаях это будет ошибкой, но это ошибка со стороны кандидата так себя вести.
Думаю, что кандидат, отправляя резюме в яндекс/гугл должен понимать через какую воронку ему придется пройти и готовиться к этому и к вопросам, которые там спрашивают
Полностью согласен: если знаешь, что тебя будут спрашивать (например, алгоритмы, или в вакансии указаны слова типа VIPER, SOLID и прочее), то уж будь готов к тому, что их спросят вместо того, чтобы спрашивать что-то с именно твоей точки зрения разумное. И если в случае незнаний каких-то абстрактных вещей может и повезти (потому что, допустим, адекватный человек собеседует), то в случае алгоритмов – не повезет)
Мне выше писали про кучу предложений на рынке и что готовиться вообще не надо. Если кандидат не готовится потому что уже готов, то он готов :)
Не совсем. Есть места, где спрашивают что-то, что к разработке и к выявлению способности кандидата думать не относится почти никак (например, в одном месте уперлись в SOLID, а я без понятия был, что это. Потом почитал, понял, что я и так всё делаю, как там сказано, но я понял, что даже работать с таким руководителем не хотел бы ни при каких условиях: его мало интересовал опыт, не интересовали алгоритмы, но интересовало знание статей с типичного программиста). Притом, я рад был бы рассказать и про опыт, и про алгоритмы и т.д. Собственно, в двух других местах меня оценили на основе более-менее нормальных вопросов и сделали предложение.
Если на собесе видишь неготового кандидата, который выражает готовность работать где угодно и вы ему не сильно интересны (а примерно это мне и описывали), то тогда такой вывод.
Ну, я, например, готов работать мобильным разработчиком где угодно почти, где пишут на Swift/ObjC/Kotlin/Java просто потому, что мне нравится в принципе мобильная разработка. Да, мне, например, интереснее было бы работать в гугле, но это единственное место, которое я выделяю. С другой стороны, я готов работать много, подходить к работе ответственно; вот на текущем месте я в свободное своё время иногда работаю, потому что мне просто нравится, хотя по срокам всегда всё ок, никаких проблем.
Конечно, в каких-то случаях это будет ошибкой, но это ошибка со стороны кандидата так себя вести.
Ну, я знаю людей (не только программистов), которые как я – готовы работать много где, но если работают, то работают максимально качественно. Вот и ошибка. Но, конечно, согласен, что кандидат должен проявлять заинтересованность какую-то, а не «ну я тут пришел, берите меня», это само собой.
//del
Зависит от компании и позиции на которую вы претендуете.
В большинстве случаев по алгоритмам не спросят ничего, что не было в университетском курсе или в среднем по направлению не принято знать.
Тут куча негатива было просто за сам факт вопросов по алгоритмам, хотя в целом это стандарт знаний в профессии.
Я заметил, что вы дополнили комментарии, отвечу сюда.
Никто же не спорит, что предложения выше спроса сейчас. Рынок труда на стороне соискателя (программиста) — это факт.
А как вопросы со стороны работодателя к вам должны влиять на качества работы у этого работодателя непосредственно? Это часть алгоритма отбора кандидатов, сама работа может вообще не предполагать написание кода.
Вообще, собеседование — двухсторонняя вещь. Вы со своей стороны должны выяснить все важные для вас нюансы. Можете и про использование алгоритмов и структур данных в работе заодно спросить и про аттестации и т.д. Я не стесняюсь спрашивать, где применяются алгоритмы, которые у меня спрашивают — это дает представление о том, чем я лично буду заниматься.
Лично я вот сменил работу за апрель, так и не начав рассылать резюме сам. Единственное отличие от более лучших времен — то, что я внутренне был на низком старте относительно необходимости идти стучаться в двери самому, а не ждать рекрутёров. Но нет, не пришлось.
Никто же не спорит, что предложения выше спроса сейчас. Рынок труда на стороне соискателя (программиста) — это факт.
Тут есть маленькая проблемка: я не вижу никаких исчислимо лучших условий там, где «со всякими алгоритмами» относительно мест «без всяких алгоритмов». Разница, главным образом, именно в этом: одни прям жить не могут без алгоритмов и структур данных на собеседованиях, вторые — могут. В остальном всё плюс-минус похоже.
А как вопросы со стороны работодателя к вам должны влиять на качества работы у этого работодателя непосредственно? Это часть алгоритма отбора кандидатов, сама работа может вообще не предполагать написание кода.
Вообще, собеседование — двухсторонняя вещь. Вы со своей стороны должны выяснить все важные для вас нюансы. Можете и про использование алгоритмов и структур данных в работе заодно спросить и про аттестации и т.д. Я не стесняюсь спрашивать, где применяются алгоритмы, которые у меня спрашивают — это дает представление о том, чем я лично буду заниматься.
НЛО прилетело и опубликовало эту надпись здесь
я извиняюсь, студент я, вопрос ученический:
зачем перемешивать, когда можно получить быстро К номеров с нужными параметрами и распределением и взять эти элементы, храня их там же где и были. И быстрее и меньше памяти — хранится всего К указателей.
Представим, что мы перемешиваем входные данные случайным образом, а затем берём K стартовых элементов — очевидно, это будет статистически корректный способ. Чтобы получить первые K элементов, не нужно хранить весь перемешанный массив, по существу можно хранить только первые K элементов.
зачем перемешивать, когда можно получить быстро К номеров с нужными параметрами и распределением и взять эти элементы, храня их там же где и были. И быстрее и меньше памяти — хранится всего К указателей.
Это тоже вариант, но есть несколько подвохов.
1. Если K сравнимо по величине с длиной массива, придётся часто сталкиваться с коллизиями: будем выбирать тот номер, что уже был выбран и перебрасывать кубик. В среднем там квадратичный алгоритм получается.
2. Нужно знать N заранее. Тогда надо либо все данные читать два раза (а это может быть дорого — вдруг их терабайт?), либо ограничивать работоспособность алгоритма только данными, которые влезают в память. Если работаешь на MapReduce — у тебя как правило нет ни одной, ни второй возможности. Нужно реализовать за один проход и при этом не знать полную длину входных данных.
1. Если K сравнимо по величине с длиной массива, придётся часто сталкиваться с коллизиями: будем выбирать тот номер, что уже был выбран и перебрасывать кубик. В среднем там квадратичный алгоритм получается.
2. Нужно знать N заранее. Тогда надо либо все данные читать два раза (а это может быть дорого — вдруг их терабайт?), либо ограничивать работоспособность алгоритма только данными, которые влезают в память. Если работаешь на MapReduce — у тебя как правило нет ни одной, ни второй возможности. Нужно реализовать за один проход и при этом не знать полную длину входных данных.
студент опять не понял
1. Коллизия в таблице К элементов в памяти исправляется за несоизмеримо меньшее время чем любое обращение в базу данных, любую. Да и в вашем алгоритме отбрасываются ненужные номера
2. Если нет оценки количества элементов — то что не то с архитектурой? Совсем нет никакой оценки имеющихся элементов?
3. Вы выбрали элемент — а его вот прям сразу в это время и запретили к показу/деньги на рекламу кончились/, но вы его уже выбрали в старом его состоянии и покажете бесплатно. Если выберете указатель, то при выборке самого элемента к показу вы его и забаните.
Так что подвохи тут разные
1. Коллизия в таблице К элементов в памяти исправляется за несоизмеримо меньшее время чем любое обращение в базу данных, любую. Да и в вашем алгоритме отбрасываются ненужные номера
if (position >= ItemsToTake) {
continue;
}
2. Если нет оценки количества элементов — то что не то с архитектурой? Совсем нет никакой оценки имеющихся элементов?
3. Вы выбрали элемент — а его вот прям сразу в это время и запретили к показу/деньги на рекламу кончились/, но вы его уже выбрали в старом его состоянии и покажете бесплатно. Если выберете указатель, то при выборке самого элемента к показу вы его и забаните.
Так что подвохи тут разные
1 — Пусть мы знаем N и алгоритм таков: выбрать случайный номер от 1 до N, взять элемент с этой позиции, повторить K раз. Но тут нужно реализовать выбор без повторений: если я выбрал элемент с первой позиции, я не могу выбрать его ещё раз. Так что при повторе выбранной случайно позиции (коллизии) мне надо будет либо выбирать случайное число ещё раз, либо программировать собственно выбор без повторений: при выборе числа k пройтись по массиву и взять k-е ещё не выбранное число. Оба способа работают за в среднем линейное время, так что по итогу алгоритм окажется квадратичным.
2 — Можно иметь оценку до выбора, но тогда никак не обойтись без нескольких проходов.
3 — Это в любом случае на разных этапах происходит. Как правило, платят за клики, а не за показы.
2 — Можно иметь оценку до выбора, но тогда никак не обойтись без нескольких проходов.
3 — Это в любом случае на разных этапах происходит. Как правило, платят за клики, а не за показы.
посмотрел внимательно на ваше усовершенствование алгоритма shuffle и совсем запутался
например:
вы бросаете на I шаге кубик с I гранями и тут чудо — выпала первая грань, и так К раз.
Это утрирование, гипербола — но это возможно и очевидно явно искажение статистических параметров shuffle таким изменением алгоритма. У вас некоторые элементы с номером до К могут и не выпасть никогда — и тогда это не операция shuffle и взять первые К.
Это действительно боевой код кровавого ынтерпрайза яндекса?
в вашем алгоритме количество дорогих операций — обращение к БД — может быть гораздо больше К и совсем непонятно зачем?
Нас такому не учат и наверно в Яндекс не пригласят даже на собеседование ))
например:
вы бросаете на I шаге кубик с I гранями и тут чудо — выпала первая грань, и так К раз.
Это утрирование, гипербола — но это возможно и очевидно явно искажение статистических параметров shuffle таким изменением алгоритма. У вас некоторые элементы с номером до К могут и не выпасть никогда — и тогда это не операция shuffle и взять первые К.
Это действительно боевой код кровавого ынтерпрайза яндекса?
в вашем алгоритме количество дорогих операций — обращение к БД — может быть гораздо больше К и совсем непонятно зачем?
Если этот номер меньше, чем K — поместим текущий объект в ответ, при необходимости исключив из него какой-то ранее уже добавленный элементВам не нравится копеешное исправление коллизии в таблице в памяти, но устраивает полный просмотр БД для выбора всего К элементов? Я правильно понял?
Нас такому не учат и наверно в Яндекс не пригласят даже на собеседование ))
Давай ты напишешь код, который имеешь в виду? И его предметно обсудим. А то так обсуждение довольно непонятное. Код из статьи гарантированно работает за линию, проходит по данным один раз и использует O(K) дополнительной памяти, это всё, что нужно.
1. Ваше хамство и тыканье мне, взрослому, образованному человеку, еще раз подтверждает, что аргументов нет. У вас дрянной алгоритм и дрянной код. И, скорее всего, у Вас дрянное воспитание и образование.
2. Тот код, что я хочу написать и опубликовать — я пишу и публикую, без Ваших советов.
3. Лишний раз показали, что не нужно пользоваться Яндексом, спасибо за очередное аргументированное подтверждение. ))
2. Тот код, что я хочу написать и опубликовать — я пишу и публикую, без Ваших советов.
3. Лишний раз показали, что не нужно пользоваться Яндексом, спасибо за очередное аргументированное подтверждение. ))
Пардон, господин студент, а где вас оскорбили? По-моему вы автора троллите просто :)
1. дорогой Piradius, и при царизме, и при большевиках, и при коммунистах, и при демократах, и при либералах всегда обращение на «ты» к старшему по возрасту считалось хамством и никак иначе. Не оскорблением, не хулой или еще как, а прямо вот так — хамство.
Теперь немного троллинга, раз так просите
2. Автору показали на ошибку в его коде. Реальная ошибка или кажущаяся это другой вопрос — но по большому счету проявили заботу про его код, про его дело и его статус. Провели бесплатный анализ, чего то нашли, чего то не написали.
Ответное предложение автора статьи померяться толщиной кода говорит только об одном — в Яндексе в разработке нет ни математики, ни теории алгоритмов, ни покрытия тестами. Чей «код толще» тот и в проде.
При Сергее Павловиче, сотрудник улучшивший его техническое решение не расстреливался, не ссылался на каторгу или подвергался остракизму — нет!!! Такой человек получал премию на следующий день после утверждения его решения техсоветом. Именно поэтому первыми были в космосе и космос был наш.
А в Яндексе, я так понимаю, любая ошибка найденная в коде начальника — прямой путь к увольнению. И именно поэтому Яндекс в интернете на вторых ролях.
Ну и совсем hard троллинг. Всё по заявкам. Piradius должен быть доволен
3. А ведь про ошибку эту прочли не только друзья автора статьи, но и недруги. И код они свой написали и сравнили его с кодом автора и в нужный момент в нужном месте ведь вытащат — как автор статьи сознательно не правил ошибки в святом коде Яндекса ))
Теперь немного троллинга, раз так просите
2. Автору показали на ошибку в его коде. Реальная ошибка или кажущаяся это другой вопрос — но по большому счету проявили заботу про его код, про его дело и его статус. Провели бесплатный анализ, чего то нашли, чего то не написали.
Ответное предложение автора статьи померяться толщиной кода говорит только об одном — в Яндексе в разработке нет ни математики, ни теории алгоритмов, ни покрытия тестами. Чей «код толще» тот и в проде.
При Сергее Павловиче, сотрудник улучшивший его техническое решение не расстреливался, не ссылался на каторгу или подвергался остракизму — нет!!! Такой человек получал премию на следующий день после утверждения его решения техсоветом. Именно поэтому первыми были в космосе и космос был наш.
А в Яндексе, я так понимаю, любая ошибка найденная в коде начальника — прямой путь к увольнению. И именно поэтому Яндекс в интернете на вторых ролях.
Ну и совсем hard троллинг. Всё по заявкам. Piradius должен быть доволен
3. А ведь про ошибку эту прочли не только друзья автора статьи, но и недруги. И код они свой написали и сравнили его с кодом автора и в нужный момент в нужном месте ведь вытащат — как автор статьи сознательно не правил ошибки в святом коде Яндекса ))
Давай я напишу. Я понял о чем он. И в этом есть смысл.
public static void main(String[] args) {
byte[] data = new byte[10];
byte[] selected = new byte[5];
int currentSize = 10;
var random = new Random();
random.nextBytes(data);
for(int i=0; i<5;++i) {
int pos = random.nextInt(currentSize);
selected[i] = data[pos];
if(currentSize-1 != pos) {
data[pos] = data[currentSize - 1];
}
--currentSize;
}
}Ура! Спасибо! :) Так действительно не нужно делать массовых сдвигов и не нужно обрабатывать коллизии за счёт того, что выбранные элементы отправляются в конец массива, это корректный алгоритм!
Но требуется знать размер заранее и требуется изменять входные данные — т.е. для потоковой обработки всё-таки не подходит.
Но требуется знать размер заранее и требуется изменять входные данные — т.е. для потоковой обработки всё-таки не подходит.
- Если нет оценки количества элементов — то что не то с архитектурой?
Во-первых, "оценка количества" — это приблизительная величина, а в предложенном вами варианте "получить быстро К номеров" нужно точное количество N.
Во-вторых, даже если все данные могут уместиться в оперативной памяти, то есть структуры, в которых нельзя получить N за константное время.
Самый простой пример — простейшая реализация связанного списка, в которой подсчёт количества элементов требует одного прохода по списку.
Более сложные примеры, в которых в принципе может быть невозможно получить все данные одновременно целиком, чтобы посчитать количество элементов — потоки данных, или, как в статье, MapReduce-таблицы.
И зачем в таких случаях пытаться считать N, если есть алгоритм, который его не требует и при этом работает в один проход по данным?
здесь просто всем честно следует признаться, что таковы правила игры. Яндекс ни от кого не скрывает свои задачи, их эйчар уже даже присылает чуть ли не образцы тех задач, которые спрашивают на собеседованиях и никто никому не мешает подстроиться под эти правила, выучить сортировки, деревья и прочие штуки. С другой стороны, было множество статей, про то, как действительно крутые разработчики физически не могут писать на досках, листках, не могут писать программы по таймеру или под страхом смерти — кому в действительности нужны эти скиллы?
Для полноты картины, нужно было также написать, сколько % рабочего времени вы вообще не используете те алгоритмы, которые спрашиваете, а то статья выглядит как неубедительное оправдание перед теми, кто не прошел собес)
Для полноты картины, нужно было также написать, сколько % рабочего времени вы вообще не используете те алгоритмы, которые спрашиваете, а то статья выглядит как неубедительное оправдание перед теми, кто не прошел собес)
def dictFromString(s):
Counter?
интересная и честная статья, спасибо
Какой-то диссонанс между громко кричащим названием статьи и ее содержимым. Серьезно, ваши программисты пишут такой код каждый день? Если так, то почему этот код до сих пор не вынесен в библиотеки и не переиспользуется?
А вы каждый день используете вообще все библиотечные функции вашего языка? Следуя вашей логике, библиотечные функции — не нужны.
Даже если код вынесен в библиотеку, программист должен знать, что ему понадобится алгоритм, чтобы вообще начать его искать. Иначе влепляется полный перебор или пирамидка из for и все. Сама мысль взять реализацию, условно говоря, стека, ну или там балансированного дерева из стандартной библиотеки, не возникнет у человека не умеющего в алгоритмы. И код ревью этот код пройдет, потому что в копании все такие.
Поэтому при прочих равных, компаниям лучше подойдут разработчики, которые алгоритмы знают и умеют думать. А еще это очень удобный и формализуемый критерий. Поэтому его и используют для отсева кандидатов.
для понимания того, что не надо писать пирамидки из for, не надо уметь по памяти реализовывать на собеседовании всевозможные алгоритмы, которые интервьюер вспомнит. Чувствуете разницу?
еще раз, что такое по вашему «знать алгоритмы»?
лучше подойдут разработчики, которые алгоритмы знают и умеют думать
еще раз, что такое по вашему «знать алгоритмы»?
для понимания того, что не надо писать пирамидки из for, не надо уметь по памяти реализовывать на собеседовании всевозможные алгоритмы,
Да, это условие не необходимое, но достаточное (за исключением каких-то крайне вырожденных случаев). Если человек понимает алгоритмы, может на интервью решить несложную задачку (типа описанных в этом посте), то почти гарантированно у него есть какое-то понимание о "пирамидках из for". Точно так же, чтобы знать условный матан, не обязательно сдать экзамен в университете. Однако, экзамены используют как аппроксимацию этого факта.
еще раз, что такое по вашему «знать алгоритмы»?
Иметь представление о теории сложности (например, понимать что O(2^n) для n порядка 50 будет "довольно медленно"), уметь решать простенькие алгоритмические задачи (типа того, что в этом посте, например), уметь преобразовать описание решения в код за приемлемое время, понимать какие есть стандартные структуры данных и иметь представление о их сложности (стек, список, сбалансированное дерево поиска, хеш-таблица, trie), хотя бы раз в жизни видеть описание основных стандартных алгоритмов (обход в глубину/ширину, сортировки).
Эта база позволит программисту, когда такая нужда возникнет, написать эффективный, понятный и простой код. Этот программист не будет смотреть с выпученными глазами на чужой код в котором применяется какой-то алгоритм или что-то чуть сложнее стандартного контейнера.
И последнее, вот в посте пример нескольких задачек, типа тех, что задают на интервью. Где здесь "всевозможные алгоритмы, которые интервьюер вспомнит"?
Вопрос про:
А не лучше будет так:
Т.е. не на каждом шаге вычислять best, а только когда закончится последовательность?
def foo(nums):
current = 0
best = 0
for n in nums:
if n > 0:
current += 1
best = max(best, current)
else:
current = 0
return bestА не лучше будет так:
def foo(nums):
current = 0
best = 0
for n in nums:
if n > 0:
current += 1
else:
best = max(best, current)
current = 0
return bestТ.е. не на каждом шаге вычислять best, а только когда закончится последовательность?
а если она не закочится нулём?
справедливо, но всяко быстрее будет:
def foo(nums):
current = 0
best = 0
for n in nums:
if n > 0:
current += 1
else:
best = max(best, current)
current = 0
return max( best, current )
1. Асимптотически никакой разницы нет.
2. Даже если оптимизировать количество операций, то тоже не поможет. Мы же не знаем сколько единиц в массиве. А что, если там нулей сильно больше, чем единиц?
2. Даже если оптимизировать количество операций, то тоже не поможет. Мы же не знаем сколько единиц в массиве. А что, если там нулей сильно больше, чем единиц?
Если единичек больше, чем ноликов — будем чаще проваливаться в одну ветку алгоритма; если наоборот — в другую. Заранее не знаешь, какой вариант выгоднее.
Мне нравится вариант с обновлением в ветке про единичку, потому что в таком случае не возникает корнер-кейса с обработкой последнего элемента.
Мне нравится вариант с обновлением в ветке про единичку, потому что в таком случае не возникает корнер-кейса с обработкой последнего элемента.
Можно также слегка уменьшить кол-во проходов!
Предположим, что в массиве из 100 элементов, мы нашли 50 повторов и при этом находимся на 51 позиции, которая является нулем. В таком случае нет дальнейшего смысла делать проход оставшейся части массива, так как в лучшем случае у нас может быть найдено 49 новых повторов.
if max_counter >= len(l) - k + 1 and counter == 0:
return max_counter
Пожалуйста, мутируйте аккумулятор в reduce и перестаньте нагружать машины пользователей избыточным и неоптимизируемым кодом!
acc = acc.concat(part.split(';').filter(Boolean));
// -->
acc.push(...part.split(';').filter(Boolean));
НЛО прилетело и опубликовало эту надпись здесь
Проверять программиста по алгоритмам на листочке (ну или не на листочке, а в браузере в специальном сервисе, которой так далек от IDE) — это самое последнее средство, которым нужно пользоваться, если и только если, на рынке об этом программисте ничего не видно/не слышно. Я имею ввиду код на GitHub, ответы на SO, выступления на конференциях, участие в OpenSource, технический блог, статьи в технических/научных изданиях — вот это все оценивает программиста лучше, чем онлайн решение стандартного алгоритма на собеседовании. Более того, те способы, которые я указал, при проверке кандидата не требуют участия самого кандидата, то есть можно отбирать программистов не по резюме, не по беседе (это все важно, но на следующем этапе), а по реально сделанным им делам (написанному коду, если хотите быть ближе к алгоритмам), которые свободно доступны на рынке. Эти способы дадут о программисте многообразную информацию: командная работа, знание git-flow, умение работать с трекинговой системой, умение общаться с другими разработчиками (ваши любимые SOFT SKILLS), знание основных библиотек, применение паттенрнов, понимание фреймворков, чистоту кода.
Думаю, в подобном стиле можно было бы написать статью про важность unit-тестов, про неотъемлемый статический анализ, про необходимость CI/CD, про обеспечение качества с помощью команды QA. И в 99% знание подобных процессов важнее знания написать бинарный поиск без ошибки (может, потому что стандартные алгоритмы обработки данных уже реализованы?...).
Но на собеседованиях все равно продолжают просить написать очередной абстракный fizz-buzz (а на работе в таких компаниях просят еще писать код без ошибок).
Остановитесь! Вы спрашиваете алгоритмы не потому что они действительно требуются инженерам в ежедневных задачах, а потому что вы по-другому не научились отбирать кандидатов! Я не хочу работать в команде, где разработчиков нанимают по зазубренным стандартным наборам алгоритмов/вопросов, к которым нужно еще и готовиться (видимо, чтобы угодить собеседующим, лицемерие), потому что в таких командах о разработке, как о процессе, не знают ровным счетом ничего.
Остановитесь!
Зачем? Пусть лучше доводят процесс найма до абсурда. Нормальные люди к ним не попадут и не потеряют свое время, а душные любители алгоритмов с завышенным чсв не будут создавать конфликты в коллективах нормальных компаний.
Плюс всегда есть шанс, что компания с таким подходом к организации труда в целом (когда всевозможные формальные показатели сотрудников и соискателей важнее конечного результата) либо разорится, либо будет стабильно большие убытки нести, которых можно было бы избежать
Я имею ввиду код на GitHub, ответы на SO, выступления на конференциях, участие в OpenSource, технический блог, статьи в технических/научных изданиях
А если у меня, допустим, семья, (или, упаси бог, я в свободное время не хочу писать код, а хочу заниматься своими хобби)?
А как проверить, что этот код на гитхабе написал именно этот человек, и он не скопипащщен откуда-то? Блоги, выступления и статьи — это слишком нишевая область, чтобы всех массово по этому оценивать.
Конечно, можно для таких звезд сделать отдельное интервью — где оценивают выступления/статьи/лекции кандидата. Но если кандидат — такая звезда, неужели он так и не смог прочитать одну книжку типа "Cracking code interview"? Голова у такого гения варит — ему и времени на подготовку тратить-то почти не надо.
А если у меня, допустим, семья, (или, упаси бог, я в свободное время не хочу писать код, а хочу заниматься своими хобби)?
Да, свободное время — это личное для каждого. Естественно, что не все программеры тратят свободное время на OpenSource. Но давайте на секундочку вспомним, когда последний раз мы использовали OpenSource в своем коде на работе? Кажется, каждый день, потому что доля открытого кода в большинстве проектов на ваше удивление — гигантская. Неужели ни разу не было случая, когда нужно было создать issue в гитхаб или подправить код вашей любимой OpenSource библиотеки? И ни разу не надо было вопросы на SO создавать? Во многих компаниях есть культура OpenSource, то есть вы можете в рабочее время коммитить в открытый репозиторий GitHub — ну так покажите, какой вклад вы там внесли. Неужели ни разу вы не разбирались в какой-то теме так хорошо, что могли бы рассказать о ней всем в виде доклада на конференции или технической статьи? Пусть после работы вам некогда, но потратьте рабочее время на это, объясните своему руководству, что вы занимаетесь документированием вашего крутого алгоритма, и выложите этот документ на habr, или еще лучше вместе с исходниками в GitHub. Что, GDPR? Ну так просто не выкладывайте данные клиентов компании. Ваш код скорее всего не нужен никому, он решает какую-то конкретную проблему, и скорее всего договориться с руководством о его открытии будет очень просто.
Дело не в отсутствии свободного времени на эти задачи, а в общем понимании того, как работает IT рынок, и как вам в нем двигаться как профессионалу.
А как проверить, что этот код на гитхабе написал именно этот человек, и он не скопипащщен откуда-то? Блоги, выступления и статьи — это слишком нишевая область, чтобы всех массово по этому оценивать.
Если вы работали над этим проектом, то никакой проблемы не возникнет посмотреть в историю git. Историю git можно подделать? Ну камон, кто-то серьезно будет этим заниматься? Ну вас на беседе спросят об особенностях этого проекта, и вот тут вы ничего подделать не сможете. Вот представьте год работы над собственным открытым проектом на GitHub. Представили? Так вот, там будет около 500 коммитов или больше, за это время, если вы сделали что-то интересное, у проекта появятся пользователи, они будут создавать вам issue, вам придется на них реагировать, писать пулреквесты чтобы закрыть эти issue. Это не подделать. Проект либо ваш, либо вы над ним еще мало трудились.
Но если кандидат — такая звезда, неужели он так и не смог прочитать одну книжку типа "Cracking code interview"? Голова у такого гения варит — ему и времени на подготовку тратить-то почти не надо.
Не в звездах дело. Если вы занимаетесь своей работой инженера — вы звезда? Вот вы пишете каждый день, скажем, чат бот для телеги, например на java на протяжении двух лет. Java SDK для бота телеги — не совершенное, за два года вы словите там не один десяток багов, вам будет не хватать его функциональности, и вам, если вы понимаете, что такое разработка, прийдется создавать issue и пулреквесты в Java SDK для бота. И вот через два года — вы уже активный контрибьютор в этой библиотеке. Что, вы звездой стали? Да нет, это обычная работа. За эти два года вам прийдется задавать вопросы на SO, потому что вы будете искать ответы, чтобы решить какую-то адски-сложную задачу, поставленную бизнесом, а там, внезапно, версия джавы не позволяет использовать последние сертификаты безопасности, и вы об этом узнали только благодаря вопросу, заданному на SO — и вот они, шаги к контрибьюту в SO в рабочее время (без отнимания этого времени от жены/мужа и детей). А дальше за два года работы над одним проектом вы по-любому сделали надстройку над той Java SDK для ботов, и она вся такая абстрактная гибкая и удобная, что вы захотите поделиться ей с соседом, или со всем миром, если уговорите своего босса выложить ее в GitHub, и потом еще статью напишете в habr. И что, вы звезда? Нет, вы простой инженер, вам дело нет до звезд ИТ индустрии, вы выполняете свою работу, и делаете себя дороже на рынке программистов, потому что хотите Range Rover.
Ух, слишком долго я веду к мысли — то, что делает программиста дороже (делает "звездой", как вы выразились) не означает, что он хорошо шарит в алгоритмах. Он хорошо шарит в разработке ПО, он знает, кто пишет код, к кому обратиться за помощью, где найти готовую реализацию известного алгоритма, он знает, как общаться с людьми при разработке продуктов. Он не звезда, он просто делает свою работу, и алгоритмы в ней — это такая капля в море, которую и замечать не всегда надо. Есть люди, которые пишут сайтики за $80 в час на RubyOnRails и не знают сколько будет 2^8. Вы думаете они плохие программисты? Нет, рынок их оценил в $80 в час за их умение вести разработку веб сайтов, потому что у них есть профиль на GitHub с готовыми примерами их работ.
А почему у вас в одном фрагменте кода на С++ std::vector, а в другом TVector?
Вместе с defaultdict в том же модуле лежит класс Counter и с ним можно написать код еще короче:
PS. Ага, нашел ответ в другой ветке. Тред не читай @ сразу отвечай.
def areAnagrams(a, b):
return Counter(a) == Counter(b)
PS. Ага, нашел ответ в другой ветке. Тред не читай @ сразу отвечай.
Я бы сказал, что в реальном практическом программировании есть ровно один самый ценный навык: «делать правильно с первого раза и за минимальное время». В широком смысле.
С данным навыком и алгоритмы, и шмалгоритмы коррелируют слабо, зато коррелируют такие вещи как ОО- и компонентный дизайн (да-да, он прекрасно есть и во фронтенде, еще почище), native-владение конструкциями ЯП (с этим у людей хуже всего: два фора и три ифа — и уже сложности написать), DRY, разбиение на независимые и узкие слои абстракции, культура юнит-тестов и т.д. — то, что на собеседованиях просто невозможно успеть покрыть ну никак. Поэтому и спрашивают алгоритмы — то, что можно успеть спросить и то, что хорошо отсеивает людей, не умеющих учиться.
то, что на собеседованиях просто невозможно успеть покрыть ну никак
О, буду впредь знать, что то, о чём я беседовал с людям на собеседованиях (40 минут на поговорить, остальное на вопросы кандидата и на решить мелкую задачу как тест против поддельных программистов) — его, оказывается, «невозможно успеть покрыть ну никак». Прошу прощения, я об этом просто не знал тогда.
Найм в Я совершенно не адекватный, увы это так, имперский отбор не позволяет набирать адекватных людей, приемущество как раз у олимпиадников.
Кстати, именно поэтому столько людей так сильно не хотят пройти это отбор, что не могут пройти мимо статьи в интернете, не оставив свое мнение. И именно поэтому Яндекс до сих пор такая маленькая и никому не известная компания.
Хорошая попытка накинуть на тему, не осилил вот и гадишь, но неожиданно осилил)
Проблему сильнее чувствуешь не тогда когда сам не прошел, а тогда когда позицию на соседнее место не могут закрыть от полугода и дольше, срезая нормальных кандидатов на странных задачах и странных секциях интервью.
Проблему сильнее чувствуешь не тогда когда сам не прошел, а тогда когда позицию на соседнее место не могут закрыть от полугода и дольше, срезая нормальных кандидатов на странных задачах и странных секциях интервью.
Комментарий совсем не про это, а про то, что вы записали в неадекваты половину Яндекса (включая себя, получается). Я не работаю в Яндексе, не люблю Яндекс как компанию (и не хочу там работать по многим причинам), но мне кажется странным считать, что такая компания построена неадекватами и на неадекватах.
Аа, так вы такие алгоритмы в Яндексе пишете каждый день? А я-то думал, что вы там реально магией занимаетесь, судя по вопросам с собеседований. Слушайте, ну тогда просто у людей спрашивайте: сможешь цикл обойти? Если сможет — можете смело брать человека на работу.
Давайте попробуем поиграть в синьоров, пришедших в Яндекс, осваивающихся с кодобазой. Думаю, у меня будет слабая попытка, но отказать себе не могу.
… Давайте посмотрим несколько случайный мест в нашем гитхабе.
Странные названия, не находите? «uni-gram» это же дословный перевод «one-word». Зачем тут завелся синоним? И какой смысл в переменной unigramHash? Нет, давайте пока оставим только wordHash, lastWordHash и twoWordHash, остальное уберем. А репозиторий проверим на этот анти-паттерн.
Подождите-ка, эта штука работает для всех хешей, а не только stop. Давайте убирать это уточнение. Убрали? Отлично, теперь эту функцию можно вынести в общую библиотеку и покрыть тестами.
Давайте посмотрим другой код, да, вот этот:
А что с фронтом? Так… Код на пол-страницы, обрабатывающий урлы типа /action?param=¶m=1;2;3¶m=8? Вы серьезно? Во-первых надо срочно разобраться, как вообще такой url мог появиться? Там где он появился может понадобиться не одно ревью и разгребание велосипедов. Во-вторых, кто ревьюит ваш фронтовый код? Как такой велосипедо-обработчик вообще выжил? Давайте разместим вакансию синьор-фронтенда, нам нужны регулярные ревью.
Теперь к аналитике. Хорошо, что она на питоне, это удешевляет разработку.
Какой странный фреймворк. Надо не забыть провести его ревью подробнее.
Да, похоже на маленький работающий код, какой аналитики пишут десятками в день.
Вы уверены что ты это так называется? Надо пересмотреть код нашей аналитики. Похоже что предыдущим дифирамбам в адрес наших аналитиков стоило доверять чуть меньше.
Похоже, здесь не задерживались люди с опытом разработки больших длительных проектов, надо узнать причины этого…
Настоящие синьоры, пожалуйста, закидайте помидорами за напрасные претензии.
… Давайте посмотрим несколько случайный мест в нашем гитхабе.
unigramHash = wordHash; Странные названия, не находите? «uni-gram» это же дословный перевод «one-word». Зачем тут завелся синоним? И какой смысл в переменной unigramHash? Нет, давайте пока оставим только wordHash, lastWordHash и twoWordHash, остальное уберем. А репозиторий проверим на этот анти-паттерн.
ContainsStopHash(...stopHashes)Подождите-ка, эта штука работает для всех хешей, а не только stop. Давайте убирать это уточнение. Убрали? Отлично, теперь эту функцию можно вынести в общую библиотеку и покрыть тестами.
Давайте посмотрим другой код, да, вот этот:
void Do(TMRReader* input, TMRWriter* output) override {...А что с фронтом? Так… Код на пол-страницы, обрабатывающий урлы типа /action?param=¶m=1;2;3¶m=8? Вы серьезно? Во-первых надо срочно разобраться, как вообще такой url мог появиться? Там где он появился может понадобиться не одно ревью и разгребание велосипедов. Во-вторых, кто ревьюит ваш фронтовый код? Как такой велосипедо-обработчик вообще выжил? Давайте разместим вакансию синьор-фронтенда, нам нужны регулярные ревью.
Теперь к аналитике. Хорошо, что она на питоне, это удешевляет разработку.
result = bl.GetMainResult()if result.IsA('TWebResult'):Какой странный фреймворк. Надо не забыть провести его ревью подробнее.
Да, похоже на маленький работающий код, какой аналитики пишут десятками в день.
Даже в этом достаточно простом случае от аналитика потребовалось уверенно владеть ассоциативными массивами, а также учесть некоторые особенности наших данных — в частности, проверить, что каждый элемент имеет правильный тип.
Вы уверены что ты это так называется? Надо пересмотреть код нашей аналитики. Похоже что предыдущим дифирамбам в адрес наших аналитиков стоило доверять чуть меньше.
Похоже, здесь не задерживались люди с опытом разработки больших длительных проектов, надо узнать причины этого…
Настоящие синьоры, пожалуйста, закидайте помидорами за напрасные претензии.
Ну я так скажу: иногда стоит немного обобщить и вынести в библиотеку, а иногда не стоит, т.к. для каждого использования придётся как-то докручивать, и это превратит жизнь в ад. Бывает так, что простые вещи проще реализовать по месту.
Приведу другой пример, но очень похожий. За свою жизнь мне пришлось несколько раз реализовывать [DSU](https://en.wikipedia.org/wiki/Disjoint-set_data_structure). При этом, конечно, у нас есть библиотечная реализация DSU, которую я всякий раз пытался использовать, но не получалось. Дело в том, что всякий раз вместе с каждой операцией надо было делать что-то ещё, что не ложилось в стандартный интерфейс структуры. Теоретически, это можно было бы сделать через наследование и какие-то доопределения, но в таких случаях сложность реализации значительно превосходила сложность реализации собственно DSU, плюс терялась локальность кода, плюс местами появлялись сайд-эффекты. Всякий раз я смотрел на это, немного грустил и реализовывал по месту (благо, на написание DSU уходит примерно 2 минуты с ноля). К счастью, штука простая и немногословная, так что структура с добавленной в неё DSU'шностью содержала, типа, 5% кода про DSU и 95% про остальное.
Ну и фактор времени надо учитывать. Если пытаться обобщать и класть в библиотеки вообще всё, что мы пишем, скорость разработки упадёт, наверное, раз этак в пять. Даже если оставить за скобками конкурентность среды, реализовать в 5 раз меньше классных штук за жизнь не устраивает даже лично меня!
Приведу другой пример, но очень похожий. За свою жизнь мне пришлось несколько раз реализовывать [DSU](https://en.wikipedia.org/wiki/Disjoint-set_data_structure). При этом, конечно, у нас есть библиотечная реализация DSU, которую я всякий раз пытался использовать, но не получалось. Дело в том, что всякий раз вместе с каждой операцией надо было делать что-то ещё, что не ложилось в стандартный интерфейс структуры. Теоретически, это можно было бы сделать через наследование и какие-то доопределения, но в таких случаях сложность реализации значительно превосходила сложность реализации собственно DSU, плюс терялась локальность кода, плюс местами появлялись сайд-эффекты. Всякий раз я смотрел на это, немного грустил и реализовывал по месту (благо, на написание DSU уходит примерно 2 минуты с ноля). К счастью, штука простая и немногословная, так что структура с добавленной в неё DSU'шностью содержала, типа, 5% кода про DSU и 95% про остальное.
Ну и фактор времени надо учитывать. Если пытаться обобщать и класть в библиотеки вообще всё, что мы пишем, скорость разработки упадёт, наверное, раз этак в пять. Даже если оставить за скобками конкурентность среды, реализовать в 5 раз меньше классных штук за жизнь не устраивает даже лично меня!
точки над Ё
Этот текст содержит грубые ошибки, а именно.
1. Грубая архитектурная ошибка. Просматриваются все записи, а их может быть много, для выбора нескольких. Например нужно выбрать 20 из 20.000 и автор просматривает все 20.000 не извлекая из них никакой информации, кроме той, что они есть. Это грубая архитектурная ошибка, обращение к БД это тяжелая операция и для получения 20 записей нет никакой необходимости просматривать все 20 тысяч. А вот эта фраза
2. Вторая грубая ошибка алгоритмическая — декларируя вот такую задачу
Теперь вторая часть вопроса:
Если кто то пытается хамством, тыканьем незнакомому и взрослому человеку показать корректность своего алгоритма — это глупый шаг. «Это хабр! детка» и никому тут хамством не докажете корректность своего алгоритма. Алексей Шаграев ashagraev Вы хам и неуч.
И третья часть:
Никто из сотрудников Яндекса так и не показал своему шефу всю глупость и некорректность его кода. Более того, статья верноподданически растет в рейтинге. У меня вопрос — это в интересах акционеров и кредиторов Яндекса? Они готовы переводить техническое обсуждение в хамскую перепалку? Вы на них работаете или на конкурентов? Они, акционеры, готовы использовать код(а это боевой код автора в Яндексе), вся корректность которого основана на том, что другие боятся или брезгуют обсуждать с автором корректность его самоделок и статья автора на хабре набрала много плюсов?
Завершение:
Эта ситуация лишний раз показала, что хабр, не смотря на заверения его управляющего и владельца, теряет техническую экспертизу. Превращается, как у дедушки Крылова, в место где «кукушка хвалит петуха, за то, что хвалит он кукушку». deniskin Вы такой хабр для себя хотели?
Представим, что мы перемешиваем входные данные случайным образом, а затем берём K стартовых элементов — очевидно, это будет статистически корректный способ. Чтобы получить первые K элементов, не нужно хранить весь перемешанный массив, по существу можно хранить только первые K элементов. В алгоритм std::shuffle тогда можно внести такое изменение: если очередной элемент меняется местами с одним из первых K элементов — помещаем его туда, а если нет, то не делаем ничего.
Другими словами: будем обрабатывать входные элементы по одному и при обработке очередного i-го элемента будем выбирать случайный номер от 0 до i включительно. Если этот номер меньше, чем K — поместим текущий объект в ответ, при необходимости исключив из него какой-то ранее уже добавленный элемент. Код reducer'а выглядит так:
void Do(TMRReader* input, TMRWriter* output) override {
TVector<TNode> sample;
TMersenne<ui64> mersenne;
size_t passedItems = 0;
for (; input->IsValid(); input->Next()) {
++passedItems;
size_t position = mersenne.GenRand64() % passedItems;
if (position >= ItemsToTake) {
continue;
}
if (sample.size() < ItemsToTake) {
sample.push_back(input->GetRow());
} else {
sample[position] = input->GetRow();
}
}
Shuffle(sample.begin(), sample.end(), mersenne);
for (const TNode& node : sample) {
output->Add(node);
}
}
Здесь TMersenne — наша реализация алгоритма mersenne twister, то есть хороший генератор псевдослучайных чисел, TNode — структура, хранящая одну строку MapReduce-таблицы.
Эта реализация позволяет тратить объём дополнительной памяти, пропорциональный длине ответа и не зависящий от объёма входных данных.
Этот текст содержит грубые ошибки, а именно.
1. Грубая архитектурная ошибка. Просматриваются все записи, а их может быть много, для выбора нескольких. Например нужно выбрать 20 из 20.000 и автор просматривает все 20.000 не извлекая из них никакой информации, кроме той, что они есть. Это грубая архитектурная ошибка, обращение к БД это тяжелая операция и для получения 20 записей нет никакой необходимости просматривать все 20 тысяч. А вот эта фраза
исключив из него какой-то ранее уже добавленный элемент.означает, что выбрасывая ранее выбранный элемент/ куча ресурсов потрачена на его извлечение/ автор выбрасывает деньги акционеров. Если для выборки 20 элементов требуется без всяких на то оснований 20 тысяч обращений к БД — это прокол в архитектуре.
2. Вторая грубая ошибка алгоритмическая — декларируя вот такую задачу
перемешиваем входные данные случайным образом, а затем берём K стартовых элементовавтор на самом деле её не решает. Вот пример: нужно выбрать 20 элементов из 20 тысяч и автор 20 тысяч раз генерит случайное число и тот, кто распоряжается случайностью ни разу не выкинул автору 19. Тут профессиональное сообщество, ну почти, а всем профи это ясно, что вероятность такого развития событий не нулевая — а значит алгоритм отработав так, как задумал автор, может выдать пустую запись на 19 позиции. Т.е. решена не та задача, что декларировалась, при перемешивании множество отображается биективно и пропуски невозможны — но алгоритм и код автора это позволяют.
Теперь вторая часть вопроса:
Если кто то пытается хамством, тыканьем незнакомому и взрослому человеку показать корректность своего алгоритма — это глупый шаг. «Это хабр! детка» и никому тут хамством не докажете корректность своего алгоритма. Алексей Шаграев ashagraev Вы хам и неуч.
И третья часть:
Никто из сотрудников Яндекса так и не показал своему шефу всю глупость и некорректность его кода. Более того, статья верноподданически растет в рейтинге. У меня вопрос — это в интересах акционеров и кредиторов Яндекса? Они готовы переводить техническое обсуждение в хамскую перепалку? Вы на них работаете или на конкурентов? Они, акционеры, готовы использовать код(а это боевой код автора в Яндексе), вся корректность которого основана на том, что другие боятся или брезгуют обсуждать с автором корректность его самоделок и статья автора на хабре набрала много плюсов?
Завершение:
Эта ситуация лишний раз показала, что хабр, не смотря на заверения его управляющего и владельца, теряет техническую экспертизу. Превращается, как у дедушки Крылова, в место где «кукушка хвалит петуха, за то, что хвалит он кукушку». deniskin Вы такой хабр для себя хотели?
Это грубая архитектурная ошибка, обращение к БД это тяжелая операция
Там нет ни слова про обращение к БД.
автор на самом деле её не решает. Вот пример: нужно выбрать 20 элементов из 20 тысяч и автор 20 тысяч раз генерит случайное число и тот, кто распоряжается случайностью ни разу не выкинул автору 19. Тут профессиональное сообщество, ну почти, а всем профи это ясно, что вероятность такого развития событий не нулевая — а значит алгоритм отработав так, как задумал автор, может выдать пустую запись на 19 позиции.
Автор генерирует случайное число только 20 раз и для каждого числа происходит обмен двух значений местами. Если несколько раз выпадет одно и то же число, то каждый следующий раз в ячейке с этим индексом будет уже другое число, потому что предыдущее уже оттуда переехало в начало массива и заменилось другим. Это все происходит внутри библиотечного вызова Shuffle (о чем автор написал).
Дальнейшее комментировать сложно.
Зато автору исходного комментария несложно экспертным тоном комментировать в духе «грубейшая архитектурная ошибка», не осилив распарсить один экран кода. А так да, whiteboarding-собеседования не нужны, конечно же, ведь все можно нагуглить.
Я не совсем правильно понял исходный комментарий, поэтому хочу добавить и исправиться.
Что на самом деле делает алгоритм?
1. Алгоритм проходит по исходному списку и выбирает k случайных элементов подряд.
2. После того как выбрано k случайных элементов следующие элементы могут заменить собой уже выбранные. Ситуации с пустой записью быть не может, потому что первые k элементов набираются подряд.
3. Уникальность выбранных элементов обеспечивается тем, что по исходному массиву мы проходим один раз и подряд. Пройти по нему полностью придется в любом случае.
Таким образом имитируется поведение исходного библиотечного алгоритма, но только для части выборки. Остается еще одна проблема — так как элементы выбраны подряд мы не можем считать их перемешанными. Но так как массив уже небольшой, его можно перемешать обычным алгоритмом (как в моем комментарии выше).
Что на самом деле делает алгоритм?
1. Алгоритм проходит по исходному списку и выбирает k случайных элементов подряд.
2. После того как выбрано k случайных элементов следующие элементы могут заменить собой уже выбранные. Ситуации с пустой записью быть не может, потому что первые k элементов набираются подряд.
3. Уникальность выбранных элементов обеспечивается тем, что по исходному массиву мы проходим один раз и подряд. Пройти по нему полностью придется в любом случае.
Таким образом имитируется поведение исходного библиотечного алгоритма, но только для части выборки. Остается еще одна проблема — так как элементы выбраны подряд мы не можем считать их перемешанными. Но так как массив уже небольшой, его можно перемешать обычным алгоритмом (как в моем комментарии выше).
Больше всего в комментариях под этой статьей расстраивают даже не срачи за алгоритмы, а количество желчи, которым народ готов облить тех, кто не вписывается в их картину мира.
Тем не менее, задачи довольно простые, за исключением разве что второй. Несравнимо с тем, на чем обычно гоняют на собеседованиях
Чем больше автор поста открыт к сомнениям и дискуссии, тем меньше желчи
Здесь нет дискуссии, здесь люди, которые которые не знают (и не стесняются в этом признаваться) обливают потоками желчи и уговаривают людей, которые что-то знают, в том, что на работу в компании (в которых никто не хочет работать, потому что там олимпиадники и неадекваты) надо брать без этих знаний.
По моему скромному мнению дискуссия возможна только тогда, когда обе стороны обладают знаниями об обсуждаемом предмете.
По моему скромному мнению дискуссия возможна только тогда, когда обе стороны обладают знаниями об обсуждаемом предмете.
возможно даже наоборот. Суть возмущения комментаторов в том, что они знают (как писать переиспользуемый понятный код без багов) и пытаются сказать людям, которые не знают, что на работу надо брать с этими знаниями.
Если после прохождения нескольких 5-часовых интервью коллеги пишут такой код…
> Будем обрабатывать элементы по одному, слева направо; рассматривая очередной элемент с номером i, сгенерируем случайное число от 0 до i включительно и обменяем значениями текущий элемент и элемент на выбранной позиции.
Вы уверены, что случайное перемешивание работает именно так? Нужно наоборот, идти с i-го элемента, и менять его со случайным элементом от 0 до i.
> size_t position = mersenne.GenRand64() % passedItems;
Это не эквивалентно тому, чтобы выбрать (равномерно) случайный элемент из диапазона 0..i.
Рассмотрите например случай если GenRand64 всегда ограничен дипазоном 0..4 включительно (для простоты рассуждения), а passedItems == 4. Тогда результат position == 0 будет встречаться чуть-чуть почаще, чем результат position == 1 например
Дальше, в основном алгоритме перемешивания элементы нужно свопать друг с другом. У вас этого нет. Вы уверены, что подход правильный? Где доказательство?
> if (sample.size() < ItemsToTake) {
sample.push_back(input->GetRow());
} else {
sample[position] = input->GetRow();
}
Вы уверены, что это выдаст (если исправить все предыдущие замечания) равномерно распределенный набор данных? Хотелось бы послушать доказательство
> Shuffle(sample.begin(), sample.end(), mersenne);
Так ли нужно в конце перешафливать массив еще раз? Неужели нельзя построить сразу зашафленный?
> Будем обрабатывать элементы по одному, слева направо; рассматривая очередной элемент с номером i, сгенерируем случайное число от 0 до i включительно и обменяем значениями текущий элемент и элемент на выбранной позиции.
Вы уверены, что случайное перемешивание работает именно так? Нужно наоборот, идти с i-го элемента, и менять его со случайным элементом от 0 до i.
> size_t position = mersenne.GenRand64() % passedItems;
Это не эквивалентно тому, чтобы выбрать (равномерно) случайный элемент из диапазона 0..i.
Рассмотрите например случай если GenRand64 всегда ограничен дипазоном 0..4 включительно (для простоты рассуждения), а passedItems == 4. Тогда результат position == 0 будет встречаться чуть-чуть почаще, чем результат position == 1 например
Дальше, в основном алгоритме перемешивания элементы нужно свопать друг с другом. У вас этого нет. Вы уверены, что подход правильный? Где доказательство?
> if (sample.size() < ItemsToTake) {
sample.push_back(input->GetRow());
} else {
sample[position] = input->GetRow();
}
Вы уверены, что это выдаст (если исправить все предыдущие замечания) равномерно распределенный набор данных? Хотелось бы послушать доказательство
> Shuffle(sample.begin(), sample.end(), mersenne);
Так ли нужно в конце перешафливать массив еще раз? Неужели нельзя построить сразу зашафленный?
Немного подумал, всетаки алгоритм больше похож на правду, чем я изначально предполагал.
Да, решение очень неочевидное, но красивое.
Тем не менее, 2 замечания остаются в силе. Во-первых это
> size_t position = mersenne.GenRand64() % passedItems;
Во-вторых, можно обойтись без последнего shuffle-а, если последний if заменить на
> size_t position = mersenne.GenRand64() % passedItems;
Во-вторых, можно обойтись без последнего shuffle-а, если последний if заменить на
if (sample.size() < ItemsToTake) {
sample.push_back(input->GetRow());
std::swap(sample.back(), sample[position];
} else {
sample[position] = input->GetRow();
}
Сомневаюсь большую часть алгоритмов нужно реализовывать самостоятельно, но понимать структуру данных, которую оптимально использовать под тот или иной алгоритм и как следствие понимать сам алгоритм все же полезно.
А вот со словами автора "не стоит думать, что алгоритмические секции на собеседованиях дают несправедливое преимущество программистам-олимпиадникам" не согласен. Первое собеседование у вас алгоритмическое. И после него если ты вдруг что то не знал (ты ведь не олимпиадные задачки на работе целыми днями решаешь верно) то к остальным этапам тебе доступ закрыт, каким бы ты опытным специалистом не был.
А что вас спрашивали на первом собеседовании в Яндекс?
Меня вот попросили проверить строку на палиндром. Что такое палиндром мне тоже рассказали. По сути надо взять строку, пройтись по ней циклом и написать несколько условных операторов. Но основная сложность как раз в уточнении условий и учете разных случаев.
Вторую задачку, увы, не помню. Но моего знакомого просили обойти дерево в ширину, в формулировке «Выведи дерево по слоям».
Ни в одной из этих задач нет большой завязки на алгоритмы, а что такое дерево и как устроена строка в его языке знают наверное многие.
Верно ли, что именно эти задачки вы назвали алгоритмическими, которые закрывают вход многим хорошим программистам?
Меня вот попросили проверить строку на палиндром. Что такое палиндром мне тоже рассказали. По сути надо взять строку, пройтись по ней циклом и написать несколько условных операторов. Но основная сложность как раз в уточнении условий и учете разных случаев.
Вторую задачку, увы, не помню. Но моего знакомого просили обойти дерево в ширину, в формулировке «Выведи дерево по слоям».
Ни в одной из этих задач нет большой завязки на алгоритмы, а что такое дерево и как устроена строка в его языке знают наверное многие.
Верно ли, что именно эти задачки вы назвали алгоритмическими, которые закрывают вход многим хорошим программистам?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Какие алгоритмы разработчики Яндекса реализовывают каждый день