Комментарии 494
Такое не лучше гуглить. Задача поиска максимального числа в массиве решается в голове быстрее, чем открывается новая вкладка в браузере. Если кандидат действительно гуглит это, я боюсь, это red flag.
Не доводите до абсурда.
"Абстрактный алгоритм поиска максимума в неупорядоченном списке на абстрактном вычислителе с абстрактным компаратором" и "поиск максимума в компактном массиве в конкретной архитектуре и конкретных типах" — две разные задачи. На интервью на разогреве, когда вас просят написать поиск максимума в массиве, ожидают обычно первое, а не второе.
Это я помню. А почему я не могу глянуть в документацию, если мне нужно что-то чуть сложнее, например, Aggregate оттуда же? Я обязан помнить порядок всех аргументов?
И это реальный кейс, который со мной случился вот прям сегодня. Я работаю как фулстэк и я помню, как в JavaScript сделать reduce, а что в шарпе у Aggregate начальное значение задаётся первым аргументом, а не последний, я забыл.
Это всё, да, red flag?
Вы придумали другую задачу, другой вопрос, другие требования и утверждаете что они абсурдные. Прекрасно. Что это доказывает?
Перед интервью я всегда говорю кандидатам, что если они не помнят что-то в стандартной библиотеке, то они могут смело написать как придётся, на полупсевдокоде. Мы не на спецолимпиаде по запоминанию параметров у всей стандартной библиотеки. На интервью, если меня спрашивают, я поступаю так же. Никогда не возникало проблем.
int max = 0;
if (array.Length > 0)
{
max = array[0];
}
for (int i = 1; i < array.Length; ++i)
{
if (array[i] > max)
{
max = array[i];
}
}Нет проблемы это расписать. Но есть проблемы в реализации.
Вот у людей есть проблемы с тем, чтобы это написать. Над такой задачей можно просидеть все 45 минут интервью и закончить решением за O(n^2). К сожалению, я не шучу.
Допустим C# синьер к вам на собеседование пришёл и первое что бы он подумал, если бы мне на собеседовании задали такой дебильный вопрос — значит есть какая-то подколка. А точно элементы в массиве не упорядочены хотя бы частично? А может есть какая-то эвристика и логично проверять массив как-то по другому, например известно максимально возможное значение?
Если уж вы тут заговорили о вычислительной сложности алгоритма сразу уточняющий вопрос — а какова длинна массива? А какой тип данных? А какой компилятор? На чё спорим, что при достаточной длине массива в C# будет эффективнее будет фикснуть массив и пройти по нему указателем в ансейфе? А если вы компилитесь через IL2CPP то лучше просто поставить директиву компилятора отключающую проверку границ массива, и которую я без гугла или подглядывания в своей проект ни в жизни не вспомню. А точно ли компилятор догадается, что два упоминания array[i] в теле цикла это одно и то же число и сунет его в регистр, или нужно ему на это указать.
А как должна обрабатываться исключительная ситуация когда элементов в массиве 0? Вы даже не обратили на это внимание, а между прочим такой код может подкинуть вам проблем.
А компилятор точно справится с оптимизацией прохода по массиву не с начала? А то вы рискуете нарваться на проверку Array bounds и доставание array.Length каждый раз из памяти.
И наконец самый главный вопрос, если вы рассчитываете составить о синьёре суждение на основании ответа на ТАКОЙ вопрос, может быть синьёру не стоит с вами работать?
А точно элементы в массиве не упорядочены хотя бы частично?
В такой задаче часто пишут "неупорядоченный массив", но вообще да, лучше спросить о таком.
Если уж вы тут заговорили о вычислительной сложности алгоритма сразу уточняющий вопрос — а какова длинна массива?
Если мы говорим про C#, то input.Length, где input — это название переменной/параметра.
А какой тип данных?
Чаще всего в таких задачах пишут "целых чисел, вот пример — [3, 2, 5]". В любом случае, можно спросить, или же решить задачу для более общего случая, там где на вход передается IComparer.
А какой компилятор?
Мы про C#? Вроде, эта задача решается более-менее одинаковым кодом, начиная с .Net 2.0.
На чё спорим, что при достаточной длине массива в C# будет эффективнее будет фикснуть массив и пройти по нему указателем в ансейфе?
Если кандидат простые задачи начнет решать через unsafe, то вопрос, выявивший подобное, уже сразу становится хорошим классификатором. А если еще и кандидат говорит с намеком на хамство "а на чё спорим", то вообще классно, что эта задачка встретилась.
В любом случае — алгоритм-то будет тем же самым, просто реализация немного иная.
А если вы компилитесь через IL2CPP то лучше просто поставить директиву компилятора отключающую проверку границ массива, и которую я без гугла или подглядывания в своей проект ни в жизни не вспомню.
Если мы говорим про "синьора", то кандидат и так знает, что foreach оптимизирован так, чтобы не было проверки массива. Да и стандартные циклы до .Length тоже иногда оптимизируются.
А так — комментарий хороший, хоть и не влияет на сам алгоритм.
А точно ли компилятор догадается, что два упоминания array[i] в теле цикла это одно и то же число и сунет его в регистр, или нужно ему на это указать.
Если это важно, сохраните в переменную. Если нет — то зачем задавать вопрос? Разве хоть кого-то отсеяли за отсутствие микрооптимизаций?
А как должна обрабатываться исключительная ситуация когда элементов в массиве 0?
Спросите "можно ли предположить, что в массиве есть хотя бы один элемент?". И действуйте согласно ответу.
А компилятор точно справится с оптимизацией прохода по массиву не с начала? А то вы рискуете нарваться на проверку Array bounds и доставание array.Length каждый раз из памяти.
Если интервьювера заботит этот вопрос, то он может спросить. Или же кандидат может ответить, если это действительно важно.
И наконец самый главный вопрос, если вы рассчитываете составить о синьёре суждение на основании ответа на ТАКОЙ вопрос, может быть синьёру не стоит с вами работать?
Это просто первая задача, чтобы проверить, человек занимается программированием, или нет. Просто самая база. Мы ведь не просто "сеньора" собеседуем, а "программиста-сеньора". Так что это буквально мелкий вопрос, чтобы проверить, что человек может решить хотя бы простую задачу, когда не надо долго и упорно понимать бизнес-область. По сути, проверяем, что "если человек понял, что надо на самом деле делать, то сможет ли он сделать хотя бы первые шаги".
Сеньорные вопросы будут потом.
Если кандидат простые задачи начнет решать через unsafe, то вопрос, выявивший подобное, уже сразу становится хорошим классификатором
Зачем тогда в видеокартах делают много ядер, которые решают 'простые' задачи, ведь засунуть данные в неё зачастую отдельный кодинг, муторнее чем тот же unsafe?
- В изначальном комментарии есть фраза "Допустим C# синьер к вам на собеседование пришёл". И нигде не говорится, что код пишется для видеокарту, или же что задача должна быть оптимизирована по-максимуму. И будем честны, что в большинстве случаев код на C# означает именно managed код, без дополнительных усложнений.
- Если у кандидата есть опыт оптимизации ПО, то можно было бы так и сказать "а хотите я на unsafe код оформлю, плюс приложу benchmark, что такой код работает быстрее?" После решения основной задачи тогда можно было бы классно поговорить на эту тему, если требуется. Но, по моему опыту, чаще всего специалист от компании просто ответит "нет, спасибо".
- Если кандидат вместо решения такой простой задачи как "поиск максимума в массиве" начинает говорить про космически корабли и видеокарты, то начинает создаваться впечатление, что или человек слишком сеньорный (и ему надо идти в Facebook/Google), или что человек просто не хочет писать сейчас код на собеседовании. В обоих случаях правильнее всего будет поблагодарить за потраченное время и распрощаться, чтобы не было неоправданных ожиданий.
Скорее всего, я плохо раскрыл мысль в своем комментарии. На первых этапах часто просят написать хоть какой-то простой код для того, чтобы понять, может ли человек написать ну хотя бы что-то тривиальное. Буквально чтобы отсеять людей, которые и программировать-то не хотят особо. Все сеньорные задачи про видеокарты и дизайн систем будут потом. Причина — немало приходящих людей даже эту простую задачу не могут решить ну хоть каким-то образом, к сожалению.
в большинстве случаев код на C# означает именно managed код, без дополнительных усложнений.Значит у вас, скорее всего нет задач, ради которых следовало бы привлекать меня. А задачи которые встают передо мной вы, скорее всего, просто на сможете сделать.
И даже не факт, что это плохо. Как говорится «Чем круче внедорожник, тем дальше бежать за трактором».
ФАтальная ошибка — думать, что хороший код нужен только гуглу с фейсбуком. Я работаю на C# для Unity и там оптимизация необходима примерно всегда если ваш проект хоть чуть-чуть поднялся над уровнем Indi (но не во всех частях проекта безусловно), потому что FPS сам себя не алё.
То есть вы как бы правы, остаётся только загадкой, а вообще вам вообще приглашать на собеседование синьеров и переплачивать им то полтинника и выше если ваш «managed код, без дополнительных усложнений» вам прекрасно напишет любой мидл.
Значит у вас, скорее всего нет задач, ради которых следовало бы привлекать меня
Да, я так и написал выше. Запросто может быть, что кандидат не подходит на должность или компания не подходит для кандидата.
То есть вы как бы правы, остаётся только загадкой, а вообще вам вообще приглашать на собеседование синьеров и переплачивать им то полтинника и выше если ваш «managed код, без дополнительных усложнений» вам прекрасно напишет любой мидл.
Я же написал совсем другое — подобная задача является необходимым, но не достаточным условием синьорности. Далее у кандидата все равно будут сложные задачи — на архитектуру и пр. Просто если не написал простой код, то смысла гонять по архитектуре?
Вообще, по опыту найма с hh.ru я по виду резюме обычно мог определить тех людей, которых стоит приглашать. Но надо сказать, что шанс ошибиться тут больше, а времени и техлида на такую сортировку тоже уходило больше.
Просто если не написал простой код, то смысла гонять по архитектуре?
Достаточно спорный момент.
Умение/неумение делать одно не всегда коррелирует с наличием и качеством других умений.
Потенциально я готов представить реально неплохого архитектора приложений, который не сможет сходу написать алгоритм оптимальной сортировки или поиска максимума. Просто потому, что в ежедневной работе ему это не требуется. При этом понимание оптимальности алгоритма у него есть, т.к. в институте соответствующую лабораторку сдал и нейроны в мозгу это зафиксировали, но на уровне понимания, а не досконального запоминания.
Если привести аналогию — директор по производству может не знать, как лучше вручную снять фаску с какой-то детали. Но должен понимать, что это за операция, и чего она стоит. При этом знание «как» хорошо скажется на его общение и авторитет у «простых работяг», но неизвестным образом влияет на результат его работы именно как директора. Потенциально, теоретик с MBA и без опыта работы с напильником может дать лучшие результаты на этой должности.
Потенциально я готов представить реально неплохого архитектора приложений, который не сможет сходу написать алгоритм оптимальной сортировки или поиска максимума.
Вы затронули очень важную тему — стоит ли управленцу быть хотя бы средним специалистом. А в противовес Вашему примеру я приведу свой — мне коллега рассказывала, что с ней работал Software Architect. Он был крайне хорош, закончил Оксфорд, по бумагам и речам вопросов не было. Опыт тоже присутствовал. Вот только он не знал, что такое Json.
Однако, вернемся к вопросу. В MBA практиках (если так можно сказать, так как литература там определена не совсем четко) есть разделение управленческих позиций на две группы — "исполнительный директор" и "управляющий директор". Первая группа — это не только управленцы, но и довольно неплохие спецы. То есть, условно, скрипт на питоне написать человек сможет, а потому человек способен разобраться в деталях того, что происходит. Вторая группа вообще не обязана быть специалистом в управляемой области. Но "управляющий директор" не выбирает способа, он обязан всегда полагаться на советы экспертов. По карьере получается так, что из специалиста сначала вырастает "исполнительный директор", который потом, после курсов MBA, может работать управляющим. Эти люди стоят очень дорого (насколько я смотрел в интернете — около £200.000 будет минимальная общая компенсация в год), а потому, если кто-то с зп менее 1млн рублей пытается выдавать себя за птицу высокого полета, то будет разумный вопрос — "а почему бы данной персоне не пойти на более высокий оклад в крупную компанию?"
Другой важный вопрос, который Вы неявно подняли, это соответствие должностей в разных компаниях. Архитектор в небольшой компании на 50 человек запросто будет middle developer'ом в крупной компании, что по зарплате, что по уровню знаний (кстати, тут я привел реальный пример из жизни).
В любом случае, мы говорим не о высоких должностях, а о довольно базовых — Software Developer. И для этой группы людей возможность написать код является базовой способностью. Из этого пункта растет все остальное — и возможность предложить более удобное решение для пользователя, и способность понять, почему архитектура Х не подойдет проекту.
int max = int.MinValue;
Так не надо: массив может содержать исключительно отрицательные числа.
Зависит ещё от коллекции.
В массиве в один поток на регистрах общего назначения - упрётся в АЛУ
В массиве в один поток с SIMD - упрётся в шину
В списке в один поток - упрётся в дата-столы (ожидание кэша) и тут как раз мультитрэдинг подходящая оптимизация.
Первое может вполне попасться подзадачей в каком-нибудь гугле или фейсбуке.
Топологическую сортировку в разных формулировках вполне задают в FANNG и FAANG-like конторах, да. Её при этом необязательно знать, чтобы суметь написать работающий алгоритм.
"Первое" лично я спрашиваю на собеседованиях в Гугле (ну не именно это, но в таком духе) — базовые навыки работы со списками/массивами, "напишите пару тестов", "оцените сложность вот этой вот функции из 5 строк кода" (никаких подводных камней), и т.д., и т.п. Даже на простой задаче можно очень содержательную дискуссию развернуть именно на понимание, а не на знание каких-то тонкостей.
90% приходящих людей с 20-летним опытом работы не понимают, что такое связный список…
Ну и читаем классиков.
90% приходящих людей с 20-летним опытом работы не понимают, что такое связный список…
наверное потому, что 90% людей за 20 лет работы ни разу не приходилось работать со связными списками
Если для вакансии умение работать со связными списками критично — выставляйте в требованиях.
Если нет — то зачем это проверять.
возможно, чтобы проверить умение разбираться со структурой данных? Понимать что такое ссылки и так далее.
Проверяют не умение работать с X а наличие каких-то знаний и умений позволяющих работать с X.
Условно если мне хочется знать силу кандидата я могу попросить его отжаться при этом мне важна сила, а не умение отжиматься.
Или я измерю температуру человека чтобы узнать, здоров ли он, хотя сама по себе температура интересует как признак. Просто градусником проверить быстрее, чем ездить в лабораторию.
проверить умение разбираться со структурой данных? Понимать что такое ссылки и так далее
Хотите проверить понимание абстракций — спрашивайте про абстракции. А не про специфичную структуру данных, которую первый и последний раз использовал в лабораторке те же 20 лет назад.
Проверяют не умение работать с X а наличие каких-то знаний и умений позволяющих работать с X.
Когда спрашивают про связный список — проверить можно только опыт работы именно со связным списком. А не то, сможет ли человек понять, как он работает.
Ибо ответ — «я не помню, что такое связный список» сразу засчитывается как отрицательный.
если мне хочется знать силу кандидата я могу попросить его отжаться
И если получите результат в 20 отжиманий, запросто решите, что силы недостаточно. А то, что при этом он сможет в рывке взять 200кг — останется за кадром.
Просто градусником проверить быстрее, чем ездить в лабораторию.
Угу, и получите классическую среднюю температуру по больнице. Которая ничего не говорит о конкретике. Например, что у человека последняя стадия рака. Но градусник сказал что здоров — значит здоров.
Хотите проверить понимание абстракций — спрашивайте про абстракции.
Мне хочется проверить навыки и умения. Не только знания. Если кандидат не справляется с задачей я и буду спрашивать, чтобы понять причину и подсказывать и пытаться понять.
И если получите результат в 20 отжиманий, запросто решите, что силы недостаточно. А то, что при этом он сможет в рывке взять 200кг — останется за кадром.
Вы были бы правы если бы я написал, что буду проверять только отжимания.
Например, что у человека последняя стадия рака.
Я не писал, что буду проверять только температуру.
Мне хочется проверить навыки и умения.
Вы уходите от темы.
Мой комментарий был про возмущение про то, что
90% приходящих людей с 20-летним опытом работы не понимают, что такое связный список…
типа это п… ц, а не программист.
Я утверждаю, данный пример — это проверка специфичной конкретики, которая практически ничего не говорит про общие знания и умения.
Вы были бы правы если бы я написал, что буду проверять только отжимания.
Ну вы же сами привели этот пример. И не упомянули никакой другой проверки. И я лишь указал, что данная проверка недостаточно для общей оценки.
типа это п… ц, а не программист.
Ну фиг знает. Одно дело, если он не знают, что означают эти слова "связанный список" другое дело, если не понимает даже после демонстрации структуры и не может решить задачу.
И не упомянули никакой другой проверки.
Я увидел здоровенных ребят в комбинезонах, ходивших в обнимку, чертыхавшихся и оравших немелодичные песни на плохие стихи. То и дело попадались какие-то люди, одетые только частично: скажем, в зеленой шляпе и красном пиджаке на голое тело (больше ничего); или в желтых ботинках и цветастом галстуке (ни штанов, ни рубашки, ни даже белья); или в изящных туфельках на босу ногу. Окружающие относились к ним спокойно, а я смущался до тех пор, пока не вспомнил, что некоторые авторы имеют обыкновение писать что-нибудь вроде "дверь отворилась, и на пороге появился стройный мускулистый человек в мохнатой кепке и темных очках".
Проверки всегда комплексные. Обычно когда спрашивают "полезен ли X" имеют ввиду "есть ли контекст в котором X полезен" а не "всегда ли полезен только X".
Например, если меня спрашивают полезны ли молотки — я скажу "да, чтобы повесить картину" но не обязательно скажу про лестницы, гвозди, шурупы и отвертки.
Одно дело, если он не знают, что означают эти слова «связанный список»
Возможно тут есть нюанс, что собеседуется сеньор, и ответить «да, конечно знаю» про вещь, которую он помнит очень приблизительно — психологически может быть непросто, с учётом того, что собеседование — это и так стресс.
Кстати, извиняюсь за излишнюю категоричность, т.к. в исходной цитате, было про «понимание» связного списка, а не про его «знание», невнимательно прочитал. Если задачи на уровне понимания — это действительно абстракция.
Я утверждаю, данный пример — это проверка специфичной конкретики, которая практически ничего не говорит про общие знания и умения.
Тут был бы уместен пример общего знания :)
Но вообще грамотно придумать вопрос намного сложнее, чем на него ответить. Ибо формулировка вопроса/задачи должна коррелировать с проверяемыми умениями, иметь критерии правильности ответа, отсекать возможность случайного угадывания и т.д.
В этом плане проще давать около-реальные задачи бизнеса, чем гонять по теории.
Уже упоминали те же массивы и списки, без которых не обходится ни одна более-менее сложная программа.
Что именно массивы и списки? Поиск максимального значения в массиве тут забраковали :)
В этом плане проще давать около-реальные задачи бизнеса, чем гонять по теории.
Околореальные задачи бизнеса уж точно не являются общим знанием.
Поиск максимального значения в массиве тут забраковали :)
Угу, потому что голая теория и никакой практики. В проде за такие велосипеды по рукам бить принято.
Околореальные задачи бизнеса уж точно не являются общим знанием.
Зато позволяют оценить, как человек думать и работать будет.
Хз, что и в какой пропорции важнее — знание или практика. Серебряной пули точно нет.
Хотите проверять теорию и общие знания — берите «учебник информатики» и ковыряйте вопросы оттуда.
Но будьте готовы к тому, что выпускник без опыта эти на вопросы сможет отвечать лучше, чем чел с 10+ годами опыта.
Хотите полезного работника — проверяйте практическими задачами.
При этом оба параметры важны, и нужно как-то комбинировать, чтобы отсекать людей без опыта и с опытом гугления, но без понимания сути.
Наверное, дело в том, что многие — и я в том числе — считают, что человек, не знающий, что такое список и как он устроен, программистом называться не может. Ну или массив, и в чем между ними разница.
Цель — проверить умение программировать вообще — решать программистские задачи. Какие поставят — такие и решать. И работа со списками — это только индикатор такого умения, как пишут выше.
Наверное, дело в том, что многие — и я в том числе — считают, что человек, не знающий, что такое список и как он устроен, программистом называться не может.
Изначально речь шла про связный список. Который в индустрии используется ОЧЕНЬ редко из-за его специфичности.
Цель — проверить умение программировать вообще — решать программистские задачи. Какие поставят — такие и решать.
Ну так и ставьте программистские задачи.
А в примере со связным список — проверяется знание теории и практики работы со специфичным типом данных. Оно может влиять на умение решать конкретно ваши задачи. А может и нет. Только это надо понять до того, как такие вопросы задавать.
А в примере со связным список — проверяется знание теории и практики работы со специфичным типом данных.
Да нет же! Проверяется умение решать поставленные задачи на простейших примерах. Не надо знать, как обращать связные списки, но надо понимать, как он устроен, и суметь решить задачу его обращения (придумать решение). Это не требует никакого заучивания. Это требует умения воплощать в коде элементарные алгоритмы. Работать с переменными, ссылками, памятью, понимать, что это вообще такое.
Не надо знать, как обращать связные список, но надо понимать, как он устроен
Ещё раз — неумение работать со связным списком говорит лишь о незнании связных списков. А не о том, сможет ли человек с ним работать.
Вопросы про массивы и листы на порядок более актуальные, ибо без них действительно программы не пишутся.
Я со своей point-of-view (сервера для высоконагруженных решений) скорее согласен с вами. Но не является ли наша точка зрения следствием искажения наших предметных областей.
Вот возьму какой-нибудь свой код на пайтоне (условный xmlrpc-server, обрабатывающий вспомогательные запросы) - там же вообще нет списков в явном виде (очереди \ пулы трэдов в наличии - т.е. это не тот код, который можно писать "совсем не приходя в сознание").
Т.е. вопрос а насколько условному "бизнес-программисту" (получающему свою вполне приличную ЗП в условном Сбер-Техе, и между прочим решающему реальные задачи) нужно знание списков - весьма актуален.
Мне кажется, это как костюмы для юристов - какой же ты юрист, если даже костюм приличный купить себе не можешь. Ну а для программистов - какой же ты, товарищ, программист, если даже такой элементарщины не знаешь. Суть в этом, а не в том, нужна ли она в работе - если человек даже списков не знает, значит, более сложные вещи и подавно.
Насколько это так в реальности - вопрос непростой - но мне кажется, логика именно такая.
Если для вакансии умение работать со связными списками критично — выставляйте в требованиях.
Гы. Требуется программист со знаниями: односвязных списков, поведением знаковых/беззнаковых целых при переполнении в (список языков), условий допустимости использования сортировки пузырьком.
Тогда чел будет знать, что его и по хештейблам погоняют, и различия между типами деревьев спросят, и списки попереворачивать попросить могут. И если не считает свои знания/опыт релевантным — то не будет тратить своё и чужое время.
А иначе появляются возмущения от собеседующих, что пришёл чел с опупенным заявленным опытом работы, а «на наши простейшие» вопросы ответить не может. Если для ваших задач это минимальный базис — заявите сразу. Опыт соискателя может быть сильно нерелевантен вашим запросам, несмотря на схожесть по общим признакам.
условий допустимости использования сортировки пузырьком
Моей фантазии не хватает представить, зачем это знание нужно кому-то за пределами института. С таким же успехом можно о различии поэтов серебряного века порассуждать.
В 99% случае всё, что надо знать о сортировке — это что она вызывается из библиотеки Math или подобной. Всё остальное нужно либо в 1% случаев (если не меньше), либо ведёт к появлению костыльных велосипедов.
На клиенте нет Big Data, и быть не должно.
Для этого есть Back End, там это может понадобиться, и нередко алгоритмы надо реализовывать руками в особых случаях с запутанными зависимостями. Это уже зависит от задачи, БД, заранее продуманной архитектуры.
Но в 1% это помогает и на фронте тоже иногда, когда он очень запутан. Не количеством данных, а сложностью алгоритма.
Сложилось устойчивое мнение, что для фронта это не надо никогда.
Ни разу не сталкивался с такой необходимостью даже на бэке, при том, что это мое основное направление.
Но в 1% это помогает и на фронте тоже иногда, когда он очень запутан. Не количеством данных, а сложностью алгоритма.
Не буду утверждать за конкретный случай, но делать собственную сортировку — имхо — последнее дело, когда по другому уже совсем никак.
Мне в своё время сильно понравилось такое высказывание про квалификации программистов: джюниор умеет решать простые задачи простыми методами, мидл — сложные задачи сложными методами, сеньор — сложные задачи простыми методами.
По ощущениям, к вашему примеру это высказывание очень хорошо подходит.
При наличии хоть какого-то запаса времени лучше разобраться со структурами зависимых данных, чтобы с ними проще работать было, чем в имеющуюся сложность ещё свою сортировку запихивать.
Никаких самописных велосипедов тут и близко не надо.
Но в любом случае — своей сортировки здесь не видно. Сортировать тут имеет только свой массив Топ20, чтобы последний(минимальный) его элемент сравнить с текущим значением из большого массива. Тогда сложность прохода по большому массиву будет o(n), а сложность сортировки массива 20 элементов, которая будет вызываться неопределённое кол-во раз (>=20, но по вероятности сильно < n) — скорее всего ничтожна, по сравнению с миллионами основного массива. Остаётся правда краевой момент с полностью отсортированным исходным массивом. Но кастомной сортировкой он всё равно не решится.
Но соглашусь, именно поиск максимумов тут получится самописный.
Хотя с точки зрения стоимости написания и отладки кастомного алгоритма, возможно можно пренебречь повышенной сложностью при использования стандартных методов, т.к. в рантайме даже при миллионах счёт, скорее всего, всё равно на доли секунды будет.
имеет ли смысл держать свой массив размером 20 в отсортированном состоянии или просто держать в отдельной переменной минимум и при каждой замене находить новый минимум и элемент который нужно заменить полным проходом. Этот вариант показал себя чуть лучше
Охотно верю.
Но вернувшись к нашим баранам — весь этот алгоритм к кастомной сортировке пузырьком или как-либо по другому это не имеет отношения. Сортировка, в итоге, может использоваться стандартная из библиотеки.
А можно вообще без неё обойтись, что, похоже, и получилось в итоге, т.к. задача свелась к поиску максимумов/минимумов в 2 массивах.
Эту задачу, кстати, я спрашивал на интервью в гугл, пока ее не забанили за извесность.
Тут не надо никаких 20 элементов много раз сортировать! Вот зачем нужно знать алгоритмы.
Тут можно, например, вместо сортировки использовать pritority_queue какой-то (храните в очереди на минимум 20 максимальных пока найденных элементов. Новый элемент или вытесняет минимум, или идет лесом).
Тогда вместо O(n log n) будет O(n log k) — при n=10^6 и k = 20, это ускорение в 4 раза. Плюс к этому оно сильно дружнее к кэшу и вообще константа у этого решения меньше. К сожаленю, в js нет встроенной структуры данных позволяющей реализовать priority queue малой кровью. Но структура весьма простая и так.
Но, если знать алгоритмы хорошо, то можно запилить чуть-чуть обобщенный QuickSelect, который в среднем работает за O(n) — это в 20 раз быстрее наивной сортировки.
Скажете: всего-то в 20 раз соптимизировали — фигня… Но тут 20 раз, там 2 раза, вот тут еще 20% скинули… Результат пользователю будет заметен.
Тут не надо никаких 20 элементов много раз сортировать! Вот зачем нужно знать алгоритмы.
В целом да, грамотность специалиста со знанием оптимальных алгоритмов выше, чем без оных. Но большинство рутины делается на гораздо более примитивном уровне.
А универсальный специалист стоит дороже. И рутиной ему заниматься скучно :)
Скажете: всего-то в 20 раз соптимизировали — фигня… Но тут 20 раз, там 2 раза, вот тут еще 20% скинули… Результат пользователю будет заметен.
Всё, что дольше 2-3 секунд ожидания пользователем ответа — оптимизировать надо. Разница более 30% заметна без секундомера, соот-но полезна к реализации при превышении тех самых 2-3 секунд.
Всё, что дольше 2-3 секунд ожидания
Вообще, 2-3 секунды это уже много, если каждая кнопка ждет по 2 секунды — это может раздражать, про игры вообще — целая вечность за которой персонаж успеет погибнуть.
По-хорошему человек не замечает замедления при ответе около 0.3-0.4 секунд, все что выше будет уже заметно.
некоторых ленивых языках можно просто сконструировать take 20. sort (сортируем и потом берём 20 первых)
Я не в курсе за «некоторые» языки, но по логике — последовательность операций take + sort сначала возьмёт элементы, а потом их отсортирует. А надо наоборот — сначала отсортировать, потом взять из верхушки отсортированного.
А о продвинутых языках, которые бы дали оптимизацию конструкции sort + sort я не слышал. Было бы прикольно, но боюсь в более-менее универсальном виде это нерационально трудоёмко для оптимальной реализации.
Хм... вообще теоретически нично не мешает Хаскелю соптимизировать это (и к стати это будет O(2*N) + (20*log(20), т.е. О(n)) до сортировки только требуемой части массива/
Но неужели он на практике это может (в смысле может так выкидывать не требуемые вычисления без кратного замедления требуемых)?
Может быть, чем алгоритмы оптимизировать (даже 1 млн элементов это немного) лучше подумать об общей архитектуре приложения?
Я не думаю, что в гугле "всё" оптимизированно. Во-первых, в больших компаниях есть разные отделы с разной иженерной культурой. Во-вторых, в разных продуктах и разных частях продуктов есть разные соотношения компромиссов между фичами/безопасностью/скоростью.
Я не знаю испытывает ли админка gmail для фирм какое-то конкуретное давление по скорости. Скорее всего вряд ли, тот кто принимает решение о выборе поставщика решения для почты учитывает этот параметр, так как оно не так часто используется как основной интерфейс и его может использовать админ, а не ЛПР.
Так вот, решения в маленьких конторах принимает руководство. Но оно не знает ничего про админку и автоматизацию.
А вот потом, это все попадает к разрабам, которые должны автоматизировать процессы и они сталкиваются с 30 сек. ожиданием и настройкой правил через очень удобный гугл скрипт.
Более того, имея ряд знакомых маркетологов, могу сказать, что и флагманские продукты гугла делаются плюя на пользователя. Монополия, могут себе позволить.
Так вот, решения в маленьких конторах принимает руководство. Но оно не знает ничего про админку и автоматизацию.
Ну вот и я об этом.
Более того, имея ряд знакомых маркетологов, могу сказать, что и флагманские продукты гугла делаются плюя на пользователя.
Тут мне непонятна связь между первой частью фразы и второй.
Эту задачу, кстати, я спрашивал на интервью в гугл, пока ее не забанили за извесность.
Тут не надо никаких 20 элементов много раз сортировать! Вот зачем нужно знать алгоритмы.
Зачем спрашивать то, что потом вообще не будет использоваться в реальном мире? Может быть начать спрашивать о вещах, которые повысят качество продуктов и удовлетворенность пользователей?
Зачем спрашивать то, что потом вообще не будет использоваться в реальном мире
Но ведь эта задача всплыла в этой теме именно как пример того, что нужно было решать в реальном мире.
За свое время работы в гугле мне периодически приходилось применять всякие приоритетные очереди, стеки, писать динамическое программирование и бинарный поиск, линейную регрессию, применять теорию чисел… Без всего этого, качество продуктов было бы еще хуже. Грузилось бы не 30 секунд, а все 120.
Сейчас я спрашиваю на собеседовании именно ту задачу, что сам лично решал в проде (сильно упрощенную и формализованную, конечно).
Это так не работает. Если вы находите какие-то примеры где это не используется это не значит что везде в гугле это не используется. Чтобы доказать, что что-то не используется, надо показать, что это нигде не используется. Т.е. вам надо не искать неоптимизированные продукты гугль, а перебрать все продукты или взять те продукты в которых оптимизация наиболее выгодна гуглу и показать на них
Учиник: разве мне когда-нибудь пригодится эта ваша линейная алгебра?
Экзаменатор: Вы её так плохо знаете, что точно не пригодится.
Потому что бизнес во главе решений.
Все продукты растут, требования меняются, новые фичи появляются постоянно. По хорошему, надо периодически переписывать с нуля с новым набором фич/требований, вместо наращивания слоев над существующими решениями. Что очень сильно дольше. Ну, или разрабатывать сразу конечный продукт, что тоже займет в n раз больше времени.
Technical debt, неподдерживаемые никем куски кода… Много ужасов промышленной разработки не обошли гугл стороной. Особенно гугл, в силу его размеров и обширности.
>> (>=20, но по вероятности сильно < n) — скорее всего ничтожна, по сравнению с миллионами основного массива. Остаётся правда краевой момент с полностью отсортированным исходным массивом.
Так храните свои 20 чисел в дереве (или любой другой структуре данных, поддерживающей):
- упорядоченность
- поиск за O(log(n))
- вставку O(log(n))
- удаление минимального O(log(n))
в следующей версии мне нужно было сделать это для, например миллиона чисел, и там решение близкое к o(n*log(n)) уже будет выглядеть немного не очень.
Но вы в курсе, что log n от миллиона это 6?
На практике, может оказаться, что алгоритм O(n*log(n)) будет работать быстрее O(n) и на миллионе, так как на каждую итерацию O(n) делает в 20 раз больше операций (например, постоянно держать массив из 100 000 наибольших чисел и сортировать его на каждой итерации — формально тот же O(n)).
А на миллиарде оба алгоритима могут упасть с OutOfMemory и их в любом случае нужно будет заменять.
То есть, не стоит ориентироваться только на O алгоритма в большинстве практических случаев.
Но вы в курсе, что log n от миллиона это 6?
А логарифм 20 — 1.3 — более чем в 4 раза меньше. Сокрашение в 4 раза — плохо что ли?
Потом, не надо забывать про константу. Логарифм вылезает из-за деления пополам и он двоичный. На самом деле, если тупо операции считать, то там будет не 6*n а 20*n. Потому что log_2(1000000)~20.
Сокрашение в 4 раза — плохо что ли
Смотря от какой цифры, если алгоритм работает 0.4 ms, а ответ нужно дать пользователю в течении 500 ms, сокращение в 4 раза до 0.1 ms не имеет большого смысла, намного важнее оптимизировать другие части системы.
Потом, не надо забывать про константу.
Да не стоит забывать про константу — не стоит забывать, что O(n) при равном n может выполняться и 1ms и один час, так как константа у O(n) при практическом применени может быть очень разной.
Например, формально ArrayList и LinkedList в java имеют одинаковый сумарный O, но на практике первый практически всегда быстрее, даже в тех случаях когда считая только O должно быть наоборот.
del
выбрать 20 наибольших чисел из 300-10000
- копируем 20 первых чисел большого массива в маленький;
- сортируем его, это нам даёт индексы минимального и максимального чисел в маленьком массиве;
- идём по остальным числам большого массива. Если находим число больше большего, записываем его на место мин и двигаем индексы на мин и макс. Что-то вроде кольцевого буфера;
- на выходе получаем массив из двух отсортированных кусков.
Йа мотематег?? :)
Йа мотематег??
Нет. Это не работает. Допустим вы ищете не 20 элементов, а 3 максимальных. И входной массив {1, 1000, 1002, 1001, 3, 4, 5}.
Ваш алгоритм не добавит в ответ число 1001, хотя оно там должно быть.
Да, точно… Надо дальше думать :)
Ну я и не синьор с другой стороны :)
В этой задаке нет ничего сеньерского. Самые базовые знания структур данных тут достаточны на самом деле. Вы правильно придумали, что надо поддерживать 20 максимальных чисел и обновлять их по мере сканирования всего массива. Но для этого надо удалять из 20-ти минимальный элемент, если новый элемент его больше.
Для этого отлично подходит структура данных куча, она же heap (на минимум). Это будет O(n log k), если вам надо выбрать k максимальных элементов. Для k=20 оно будет раза в 4 быстрее наивного подхода, если искать минимальный в массиве из 20 вручную или 20-ти независимых проходов по всему массиву.
Более продвинутый алгоритм — QuickSelect является модификацией QuickSort (но сортировки же не нужно знать, правда — кому они могут понадобиться?). Он работает в среднем за линейную сложность.
надо поддерживать 20 максимальных чисел и обновлять их по мере сканирования всего массива. Но для этого надо удалять из 20-ти минимальный элемент, если новый элемент его больше
Только тогда придётся пересортировывать маленький массив после каждой вставки. Хотя это не так страшно. Если маленький массив изначально отсортирован, то эта сортировка будет гарантированно выполняться за 1 проход, причём не обязательно по всему массиву, а только до того момента когда новый элемент займёт своё место.
Или есть вариант делать полную сортрировку после каждой 20-й вставки. Уж не знаю что лучше :)
но сортировки же не нужно знать, правда — кому они могут понадобиться?
Я отношусь к касте людей, уверенных что программист должен знать математику и алгоритмы :)
--
Это не задача на сортировку.
Примерно поэтому и стоит знать алгоритмы.
https://en.wikipedia.org/wiki/Selection_algorithm
>> В 99% случае всё, что надо знать о сортировке
Устойчивость \ неустойчивость зачастую важна. Но это, конечно, в мануале правильнее читать, чем помнить.
поведением знаковых/беззнаковых целых при переполнении в (список языков)
Это, на практике, тоже абсолютно бесполезно.
Всё, что надо знать о переполнениях — это то, что они бывают, и что если оно случилось — то это критическая ошибка, которую надо исправлять.
Необходимость закладывать логику программы на поведение состоянии переменной при переполнении — это совсем экзотика-экзотика. И там, где это действительно надо — простого знания о переполнениях мало, надо ещё чётко представлять, как это можно использовать в своих расчётах. В общем — это полноценное требования получается, а не та вещь, которую мимоходом обсудить можно на вакансию клепателя форм.
Ага. И даже возникает подозрение, что этот блок требований можно описать короче. Системный программист, например.
>> Это, на практике, тоже абсолютно бесполезно.
Ага, а пото драйвера крэшатся, при переполнении jiffies.
Это я к тому, что только ситхи всё возводят в абсолют, не надо так ;)
То есть вы реально можете привести, хотя бы гипотетический, пример, когда для чего-то важно знать, что конкретно произойдёт при переполнении?
Или, как я написал, в 100% случаев необходимо и ДОСТАТОЧНО делать так, чтобы просто не допускать переполнений?
Программист драйверов для ядра linux должен иметь в виду, что переменная jiffies (счётчик прерываний от таймера с момента старта системы) может переполнится (это цитата то-ли из LDD то или из комментария к linux_headers).
гарантируется размер не менее, чем uint64.
Что может произойти - из типового, что приходит в голову на каком-нибудь активном пуллинге с таймаутом (вычитывании готовности данных из устройства внутри драйвера) мы попадём на переполнение jiffies и "зависнем".
Дальше проблемы (не)снятия драйвера зависят от криворукости программиста в остальных местах.
Ещё раз - нужно знать, что переполнения бывают. Если это зависит не только от твоего кода - то надо знать, как это определить и что сделать, в случае переполнения.
Но как может быть полезно знание особенностей поведения переменной при переполнении, кроме определения непосредственно переполнения?
> что конкретно произойдёт при переполнении
а в этой:
> знание особенностей поведения переменной при переполнении
Разницу видите? Если нет: разница в том, что в первом случае включается «что сделает программа при переполнении», а не отдельно взятая переменная.
В C/C++ от этого могут, например, измениться условия цикла, быть выкинуты куски кода, убраны проверки, и так далее (вплоть до того, что сама переменная исчезнет и «поведение переменной» потеряет смысл).
И вот это — да, надо знать (и знать, как обходить неопределённость, делать явные проверки, и так далее).
Классик прямо говорит, что его цель — нанять звёзд, людей, которые для развлечения и удовольствия дома пишут на ассемблере. И строго предостерегает от найма людей, которые только похожи на звёзд или могли бы быть ими, но на самом деле не являются.
Это не совсем стандартная ситуация найма. А вот вопросы про связный список хотят сделать стандартными для любых собеседований.
Ну по мне так в этом цель любой компании, нет? Нанимать лучших из имеющихся…
Цель большинства компаний — нанимать работника, который сможет решить нужную для бизнеса задачу за установленное время и, по возможности, за минимальные деньги.
Это-то разумеется, но это очень сложно предсказать. Так что реальная стратегия — лучшие в пределах бюджета — это, по крайней мере, можно измерить.
Это не так. Предположим что вы "клепаете формочки" и вдруг на мизерную ЗП пришел человек, который "для развлечения и удовольствия дома пишут на ассемблере" и знает все языки и тп. Возьмет ли его реальный бизнес? НЕТЪ! Есть такое понятие — оверквалифайед — то есть квалификация существенно избыточна. В чем проблема такого кандидата — представьте что вам предлагают Мерседес по цене Жигулей. Заманчиво. Но в реале это как минимум настораживает — с чего это вдруг Мерседес по цене Жигулей — может он в угоне, он собран из говна и палок оставшихся после крушения нескольких Мерседесов и тп? В реальной жизни многие именно так и подумают и скорее всего откажутся от такого предложения — ибо да ну его нафиг. И это в среднем разумно. То же и с кандидатами, только в другой плоскости. Почему человек легко способный найти работу на 300к идет к вам на 60к? Он дурак? Даже если ему просто нужны любые деньги СЕЙЧАС, очевидно что он скоро уйдет на другую работу — на ту ЗП на которую он реально стоит или ему будет скучно и он забьет на работу и тп. Может он запойный? Не бывает так что товар (а работник продает вам товар — себя в аренду) вдруг стоит сильно дешевле рынка. Обычно разбираться никто не будет и просто откажут.
Единственный вариант если вы вдруг встретили такого спеца и проверки показали что он чист и проблем нет — это дать ему работу на ту ЗП на которую он стоит.
Ну или промежуточные варианты, вот пример из моей практики — взял человека который показал интересные проекты со времен школы и ВУЗа, но потом пару лет работал программером в каком-то НИИ и соответственно загнил там. Но я увидел потенциал и взял — директор не одобрил мое решение, но через 2-3 месяца, когда человек освоился с нормальной работой и режимом — человек стал давать хороший выход продукта.
Или другой пример — взяли человека с отличным опытом, но к сожалению с отсутствием в резюме нужных для "девочек-рекрутеров" ключевых слов. Впрочем довольно быстро добрав эти слова в резюме он стал у нас получать ЗП не ниже рынка для своих скилов — тут нам просто повезло что у нас распространена схема поиска работников типа — "я же НАЧАЛЬНИК, не царское это дело резюме читать — вот пусть девочка нихрена не понимающая в нашей работе читает и отбирает мне нужных кандидатов".
… за ограниченный бюджет и чтоб не убежал от скуки. Хотеть от него "про запас" больше, чем нужно для реальной работы — это именно ценник специалиста поднимать и завышать ожидания от работы. Или, при прижатом "ровно столько и не больше" ценнике, снижать количество пришедших, вплоть до нуля.
Да, в теории это тоже вариант, свести всех могущих откликнуться к одному единственному пришедшему "прям что надо", но что-то мне сомнительно.
По-моему логично — нанимать максимально хороших людей, вписывающихся в ваш бюджет. Разве нет?..
Over skilled тоже не любят.
Даже если у тебя тяжёлые времена прям сейчас, и ты готов на меньшую зарплату. Будут считать, что ты сбежишь в любой подходящий момент. Это большая проблема — притвориться потупее, чем ты есть, когда чуствуешь это.
Но сбежишь всё равно.
int?[] grades = { 78, 92, null, 99, 37, 81 };
int? max = grades.Max();
Но речь-то про собеседование, где ни один из ваших пунктов не актуален.
std::vector<int> array;
if (array.empty())
{
throw std::exception("Array is empty");
}
auto maxValue (array[0]);
if (array.size() > 1)
{
for (auto index (1); index < array.size(); ++index)
{
if (maxValue < array[index])
{
maxValue = array[index];
}
}
}
А сеньор сразу начинает грузиться на тему многопоточности, архитектуры, особенности исходных данных (Они как-то упорядочены? Какой у них формат? Какой у них размер?), предельно возможного размера массива, тестов, и еще 1024 подобных вопроса. И вот тогда начинается гугление, чтобы не изобретать велосипед, который к тому же скорее всего окажется менее эффективным, чем уже известное и отработанное решение. Или по крайней мере будут какие-то куски известного и отработанного решения, которые можно будет применить. Собственно говоря, ваш вопрос как раз и показывает, что вы не видите разницы между сеньором и мидлом. Задача в такой формулировке (найти максимальное значение в массиве) хороша для мидла: ему дали задание, он его решил строго «от сих до сих». А у сеньора в этот момент голова взрывается от обилия возможных вариантов, про которые ему ничего не сказали.
Нет, я не спорю, возможно, именно это и было целью данного вопроса: проверить меня как сеньора в этом аспекте, т.к. для сеньора задания из серии «пойди туда, не знаю куда, принеси то, не знаю что» являются вполне себе типовыми. И для начала надо при помощи утюга, паяльника, пассатижей и прочих специальных предметов выдрать из приславших задание определение «туда», потом выдрать из них же определение «то», потом убедиться, что они имеют согласованное между собой мнение, т.к. бывает, что желающие понимают под одними и теми же словами самые разные варианты вплоть до строго противоположных и т.д. И вот после всего этого можно уже задумываться об архитектуре и дизайне. Но я лично сильно сомневаюсь, что задающие подобный вопрос, имели в виду именно это, а не написание сферического кода в вакууме. Я конечно могу написать за полминуты ни о чем не говорящий вариант (что я, собственно говоря, и сделал выше), который ни в один продакшен не пойдёт по причине его полной ненужности, но при чем тут позиция сеньора? Как и что вышеописанный код скажет обо мне как о сеньоре?
Потому что я начну вообще не с задания, а с вопросов, в каком проекте это собираются использовать, и какие именно аргументы привели к тому, что для этого надо писать свой велосипед вместо использования уже существующих решений.
Вам скажут, "напишите пожалуйста самый простой код, который сможете прямо сейчас". Тут уж вопрос понимания. Если обе стороны изо всех сил стараются друг друга понять, то вы друг друга поймете. Если у вас эмоциональное убеждение что задача какая-то глупая, то вы сможете в любом случае затянуть все что угодно до бесконечности.
Что кстати, косвенный признак того, насколько вы будете хотеть понять собеседника на работе.
Как и что вышеописанный код скажет обо мне как о сеньоре?
Что вы обладаете базовыми навыками программирования, а это мастхев для сеньора.
А если не напишете что не обладаете и что не можете быть сеньором.
Если у вас эмоциональное убеждение что задача какая-то глупая, то вы сможете в любом случае затянуть все что угодно до бесконечности.
У меня не убеждение, что задача глупая, у меня мнение, что для позиции сеньора задача неполная. Если это проверка на мое умение как сеньора тащить задания / проекты с нуля, с неполной информацией и т.д., тогда все нормально (о чем я писал в предыдущем комментарии). Если же это проверка, могу ли я писать код на уровне джуна, то по моему мнению она выглядит абсолютно бесполезной.
Что вы обладаете базовыми навыками программирования, а это мастхев для сеньора.
Написание алгоритма на уровне джуна в по одной-единственной теме дает понимание того, что у меня есть базовые навыки программирования? А вдруг я знаю массивы, но не знаю списки? А вдруг я знаю массивы, но вообще не знаю деревья? А вдруг я знаю массивы, но не знаю разницы между указателем и ссылкой? И еще 1024 подобных вопроса. Если уж так важна данная тема, то давайте тогда сделаем полную проверку на все базовые знания: вдруг я еще чего-то базового не знаю. Дабы быть правильно понятым: нет у меня корона с головы не свалится по причине ее (короны, а не головы) отсутствия, и мне несложно этот код написать, но данная задача абсолютно бесполезна для позиции сеньора. Более того она вызовет у меня недоумение и подозрение: если подобный код проверяется на позиции сеньора, то чем, собственно говоря, я там буду заниматься? Писать что-то подобное?
что для позиции сеньора задача неполная
Конечно неполная. Есть еще все остальное собеседование. Но я говорил не об этом, а о том, что если вы захотите друг друга понять, то вы поймете.
Написание алгоритма на уровне джуна в по одной-единственной теме дает понимание того, что у меня есть базовые навыки программирования?
Ага. А ненаписание дает понимение что нет.
И еще 1024 подобных вопроса.
Конечно, собеседование не состоит из одной этой задачи.
Писать что-то подобное?
Писать не проще чем что-то подобное. Это задание не для того, чтобы дешево отсечь менее квалифицированные кадры, а не для того, чтобы только по нему судить сеньор вы или нет.
Вы почему-то рассматриваете только ситуацию когда это задание проходят, но не рассматриваете ситуацию когда это задание не могут выполнить.
>> т.к. для сеньора задания из серии «пойди туда, не знаю куда, принеси то, не знаю что» являются вполне себе типовыми.
Мне кажется, что вы сильно всё усложняете.
В моей практике в 90% (если не 95%-99%) уточнящий вопрос "а что реально надо-то?" расставляет всё по своим местам (в смысле ты получаешь +/- ссылку релевантную ссылку на условия решаемой задачи за минуту).
И излишнее усложнение общения (в том числе тонна необязательных уточняющих вопросов) - на первый взгляд характеризует вас отрицательно.
Как открыть и прочитать файл.
Как открыть JDBC коннект к базе.
И да, 20+ лет джавы.
И делаю это по одной простой причине — подобные действия делаются один раз в несколько лет (да и то не факт, можно просто скопировать этот код с предыдущего проекта), и улетучиваются из памяти сразу же, как закрыл вкладку с классом.
На джуна меня не возьмут, да? :-)))
Вы это серьезно? Если у вас вызывает сложность написание поиска максимального элемента в массиве — что-то сильно не так, неважно сколько лет назад вы с этой залдачей встречались. Это элементарная операция. Вот просто элементарная — неважно, сколько у вас лет опыта и с какими языками.
Если же задача не вызывает сложности, то в чем проблема? Лень? Или корона давит?
ну, волнение — это известная проблема, и это все-таки другая проблема. У меня подобное тоже случалось, и вообще я не то чтоб прям магистр кода. Но если уж я пришел на собес (на сеньорскую позицию, да), и меня просят написать что-то — я беру и пишу (ну, пытаюсь). Потому что… ну потому что могу, в конце-то концов.
Если у вас вызывает сложность написание поиска максимального элемента в массиве — что-то сильно не так, неважно сколько лет назад вы с этой залдачей встречались. Это элементарная операция.
Давайте рассмотрим типичную задачу выполнения свертки над изображением, превышающим размер доступной оперативной памяти, с варьируемым окном и ядром при использовании OpenMP/OpenMPI. Пусть ядро будет как раз функцией максимума. Покажите ваш код вычисления — не забудьте подумать, как совместно оптимизировать вычисления для набора заданных окон и так далее, ну да вы же сами все знаете. Заметьте, за плохой результат или его отсутствие вам ничего не будет, в отличие от рассматриваемой в статье ситуации:)
А может быть всё-таки рассмотрим типичную задачу на собеседовании, которую дают с целью проверить, что собеседуемый вообще может код писать?
По задаче: арендовать инстансы с бОльшим объемом оперативки, чтобы нужные куски в память помещались и использовать стандартные функции BLAS.
А это типичная задача для каждого, кто использует облачные вычисления для обработки космоснимков на Google Earth Engine, к примеру. Объем данных — порядка миллиона снимков (сцен) объемом гигабайт каждый. Да, вот такая предметная область и типичная в ней задача — автор статьи ведь не указывал свою предметную область, значит, речь может и о такой задаче идти. Вы точно хотите потребовать кластер с петабайтом оперативки на собеседовании? Не говоря уж про интернет канал, чтобы все это скачать. Адекватным решением будет яваскрипт для Google Earth Engine, который выполнится бесплатно за полчаса примерно (ну, как повезет, на самом деле, но может и за полчаса). Да, полезно представлять, как гугл это все реализует, но решить указанную задачу локально не получится все равно.
Для меня такие кодинг собесы — чистые стресс тесты и ничего более.
- так-с, это уже отличается от поиска наибольшего числа, но все-равно школьная задачка, сейчас за пару минут напишем, главное не как в прошлый раз, до закрытия офиса;
- не забудь про тесты!
- сравниваются не сами точки, а расстояния, надо лучшее расстояние сохранять, а правильнее его квадрат — сэкономим на корне;
- надо хранить отдельно указатель на лучшего кандидата… его индекс? а если мы больше не сможем обратиться по индексу, может вообще коллекция с переопределенным this[] или выборкой из БД? значит надо локально сохранять точку в переменную, но в худшем случае будет N копирований в эту переменную, лучше хранить таки ссылку, зависит от размерности;
- можно начать не с 1го элемента, с 0го, а лучшее расстояние присвоим в FLT_MAX, тогда любой член будет априори лучше, но не забыть проверку пустой коллекции;
- если считаем с 0го тогда можно вообще перебирать по итераторам или что у этой коллекции есть. правда, тогда ссылка не получится;
- погуглим по-быстрому что там в библиотечных методах;
- блин! забыл спросить про размерность — пространство или плоскость, или вообще 12 измерений, а универсальный вариант с интерфейсом или наследованием сожрет больше памяти, чем сами координаты, особенно 64-битный vtable;
- а есть ли у них кофе в офисе?
- хорошая библиотека выходит, всего на 1000 строк, но столько вариантов покрывает!
- как это час прошел???
Зарплата всегда представляет собой вполне определённую сумму, вполне себе конечную и ограниченную.
Бесконечно полное не требуется.
Не чувствуй себя гуру.
Общайся с бэком (если ты на фронте).
Выноси на общие обсуждения, с первого раза, со второго.
Ты должен решить проблему в любом случае, и лучше, чтобы оптимально.
Единственный значимый вопрос — возможно ли сохранение ссылки на элемент, с гарантией последующего доступа, ну и про кофе, конечно
А вот разумный вопрос — можно ли возвращать FLT_MAX при отсутствии элементов не прозвучал.
Но даже в этом случае можно было бы просто задать вопрос.
Вас всё-таки нанимают для решения проблем бизнеса, а не сидения в башне из слоновой кости.
Человек может решать задачу как ему удобно, главное качественно.
Вариантов решений море, и человек не должен знать ВСЁ, а должен уметь качественно использовать свои и ЧУЖИЕ знания (сообщество) и выдавать качественно решение.
Знание даже наоборот может сыграть – если человек знает хороший алгоритм, то это реализация, отладка, и возможные ошибки, в то время как коммьюнити может использовать давно проверенные и протестированные библиотеки. Тогда решение через "гугл" и быстрее, и надежнее, и проще.
Поэтому не вижу ничего такого в поиске решений через гугл, имхо J
Его умение отлаживать и искать ошибки — тоже предмет проверки.
Что касается продакшена, то велосипеды, конечно, писать стоит только в крайнем случае, вместо этого стоит пользоваться библиотечными функциями.
Так можно давать реальные задачи, и создавать реальные условия, и смотреть как человек адаптируется под изменения требований к решению и работает со своим же кодом.
Например:
Надо сделать форму авторизации. Потом добавить в форму поддержку разных стратегий авторизации (сервисов, через которые можно войти используя логин и пароль). Потом эта форма должна стать экспортируемым независимым модулем.
Он сначала напишет простую форму. Потом будет думать как построить передачу данных с одного интерфейса в разные точки, с разными интерфейсами. Потом если прибил всё это гвоздями, ему придется брать гвоздодер и разбирать свой же интерфейс.
Так и будет видно, насколько гибкое решение пишется, как оно поддерживается, и как он адаптируется к изменениям в реальных задачах, как пишет код. Чужие знания здесь не использовать, потому что задания реальные, не совсем типовые, думать придется самому.
Но с обеих сторон барьера мне трудно понять зачем помнить сколько байтов в IP или MAC адресе, какие ключи у команды 'ls', или зачем в уме считать netmasc.
Обидеть сеньора может каждый
Во всем сервисы по подготовке к интервью виноваты и книжки типа как крякнуть интервью на изучениях которых у мид+ плюс нет ни времени ни желания, а вот у ребят которые только залетают предостаточно.
На самом деле, проводя интервью, мне не важно как хорошо кандидат знает основы, алгоритмы, структуры данных, да даже язык на котором он пишет меня не очень волнует. Мне нужно понять может ли человек решать проблемы и я был бы рад дать ему написать объемное приложение чтобы оценить его со всех сторон, но у меня только час на интервью. Это значит что мне нужно придумать минимальную задачу в плане объема, за решением которой я смог бы проследить и понять, что из себя представляет человек, таких задач много на самом деле, и данный способ даже никого не бесил и всех устраивал какое то время…
А потом настал бум взломщиков собеседований появились всякие leetcode, hackerrank и тп, которые просто дрессирую разрабов на решение таких задач. Что привило к ситуации которую мы имеем сейчас, сложные алгоритмические задачи с использованием разнообразных структур данных, задачи на разогрев и подобный треш, который конечно никому из мид+ сегмента не нравится.
Мне нужно понять может ли человек решать проблемы
Вы в курсе, что вы — уникум? Вот правда, большая часть собеседований как раз выглядит как олимпиада при том, что «у нас весь софт свой, реальный хайлоад и все такое».
Это значит что мне нужно придумать минимальную задачу в плане объема, за решением которой я смог бы проследить и понять, что из себя представляет человек, таких задач много на самом деле, и данный способ даже никого не бесил и всех устраивал какое то время…
Иногда самое сложное не выдать тут же и решения. Я это называю ежиным тестом по аналогии со статье йМосигры.
Однако, надо заметить что не все соискатели готовы к таким собеседованием, мне много раз попадались люди у которых ни проблем ни достижений и вообще рассказать нечего. Я, правда, в таком случае делаю вывод, что в резюме сплошняком ложь.
мне много раз попадались люди у которых ни проблем ни достижений и вообще рассказать нечего. Я, правда, в таком случае делаю вывод, что в резюме сплошняком ложь.
Т.е. человек, работающий 10 лет в саппорте какой-нибудь CRUDной опердени, где основная проблема — составить внятное ТЗ из разрозненных фрагментов потоков сознания разных лет и разных источников мыслей, — автоматически лжец?
Я например подумал про первый вариант и сделал вывод — сеньер — это тот, который круды шлепает, не вдаваясь в логику решения проблем.
Это на самом деле завуалированное "а вы сами резюме писали, а помните что там насочиняли?" ;)
Полностью с вами согласен. Я, например, честно не помню, как синтаксически корректно написать цикл, потому что везде используем иммутабельные коллекции и методы — .map / .flatMap / .fold, и т.п.
Кандидат приходит устраиваться на работу водителем. В резюме у него пять лет за баранкой пылесоса грузовика и восемь — легковушки. Я сажаю его в малолитражку и прошу в качестве демонстрации проехать полсотни метров по прямой, повернуть направо и там остановиться возле знака «P». Почти оскорбительно простое задание, не правда ли?
Я наблюдаю, как машина глохнет, потом ещё раз глохнет, потом, после снятия с ручника, рывками начинает движение и на середине дистанции врезается в бордюр. Даёт задний ход, снова глохнет, теперь поперёк дороги. Ещё раз врезается в бордюр, поднатужившись, наезжает на него и тут же цепляет зеркалом дерево. Кандидат выходит, поправляет зеркало, догоняет скатывающуюся назад машину, ставит на ручник. Машина глохнет. После снятия с ручника трогается и врезается в дерево уже бампером. Задний ход, машина съезжает с поребрика на дорогу и каким-то чудом становится по направлению движения. Газу! Заветный знак «P» маячит вдалеке, как мираж, не становясь ближе, — но это потому, что кандидат газует на нейтрали. Новая попытка, и машина с визгом трогается с места, поднимая асфальто-резиновую пыль. Чуть было не пролетев мимо нужного поворота, машина в последний момент останавливается со скрипом тормозов. Не вписываясь в поворот, она ещё раз проезжает по поребрику и останавливается на противоположной от знака «P» стороне дороги.
Кандидат выходит из машины и объясняет свою езду так: «Вы знаете, я вообще-то готовился к собеседованию. Мне не сказали, что будет практический тест».
Источник: https://feldgendler.livejournal.com/2015/08/05/
На самом деле, для нормального сениора написание примитивного кода на интервью не должно быть проблемой без всякой подготовки. Я говорю не о собеседованиях в стиле "напишите алгоритм Кнута-Морриса-Пратта для разогрева", а о значительно более приземленных задачах, наподобие "напишите функцию разворота массива".
А вообще, из личных наблюдений, сениоры делятся на два типа. Первый в ответ на просьбу написать FizzBuzz жмёт плечами, иногда косо смотрит и пишет за 30 секунд. Второй начинает истерику о том, что он сениор, его не ценят, не уважают, унижают такими вопросами, и вообще код писать должны джуниоры, а он вообще больше по архитектуре.
— напишите функцию замены строки ДНК на другой участок ДНК
— напишите функцию фибоначчи
— напишите сортировку массива
— что такое замыкание
— что такое промис
-итд
А теперь главный вопрос — это серьезно задачи для архитектора и тех лида? Таких интервью у меня были десятки только за последние 10 лет моей 20-летней карьеры.
Понимаете, никак, вот совсем никак, такие задачи не раскрывают моих умений и знаний. Мне не сложно было написать эти функции и ответить на простые вопросы. Но где вопросы об архитектуре, о походах проектирования проекта, о организации документации, подходах к тестированию?
Когда таких интервью один или два — ты просто не обращаешь внимания. Когда десятки — это начинает раздражать.
Вам сложно ответить на такие простые вопросы, как вы привели? Это занимает пять минут и явно сигнализирует о том, как вы пишете код на микроуровне (в пределах одной-двух функций). Без нормального кода на микроуровне ваши навыки на макроуровне могут пригодиться разве что на позиции проджект-менеджера, но явно не на позиции сениор-разработчика.
Вы на джуниора, который спросит, что такое промис, отреагируете в стиле "ты серьезно меня об этом спрашиваешь?". Это уже про софт-скиллы, причем неявно, а не в лоб. Сениор с избыточным ЧСВ, который отказывается писать код — оно вам надо?
Обычно вопросы про "организацию и архитектуру" имеет смысл задавать тем людям, которые минимальную планку берут. А если нет — то зачем вообще?
Работодатель просто хочет увидеть, как будет писать код человек, которому, возможно, будут платить деньги за написание кода. Удивительное ЧСВ, да?
Вы знаете, на каждом интервью в компании, где я работаю, мы очень, очень хотим нанять человека. Каждому человеку, который проходит интервью успешно, мы очень, очень хотим платить деньги и очень, очень хотим, чтобы он работал у нас подольше и получше. Поэтому платят человеку после интервью очень, очень хорошо.
Не очень понимаю, зачем начинать отношения с человеком с агрессии и "сбива цены", не стремясь к хайру. Хайринг-мероприятия, интервью, время рекрутеров, время инженеров, поездки на интервью, оформление виз, перевоз людей и т.п. стоят денег, причем достаточно больших. Как-то тупо их тратить, чтобы "унизить и цену сбить, но не нанять", не находите?
Так что, к чему ваши замечания?
Ну так ответьте. К чему это нытьё?
Если после этих вопросов вам не задали нормальные вопросы, то это значит что вам с этой компанией не по пути. Собеседование двустороннее так-то.
Но все же повторю — мне не сложно было ответить и написать, что я и делал. И увы, придется делать в будущем.
И это не нытье, это разговор о полезности/бесполезности некоторых видов интервью.
это разговор о полезности/бесполезности некоторых видов интервью.Вы смотрите на это со своей колокольни, колокольни человека, который обладает знаниями сеньера и т.д., для Вас эти вопросы просты и пусты.
Проблема работодателя в том, что 9 из 10 кандидатов претендующих на позицию сеньера не осилят эти вопросы даже если они будут заданы им в виде домашнего задания с неделей на подготовку.
Такие вопросы это первичный фильтр откровенных самозванцев, которых действительно очень много.
Гитхаб и портфолио тоже не аргумент, т.к. неизвестно сколько там кода самого кандидата, а сколько заимствованного и как быстро и после скольких ошибок это было написано.
сразу нормальные «сеньёрские» вопросы
Про архитектуру, базы данных и патерны? Несколько раз встречал людей, которые отвечали на все такие вопросы, но сыпались на базовых знаниях языка — потом оказывалось они давным давно архитекторами и техлидами работали, но нам-то нужны были именно программисты.
раз ваши «сеньёрские» вопросы не отсеят — значит они вам подходят
Проблема в том, что в реальной жизни нужно не на вопросы отвечать, а программировать. А многие «сеньёрские» вопросы можно просто выучить.
Почему бы им сразу нормальные «сеньёрские» вопросы не начать задавать? Не отсеят?Во-первых, потому что это первый этап, который 9 из 10 не пройдут, и ни к чему тратить время сеньора для оценки ответов на сеньорские вопросы. На втором этапе — да, будут сеньерские.
А во-вторых, как ни парадоксально звучит — могут и не отсеять. На должность сеньора нередко проще пройти собеседование чем на должность миддла, т.к. ответы на вопросы более расплывчатые, неоднозначные и их проще выучить. При этом когда дело дойдет до практической реализации — тут наступает оппаньки.
Собственно не знаем как в россии, а на западе достаточно много «самозванцев» таки проходит все круги собеса прокачав скилл прохождения собеса, выучив базовую теорию и список типичных вопросов. А потом фиг их уволишь. А тестирование базовых практических навыков в реальной жизни их и срезает.
Могу предположить, что вы говорите с точки зрения «галеры», где позиция работника (с веслом в руке, и веслом в .....) определяется количеством проектов, которые он может закрыть своей тушкой.
PS: Без обид, тут я не пытался какой-то негатив в твою сторону пустить, наверняка, ты отличный программист и пишешь хорошие алгоритмы, тут скорее просто хотел отметить постановку вопроса :)
Характеризует. Если вы не смогли ответить, значит вы не senior dev
А теперь представьте, что интервьювер слабее вас. Вас для этого и собеседуют, что бы вы усилили команду.
О чем он вас должен спрашивать? О том, что сам не знает?
Если в компанию требуется специалист высокого уровня и в компании нет людей, способных провести интервью, то следуют двум путям:
— Затратный. Нанимают людей или компанию, с подходящим уровнем, со стороны для аудита кандидатов.
— Дешевый или сарафанное радио. Ищем среди друзей, людей с уровнем знаний и договариваемся за пиво/кофе/пиченьки.
Но признаюсь, я такое в своей жизни не встречал.
По крайней мере он может проверит что кандидат не слабее его.
Он может сделать это как раз тем способом, который раздражает сеньора-помидора.
О чем он вас должен спрашивать? О том, что сам не знает?
Честно говоря, не понимаю, а что в этом такого? Особенно если собеседуют на лида?
По тому, как отвечают, можно понять, уверен человек в своих ответах или нет. Можно понять, сможет ли он объяснить это менее сильным коллегам. Самому, в конце-концов понять какой-то технический момент.
Я вот в душе не гребу, что под капотом у async-await в C#. Но это не помешает мне понять, собеседуемый в этом разбирается или нет.
И да, в идеальном мире надо брать на работу людей, которые сильнее тебя.
И да, в идеальном мире надо брать на работу людей, которые сильнее тебя.
По моему скромному опыту, ближе всего к этому утверждению зарубежные работодатели. Но «заумность» ни в коем случае нельзя показывать в России. Я вот точно знаю пару моментов по которым я не прошел собеседования. Первый спросил у архитектора почему бы вам просто не масштабировать текущее java приложение через домен WildFly/JBoss. Второй раз спросив на собеседовании у представителя IBM/RedHat почему они рекомендуют Kubernetes, а не OpenShift. Я ни в коем разе не считаю себя сильнее интервьюеров, во всех случаях спрашивал из чистого любопытсва.
По тому, как отвечают, можно понять, уверен человек в своих ответах или нет
Поэтому чаще всего в таких случаях нанимают не специалистов, а эффективных менеджеров, прошедших тренинг уверенности в себе.
Ну вы не пойдете и ладно, я переживу. Зато я не найму те 40% "синьоров", которые приходят на собеседование на фронтэнд позицию и не могут рассказать, что такое замыкания и не понимают, как с ними работать. Вообще, такие заявления позволяют сделать вывод о том, что вы сами никого не собеседовали на регулярной основе.
Меня, например больше волнует понимание типов, причем не на уровне типов JS а на уровне TS. Всевозможные Nullsafe должны быть в крови опять же. Базовое представление о классах и наследовании (остальное сам доучу если нужно будет). А кроме того я лучше послушаю какие проблемы человек решал и как их побеждал (заодно и выясню кем было писано резюме).
А про замыкание пусть в гугле читает.
Понимаете, никак, вот совсем никак, такие задачи не раскрывают моих умений и знаний.
Еще как раскрывают. Во первых, все говорят, что им легко написать, но далеко не все напишут. Во вторых, умение составить элементарный алгоритм говорит о наличии алгоритмического мышления — умение анализировать и раскладывать задачу на кусочки.
Но где вопросы об архитектуре, о походах проектирования проекта, о организации документации, подходах к тестированию?
Есть люди, которые умеют четко изложить свою мысль, а есть те кто не умеют. Это также как и у писателей, кто-то «Ревизора» пишет, а кто-то с трудом доводит мысль до конца в сочинении «как я провел лето». Последние в любой архитектуре пишут хрень, а первым насрать на подход, главное чтобы какой-то был. Первых отличает аналитический склад ума, большой кругозор (в частности знание как что работает) и умение разложить задачу на кусочки. Всякие FAANG это давно поняли и дрючат народ задачками. А остальные могут и дальше растекаться мыслью по древу сравнивая ООП и ФП или DDD с Clean.
напишите функцию замены строки ДНК на другой участок ДНК
Вот это кстати очень похоже не на задачу, а на проверку умения вытягивать из заказчика требования. И в таком контексте вопрос не плох. Я недостаточно знаком с биохимией, но там, скорее всего, есть где развернуться.
Это, с одной стороны, очень хорошая задача, причем реальная, а не высосанная из пальца. Вы правы в том, что 1 ее этап — это вытягивание требований. Это вообще обязательный этап при решении любой задачи, если кандидат его пропускает, то в 99% случаев будет фейл.
Но вообще, конкретно эта задача на понимание концепции скользящего хеша. Причем, кандидат может прийти к этому, даже не зная, что это такое.
А с другой стороны, задача плохая. Потому что если кандидат знает алгоритм Рабина — Карпа, он решит задачу за O(n) и мы не выясним ничего, кроме того, что он знает алгоритм и может его реализовать. Хотя, даже в этом случае, человек, зная концепцию, будет вынужден вспоминать и выводить функцию формирования хеша.
А теперь главный вопрос — это серьезно задачи для архитектора и тех лида? Таких интервью у меня были десятки только за последние 10 лет моей 20-летней карьеры.
Крупные компании имеют сильноформализованный процесс интервью, в котором есть этапы который должен пройти +- любой сотрудник. Да, для позиций специалистов это выглядит как пустая трата времени, но это обеспечивает потом отсутствие для компании юридических притензий, минимизирует bias, отсеивает всяких сильно неадекватных кандидатов etc. Нужно относиться к этому как к неизбежному злу. Обычно там не то, чтобы надо сильно готовиться — критерий бинарный, а не качественный — или проходишь до нормальных интервью или отсеиваешься.
Конечно, когда так поступают небольшие компании, а не условный FAANG, это выглядит очень странно и не оправдано. Но никто же не заставляет туда идти.
Я редко сам собеседую, у меня коллеги чаще этим занимаются, так вот проблема, что на позицию "сениор разработчика" может прийти человек который на такие вопросы не может ответить. Так что хоть вам и унизительно, но подумайте, что больше половины кандидатов не отвечают на то что такое промис или зачем нужен модификатор virtual.
Таких интервью у меня были десятки только за последние 10 лет
А дальше? Вот написал ты Фибоначчи (без рекурсии, стримов и пр., простым циклом). И что?
"Ок, ты принят, вот тебе пятёра грина на руки!" Так было? :)
Если же всё техническое интервью состоит из вопросов примерно такого плана, то это конечно повод задуматься.
В резюме у него пять лет за баранкой пылесоса грузовика и восемь — легковушки. Я сажаю его в малолитражку
Некорректные аналогии подобны котёнку с дверцей.
Вы умеете водить автомобиль? Подозреваю что нет.
Это довольно незабываемый опыт, когда после нескольких лет езды на своём авто, на автомате — тебя просят проехать разок, недалеко, но на матизе (ручная коробка и другие габариты).
P.S. Особенно эта фраза повеселила — о значительно более приземленных задачах, наподобие «напишите функцию разворота массива». Вот я «прям всю жизнь» разворачиваю массивы вручную, вместо использования встроенной либы. Прям троллинг какой-то.
Вы умеете водить автомобиль? Подозреваю что нет.
Интересно, какие у вас данные были чтобы хоть что-то подозревать в этом вопросе? Плохо подозреваете, в общем.
Это довольно незабываемый опыт, когда после нескольких лет езды на своём авто, на автомате — тебя просят проехать разок, недалеко, но на матизе (ручная коробка и другие габариты).
Он довольно незабываемый, если вы ездили на механике только в рамках учёбы в автошколе. Если у вас в анамнезе есть опыт управления механикой (написания кода) хотя бы пару десятков тысяч километров (ну хоть чуть-чуть в карьере), то вы сядете и поедете. Ну заглохнете пару раз в первые 10 минут. Но это не ноухайр.
Особенно эта фраза повеселила — о значительно более приземленных задачах, наподобие «напишите функцию разворота массива».
Функция разворота массива, хоть и не очень нужна в реальной жизни, тем не менее настолько проста и примитивна, что вывести её за несколько секунд в голове может любой программист, который вообще работает с массивами. Если программист не работает с массивами, мне не очень понятно, почему он программист. Объясните?
По поводу примера с машиной — ровно по этим граблям я недавно прошёл. 100k на механике, потом 150k на автомате.
Сел на механику, и… сначала тупо заглох. Потом тронулся только раскрутив движок под 3500. С переключением передач тоже были косяки.
Уверенно я поехал минут через 5. Если бы это было собеседование, то оно, считай, провалилось в первую минуту.
Если для вас "функция разворота массива" это нечто примитивное, то у меня для вас плохие новости. Развернуть сферический массив в вакууме чертовски сложно. Нужно учесть тип массива (обычный или разреженный, а может у него магические геттеры/сеттеры есть с линейным ростом времени доступа при переборе индексов?), разобраться с хранимыми там значениями (а если там ссылки? а надо по ссылкам значения копировать или новые ссылки сделать? а язык с гарбадж коллектором или надо руками аллоки делать?), разобраться с памятью — копируем поверх или аллочим новый блок (а если поверх и это java с final массивом, то не забываем учесть exception'ы), убедиться, что операция будет thread safe при необходимости… и это, кажется, далеко не всё.
Если же для вас задача "развернуть массив" это "массив int'ов в языках типа c/pascal, тупо for'ом пробежать с конца до начала и сделать exchange значений в оригинальном массиве или выделить столько же памяти, пробежаться с начала до конца и скопировать с конца до начала", то с ЭТИМ справится студент 1го курса любого технического ВУЗ'а.
Вот только если на собеседовании миддл начнёт писать такой алгоритм, а не задавать тонны вопросов перед началом (из озвученного мной ранее списка), то надо не радоваться, а серьезнон сомневаться в квалификации этого миддла.
Ну кроме случая, когда вы сами выдаёте граничные условия вроде "неразреженный массив int'ов, без thread safe, память экономим по максимуму, оптимизация скорости не нужна" — тогда да, тогда мидл очень косо на вас посмотрит, но напишет этот алгоритм даже на бумажке на абстрактном языке за пару минут.
Уверенно я поехал минут через 5. Если бы это было собеседование, то оно, считай, провалилось в первую минуту.
Я часто ставлю Hire кандидатам, которые первые 5-15 минут тупили. Это очень часто случается и все это понимают. Более того, мы обычно даём одну задачу на разогрев, как раз чтобы кандидат вспомнил, что это вообще такое и снял стресс на "раскрутке движка" и "переключении передач".
Функция разворота массива in-place — это как раз про примитивный случай. Мы на интервью, мы не пишем звездолёт. Если кандидат задаёт правильные вопросы — это хороший знак, конечно. Если он спрашивает "простейший примитивный кейс?", получает ответ "да", и косо глянув пишет — это хороший знак. Проблема в том, что кандидаты не пишут. Не могут. Не знают, как в языке по их выбору считается длина массивов. Забывают про концевой элемент. Ошибаются в центре. Не понимают, что arr[len(arr)] в языке по их выбору не работает.
При этом брал на работу человек 15, всегда удачно. Никогда не было проблемы оценить скил человека, просто спросив — какие последние проблемы ему запомнились, как их решал и тп. Чем бы хотелось заниматься, в чем силен. Правда никогда не стояло задачи отсеять из кучи людей. Из 5 -10 людей уже находился один подходящий.
Уверенно я поехал минут через 5. Если бы это было собеседование, то оно, считай, провалилось в первую минуту.
Нет, вы бы его с блеском прошли. Вы показали способность за 5 минут разобраться с задачей, с которой не встречаетесь каждый день, и успешно решить её. Именно так и работает кодинг интервью.
Нужно учесть...
А вот этого от вас и ждут. Если кто-то сразу бросается кодить и с блеском решает задачу, не выяснив вот этого всего, он провалит интервью. А вы опять прошли.
Просто вокруг кодинг интервью много мифов. Большинство, почему-то, уверено, что это проверка способности по памяти алгоритмы писать. Что имеет отношение к реальности чуть менее, чем никакого.
Большинство, почему-то, уверено, что это проверка способности по памяти алгоритмы писать. Что имеет отношение к реальности чуть менее, чем никакого.
Оно может к вашей реальности имеет малое отношение, но у других реальность отличается. Плохое мнение об интервью зародилось не из воздуха, а из-за повсеместного подхода как раз зубрить алгоритмы и на зубок выдавать алгоритмическую сложность красно-черных деревьев. Если бы интервью работали так, как вы описываете, никто бы и не жаловался.
Вообще, кодинг задача это не просто решил/не решил — это как решил, как рассуждал, какие вопросы задавал, насколько было понятно то, что он хочет сказать, что забыл упомянуть, понял ли после напоминания о чем идет речь и так далее.
но как-то так сложилось, что задачи уровня senior — это про то, когда стандартных библиотечных структур уже не хватает и надо писать свои
а там как раз и работа с массивами, и «нестандартная» работа с примитивами, и вот это вот все про «а без выделения дополнительной памяти сможете?»
Думал о том же, пока читал исходный комментарий.
Пример с машиной некорректен потому, что в нем просят продемонстрировать вождение, то есть то, что и будет делать водитель.
В случае же с кодом, практически никто и практически никогда не пишет сортировку массива руками. Да, это несложно, но это не тот навык, который требуется в повседневной работе, если несколько лет не писал ту же быструю сортировку, то мелочи забываются, нужно перед собеседованием их из головы достать и дома повспоминать, чтобы не тупить потом за столом.
В конечном счёте это означает, что кандидату нужно поддерживать два набора навыков, отдельно для рабрты и отдельно для прохождения собеседований. А это странно.
Не существует навыка написания сортировки массива. Существует навык написания кода, оперирующего данными в массиве, который будет решать задачу. Сортировка — один из примеров. Поиск максимума — другой. Разворот — третий. Бинарный поиск в отсортированном массиве — четвертый. Продолжите список.
В случае с кодом, написание кода, оперирующего базовыми конструкциями языка по выбору кандидата (массивами, хештаблицами и т.п.) — минимальный набор для работы. Я говорю о случаях, когда ты просишь написать линейный поиск в массиве, а человек не может написать простой for-цикл.
В аналогии с водителем это больше похоже на требование не только машину вести, но еще предварительно отремонтировать ее и рассказать принцип устройства. Да, опытный водила наверное может знать это, но не этим он будет заниматься в нормальной компании. Так же как и программист не будет выдумывать алгоритмы сортировки и обхода графов, если его нанимают очередной онлайн магазин писать. Хочется оценить навыки программирования, давай профильное задание, а не матан очередной.
Полное описание алгоритма.
Желательно ещё его полную реализацию на целевом языке.
Тогда сениор-разработчик сможет списать и продемонстрировать, что он умеет печатать.
Вы серьёзно?
Как часто в Вашей практике сеньору приходится изобретать новый алгоритм обхода графа и сортировки? Именно новый, а не "взять готовый, адаптировать по месту под, скажем, особенности адресации"; а то и вовсе "вызвать библиотечный".
Я вот видел такое как-то целый один раз, за 20 лет рабочей практики. Человек изобретал оптимальную(вернее, очень отдалённо кажущуюся таковой) расстановку ограниченного набора элементом по ограниченному(столько же или больше) числу позиций, с набором дополнительных ограничений.
Что по факту имеет свои типовые методы решения с плюсами и минусами, но он явно всякую схемотехнику не изучал — и потому более изобретал.
Вот потом, спустя месяцы, пошли доп. требования добавить ограничения и тут уже работа "доработать" и "своё изобрести" сравнялась.
Чтобы написать
for i in arr:
do(i)senior-разработчику нужен справочник?
Да не надо функционально/реактивно/с вывертом/через Марс, надо хоть как-нибудь.
Люди, претендующие на сениор-позицию могут всерьез сказать, что не помнят, как объявить пустой dict в Python. А потом уйти и написать на хабре, что на интервью, видите ли, компании с ЧСВ просят писать код.
Люди, претендующие на сениор-позицию могут всерьез сказать, что не помнят, как объявить пустой dict в Python.
Вы не слышите ваших собеседников.
Именно это вам и говорят.
Что «человек, претендующий на сениор-позицию» вовсе не обязан помнить, как объявить пустой dict в Python.
Это не значит, что он никогда его не объявлял.
Это не значит, что у него плохая память.
Это не значит, что он не справится с задачами, которые перед ним поставят.
Это вообще ничего не значит. Это взятый с потолка параметр, который скорее всего вообще никак не коррелирует с профессионализмом. Особенно интересно здесь то, что эту корреляцию даже никто и не проверял никогда, не существует проверок уровня «Мы отловили 1000 сеньоров и 1000 миддлов случайным образом и задали каждому задачу об объявлении пустого словаря, в результате из сеньоров с этим справилось 999, а из миддлов только 700».
Зато в интернете ходит байка о том, как команда собралась нанимать кандидата, каждый член команды написал в список вопросы, которые нужно было задать кандидату чтобы он обязательно ответил, и в результате никто из команды сам итоговый список пройти не смог.
Подавляющее большинство интервьюеров это голуби Скиннера. Те устраивали сложные пляски вокруг кормушки, потому что несколько раз такие же пляски совпали с выдачей еды. Вы устраиваете сложные пляски вокруг кандидатов, потому что несколько раз эти пляски совпали с наймом нормальных кандидатов. Но практически нигде найм не обусловлен какими-либо реальными закономерностями. И возмущение людей связано именно с тем, что всё это видят. Даже жребий был бы справедливее, потому что падающая монетка не пытается наменуть, что ты глупее своего соперника.
Конечно, такие технологии очень помогают в найме «звёзд». Если человек отвечает на любые вопросы — то он, вероятно, гений, и его надо хватать. Но речь ведь не об этом.
Вклинюсь и повторю другими словами то, что говорили выше — такие задачи проверяют навыки ПИСАТЬ КОД. Не поговорить о написании кода, не рассказать, как он работает, не показать свой старый код (который то ли свой, то ли не свой, пес разберет), а просто сесть и написать код. Не надо помнить названия классов и методов — интервьюер подскажет. Не надо писать без ошибок. Но надо суметь написать код, ну а уже потом объяснить, что написали, как, и почему.
Конечно, задача искусственная — в основном, для простоты постановки — что такое массив или список, по идее, знает каждый.
И присоединюсь к комментирующим — огромное количество "программистов", приходящих на интервью, не может написать код. Зато может красиво порассуждать.
Вклинюсь и повторю другими словами то, что говорили выше — такие задачи проверяют навыки ПИСАТЬ КОД. Не поговорить о написании кода, не рассказать, как он работает, не показать свой старый код (который то ли свой, то ли не свой, пес разберет), а просто сесть и написать код
А я так не могу. Мой мозг протестует писать непонятно что и зачем. Большинство задач на собеседованиях не относятся к реаольности. Мне нужно искусственно придумывать оправдания всему, что в задаче.
Соответственно у отобранных от реальности задач нет для людей, который не прокачивают интервью-мысшцы — нет отскакивающих от зубов ответов. Да и с домашними заданиями беда…
В последний раз мне предложили за 30 минут 3 вопроса и по 10 минут на каждый.
Нужно запрограммировать OS Kernel Scheduler.
Я спрашиваю а какую часть — а все. У меня был шок -> адреналин и тупняк.
ЗЫ:
Я считаю что наиважнейший навык это «не писать» код.
А то вы наймете человека, который умеет писать. А потом будете его увольнять за то, что он чушь писал (даже если и красиво, с тестами и т.д.). Я не слышал, что бы увольняли архитектов, который из г--на и скотча многомиллионные продукты лепили. Наоборот им в команду кидают тех, что это все разглаживают.
А вот пусто-писателей — отпускают частенько.
огромное количество «программистов», приходящих на интервью, не может написать код. Зато может красиво порассуждать.
так в чем проблема смотреть в репозиторий на гитхабе?
Или как тут водится у многих ревьюверов нет времени смотреть?
Люди, претендующие на сениор-позицию могут всерьез сказать, что не помнят, как объявить пустой dict в Python.
Я вот претендую на позицию Senior и тоже многих таких базовых вещей не помню.
Например, я не помню, как написать заголовок цикла for в C# (или C). Помню только, что он состоит из трех частей — объявление переменной цикла, инкремент переменной и условие окончания цикла.
Логично, что объявление переменной должно идти первым, но вот остальные две части — что там первое, инкремент или условие окончания цикла — этого я никогда не помнил. Приходится постоянно в Help заглядывать.
Или вот внешнее cоединение в SQL. Если у нас left outer join, то с какой стороны у нас добавляются пустые записи, слева или справа? Хоть убей, не помню. Хотя и использую это соединение уже лет 25.
Выручает только то, что у меня есть файлик с примером запроса. И когда мне нужно написать запрос с внешним соединением, то я туда подглядываю.
Правда, пустой dict в Python могу объявить. И в C# тоже. Но вот проинициализировать несколькими элементами — уже нужно где-то посмотреть.
Так что спрашивать у меня на собеседовании такие базовые вещи просто бесполезно. Я вообще помню только то, с чем непосредственно работал последние несколько недель. Если что-то не использую, то я это быстро забываю.
Видимо, это особенности моего опыта. За последние 35 лет приходилось писать как минимум на 20 различных языках программирования. Если все это постоянно держать в голове, то можно свихнуться.
Помню собеседование несколько лет назад в одной компании в Брюсселе. Перед собеседованием дали мне пачку заданий по C# по написанию кода на бумажке. Первое задание — написать определение класса. Я с этим не справился, потому что классы я всегда создаю в Visual Studio — нажал кнопку и готово. А наизусть не помню, что там пишется. Второе задание — написать код для определения Event. С ним я тоже не справился, потому что последний раз делал это лет за пять до интервью и успел все забыть. После этого я бросил делать эти задачки.
В эту компанию меня не взяли. Наверное, потому что задания не сделал. А может, оттого, что я криво усмехнулся, когда они рассказали об архитектуре своей системы.
Да что тут говорить, я, когда в школе учился, таблицы умножения не знал. Учился я очень хорошо, и при этом часто болел. И в тот момент, когда во втором классе учили таблицу умножения, я тоже несколько недель болел и ее не выучил.
И когда мне нужно было, к примеру, узнать, сколько будет 6*9 — я умножал в уме 6 на 10 и потом отнимал 6.
Но никто никогда об этом не догадывался, потому что в математике я был очень силен — был лучшим учеником в школе за много лет. Постоянно участвовал в математических олимпиадах, в 7-м классе занял первое место на областной олимпиаде.
Но все-таки через несколько лет после окончания университета как-то таблицу умножения с грехом пополам выучил. Сейчас уже помню ее, не нужно больше числа в уме перемножать.
Но при всем при этом работу свою я делаю хорошо. А часто просто отлично.
Такие дела.
Видимо, это особенности моего опыта.
Это особенности не только вашего опыта.
Это особенности работы человеческого мозга.
Хорошим примером может служить, например, всем известная «банерная слепота».
По аналогии можно назвать это явление какой-нибудь «процедурной слепотой». Человек запоминает только сжатую суть выполняемой работы и (моторная память) набор действий.
Но поскольку никто в здравом уме не пишет стандартные вещи постоянно и осознанно — то в голове задерживается только сжатая суть и «где посмотреть если что». Не сразу. Но с возрастом — всегда.
Кроме того — чем старше, тем сильнее сжатие, и в этом смысле зумерки 20-25 лет, свободно жонглирующие в памяти стандартными приёмами, просто не понимают, как именно мыслит сениор лет сорока. У них эта радость ещё впереди, они искренне уверены, что если они сейчас могут сесть и написать код из головы, потому что «всё помнят», то и через десять лет их голова будет работать таким же образом.
Интеллигентнее всех в стране
девятиклассники, десятиклассники.
Ими только что прочитаны классики
и не забыты еще вполне.
Все измерения для них ясны:
знают, какой глубины и длины
горы страны, озера страны,
реки страны, города страны.
В справочники не приучились лезть,
любят новинки стиха и прозы
и обсуждают Любовь, Честь,
Совесть, Долг и другие вопросы.
Борис Слуцкий,
1967
Зачем вообще такое спрашивать? Какой процент кандидатов на должность Senior не напишет подобный код?
Вы удивитесь, насколько высокий. В этом и проблема. Поэтому и есть разогревочные задачи. Поэтому и настоящие задачи на самом деле простые.
Просто многие действительно не верят, что на сеньорские позиции приходят люди "на авось", и их таких много.
Я тоже не верил, пока не увидел своими глазами. Теперь считаю, что если человек отказывается писать fizzbuzz — это красный если не флаг, то флажок точно.
> Просто многие действительно не верят, что на сеньорские позиции приходят люди «на авось», и их таких много.
А разве в ходе беседы этого не понять?
Это же не 500 слов выучить. Можно же смотреть на код на гитхабе.
А разве в ходе беседы этого не понять?
Языком ворочать — не код писать.
fizzbuzz, как писали многие умные люди, делит людей быстро и практически бинарно.
Еще раз — на интервью приходят много людей, с которыми беседовать бессмысленно, потому что они не могут писать код. Вообще не могут. Если вам не надо, чтоб человек писал код — то это, наверно, нормально. Иначе — лучше все же попросить написать что-нибудь. Именно эту проблему решают такие "тупые" задачки.
приходят люди «на авось», и их таких много
Просто непонятно на что они рассчитывают. Ведь практически везде есть испытательный срок. Думают получить одну зарплату и отвадить? Не, я слышал что в корпорациях можно ловко затеряться и чуть ли не годами ни хрена не делать, но расти по карьере. Но что-то, я думаю, это байки…
Да и корпораций мало, а небольших фирм много.
Да и нельзя пройти ни туда, ни туда если ничего не знаешь. Корпорации защищают себя многоступенчатыми интервью, в фирмочке с тобой будет беседовать лид, который сразу про тебя поймёт. На галере тебя отсеют в первую неделю.
Так зачем приходить? От нефиг делать?
С зарплатой в ИТ, да еще и на сеньерской позиции можно и не расти по карьере. А изображать бурную деятельность довольно просто.
Потом, тут может быть просто эффект Даннера-Крюгера. Эти люди, возможно, всерьез считают себя крутыми специалистами (просто им раньше начальники-мудаки и коллеги-идиоты попадались). А врать про старые проекты они будут просто потому что могут и понимают, что надо выставить себя как можно лучше на интервью.
Скажем, меня с честными рассказами о себе никогда не брали на работу.
Однажды даже человек, с которым я беседовал, прямо мне сказал — типа, всё бы хорошо, но надо было рассказать стандартные планы на будущее, а не свои.
Все, с кем я обсуждал этот вопрос, говорили, что на собеседованиях и в резюме надо больше врать, чтобы получить работу, и что я дурак, раз не вру.
Все, кто собеседуют, говорили, что всегда рассматривают резюме и беседуют с кандидатом, предполагая, что он врёт.
С зарплатой в ИТ, да еще и на сеньерской позиции можно и не расти по карьере
Я говорю не о карьерном росте, а о том как вообще попасть на должность и как на ней удержаться дольше 2 недель при условии что ты не знаешь FOR и IF.
Тут же одними разговорами про концепцию и архитектуру не отделаться, надо что-то выдавать. Пусть не код, но, например, схему той же архитектуры или её описание.
Ок, ты пришёл на старый проект и пока с ним знакомишься. Ну хотя бы вопросы задавай, которые покажут что ты действительно знакомишься, уже забрал репу себе в IDE и буквы, которые видишь складываются у тебя в конкретные образы :)
Если этого не делать, то любой начальник должен поинтересоваться: "Чувак, а ты ваще чо?"
Я вот устроился и всё это делаю несмотря на удалёнку.
Правда я на стажёра пошёл… Наверно надо было сразу на синьора (возраст позволяет) :))
Для навыка написания кода тогда нужно давать кандидату полное описание алгоритма,
Ну, как вам сказать… Если это не секция алгоритмов, а именно проверка навыка кодирования, то что вам мешает задать интервьюеру вопросы? Возможно, он именно этого от вас и ждёт? Этот навык для сеньора очень важен, поскольку задания сеньорам чаще всего поступают в виде "сделай чтобы всё работало", после чего надо ещё две недели провести во встречах со стопиццот стейкхолдерами, чтобы выяснить что такое "всё", что значит "работало" и получить от смежников их API и алгоритмы работы с ним и только потом приступать к… нет, не кодингу, а проектированию. Ну, если вы и правда сеньор, у вас есть прекрасная возможность продемонстрировать именно эти навыки! (и если вы от неё отказываетесь, то, может быть, вы и не сеньор ещё вовсе?)
а не сидеть ждать, когда он в голове переизобретет какой-нибудь алгоритм сортировки, который он может даже никогда не разбирался как работает.
Так ведь это хорошая возможность разобраться, наконец, как он работает. Не? И, это, зачем заучивать-то? Достаточно разобрать принцип. Это любой студент математико-ориентированного факультета понимает где-то во втором семестре — нет смысла зазубривать матан, теоремы не зазубриваются перед экзаменом, они на экзамене и доказываются (в вашей терминологии — переизобретаются). У нас в универе была одна девочка, которая таки пыталась зазубрить. Она сдавала матан 11 (одиннадцать!) раз. На одиннадцатом, как раз поняла этот принцип и потом успешно доучилась до диплома :). Вот это подход сеньорский (не про 11 раз, а про переизобретение). А заучивание — это для школоты. Даже не джунов.
Навык написания кода это стучать по клаве и набирать то, что ты и так знаешь.
это навык для джуна. Набирать то, что ты и так знаешь. Навык сеньора — делать то, что ни ты ни кто другой ещё не знают.
Сделать сортировку это навык заучивания алгоритмов
Ай, бросьте! Если вы можете за 2 минуты придумать пару способов сортировки (напр, выбором и пузырьком) вы даже не джун. Я мог это сделать в 6-ом классе.
Да, опытный водила наверное может знать это, но не этим он будет заниматься в нормальной компании.
Простите, вы утверждаете, что опытный программист не будет заниматься программированием в нормальной компании? Гмммм.
если его нанимают очередной онлайн магазин писать
А вы не нанимайтесь очередной онлайн магазин-то писать. Ну, это же, право, крайне скучно! Да и сеньоры там — оверквалифайед. Как раз пары мидлов хватит.
Хочется оценить навыки программирования, давай профильное задание
Давать профильное задание написать онлайн-магазин? Нуууу, тут же вылезут яжсеньоры с криками — компания хочет на мне нажиться, я напишу им магазин, а они меня не возьмут, а магазин в продакшн и будут деньгу зашибать! Неее. Да и это не задание на пол-часа. На кодинг хороши задания длиной от 10 мин до получаса. Какое туда профильное можно впихнуть?
Я вообще люблю задания на кодинг на интервью. Может потому, что я кодить люблю? Поэтому, меня и берут на работу :). А яжсеньоров гордо отказывающихся — нет. Не, ну, в самом деле, покодить и порешать задачки — это ж куда веселее, чем в сотый раз рассказывать устройство хеш-таблиц или, прости господи, спринговых конфигураций каких-нибудь (xml-ных, ага).
Существует навык написания кода, оперирующего данными...
Сначала данные нужно получить — скопировать данные (как? пакетно scp, потоково ssh или еще как… и вообще, через tcp или udp? в зависимости от количества и важности данных и сети передачи выбор не очевиден… у амазона и вовсе есть грузовики с накопителями для доставки данных) или загрузить обработчик на хост с данными (там вообще какая архитектура? Компилятор есть или кросс-компиляция потребуется?) или на набор хостов с данными (как их найти? они одинаковые или разные?) и так далее. Все данные записаны в одном формате? А порядок байт одинаковый или надо проверять (а как?). И так далее.
Странно, что об этом нужно напоминать, но говорить про код, который будет работать с произвольными данными произвольного размера и расположенными в произвольных местах — абсурдно. И это не говоря про эффективность.
Как только выйти из среды — можно и не суметь. Кто-то может и не написать годный код на новом месте работы из-за среды (колегг, задач, сроков, семейных проблем и т.д.)
> Я говорю о случаях, когда ты просишь написать линейный поиск в массиве, а человек не может написать простой for-цикл.
О я на собеседованиях могу забыть синтаксис for у Python когда 4-5 дней до этого пишу на Go сутки на пролет. Так у меня было пару раз :(
И вообще что оркестр, что танцоры или певцы — всегда на новой сцене тренируются, настраиваются. Даже проф.волейболисты или футболисты «прочувствуют» стадион перед игрой.
Но программист выкован из Т-1000.
мне кажется. что не существует навыка написания кода
По-моему, именно кажется. Если программист не может описать какой-то систематический способ найти в коробке шарик с максимальным номером, то возникает большое сомнение, что он программист.
Моя мать говорила на русском. Для всех остальных языков я всегда сомневаюсь, когда, что и какой синтаксис.
Я путаю ich bin и ich habe. Is и are.
For x in y: vs For i:=0;I<10;I++
Да у меня есть утилиты: ide, Google, GitHub, исходники библиотек.
Да программисты старой школы могли с нуля написать все. Ещё 20 лет назад я знал номера и дни рождения всех родственников и так же писал в слепую.
А сегодня я должен проверять синтаксис для следующих языков:
Python, Ruby, Java, Scala, Rust, Golang, Bash;
SQL, noSQL, Esper.
Всякие фреймворки: Spark, Flink, Kafka Streams, Kinesis.
Когда решаю ежедневно задачи.
Например, когда у вас 350 элементов и вам нужно их отфильтровать по 30 признакам и быстро в Python. Тут будешь с timeit проверять и читать нюансы. Например быстрее ли list comprehension или for? Как ваши представления вам помогут, если на prod версия 3.5; 3.7 или 3.10?
Как за секунду это выгружать из своей памяти на собеседовании, когда ты в стрессе?
Пример с машиной некорректен потому, что в нем просят продемонстрировать вождение, то есть то, что и будет делать водитель.
Он не будет водить на площадке и не будет парковаться с вешками. И вообще на любом испытании можно найти разницу с тем что будет на работе.
Чтобы абсолютно точно провести испытание, надо нанять пробно на работу на год, допустим, потом на машине времени вернуться назад и принять решение — нанимать или нет.
Да не просят сложные алгоритмы придумывать, во всяком случае в нормальных конторах. Это реально что-то типа экзамена в автошколе, причём даже не в городе, а на площадке: покажи, что ты в принципе умеешь код писать (машину водить) — понимаешь, что такое алгоритм, что такое цикл, и в состоянии написать несколько строк кода на том языке, который сам же назвал своим основным языком. Типичный пример подобной задачки: написать бинарный поиск в отсортированном массиве. И довольно приличный процент синьёров-помидоров такой тест реально проваливает.
Больше похож (по стилю движения) — если он с git не работал тесно.
Типа, сделал свою ветку, без спроса смержил её с master, и задеплоил на прод.
Без ревью, по привычке.
Правда, я таких давно не видел.
Большинство задач на leetcode — немного надуманные.
Да, основы Computer Science, но когда это в последний раз было надо на практике?
Опыт другой — решать сложные задачи, в основном самостоятельно.
Или с коллективом.
Понять задачу заказчика/бизнеса, декомпозировать, продумать архитектуру, организовать мини-митинг фронта и бэка, обсудить. Продумать, тикеты написать. И, в конце концов, решить задачу. А тут задачки на низкоуровневую логику.
Это хорошо, конечно, но малопрактично.
Это моё мнение. Как и проходить тесты на IQ.
Кандидат приходит устраиваться на работу водителем. В резюме у него пять лет за баранкой пылесоса грузовика и восемь — легковушки. Я сажаю его в малолитражку и прошу в качестве демонстрации проехать полсотни метров по прямой, повернуть направо и там остановиться возле знака «P». Почти оскорбительно простое задание, не правда ли?
Мне эта аналогия не нравится, потому что простые механические навыки вождения машины несравнимы с работой программиста. Здесь ближе что-то типа учёбы. Я бы не смог быстро и без гуглежа и учебника решить задачки по физике с 1-го или 2-го курса уже лет через 5 после окончания универа, хотя на 1-м курсе успешно писал контрольную. Это же не значит, что я дичайше деградировал, просто время прошло, и мозг был загружен совсем другими задачами. Зато, если мне показать задачу из тех времён и 4-5 вариантов её решения, где только 1 верный, то я определю верный без гугла и учебников.
Так и с собеседованиями сеньоров — просто показывайте им несколько вариантов кода для одной и той же задачи, и они без гугла скажут какой лучше написан, ещё и аргументируют. Заодно и уточнят в каких условиях код работать должен, есть ли особый приоритет по памяти или по скорости. А самозванцы пальцем в небо ткнут.
В резюме у него пять лет за баранкой пылесоса грузовика и восемь — легковушки. Я сажаю его в малолитражку
При этом он сможет нормально разгрузить самосвал в точно заданное место и филигранно сдать задом на автопоезде к разгрузочному месту.
И за 13 лет ни разу не ездить на легковушке, и отвыкнуть от её управляемости, жёсткости сцепления, непривычных тормозов, другого типа ручника и т.п.
А вы его отбракуете почему-то ТОЛЬКО из-за того, что он не смог справиться с малолитражкой.
Хотя работать с ней на вашей работе не придётся от слова совсем.
Л — Логика
Я сажаю его в малолитражку и прошу в качестве демонстрации проехать полсотни метров по прямой, повернуть направо и там остановиться возле знака «P».
ОЧЕНЬ хороший кейс, я в восторге, если это это первое задание мы экономим огромное количество времени и можно спокойно сказать: «спасибо, вы мне не подходите, всего доброго»
Очень хороший пример, потому что водитель седельного тягача (автопоезда), который не сидел за рулем малолитражки месяц-два, будет рулить именно так. А при движении задом вообще катастрофа будет.
При этом он 10 лет ездит без аварий и может развернуть фуру на пятачке земли
Ну да ладно, первое задание кое-как выполнил, но когда перешли к расчету нагрузки, представляете, он забыл как брать интегралы! Что-то говорил, что 20 лет как использует специальные программы для расчета, и вообще все привык делать на настроенном рабочем месте. Хотя, если честно, такой интеграл мог бы взять любой студент второго курса. Мы с ним конечно же попрощались.
Безусловно, задавать синьору задачи а «напиши ка мне» очень увлекательно, и еще увлекательнее смотреть на то как человек настраивается и пытается войти в состояние потока под пристальным взглядом нескольких интервьюеров, но как мне видится, зачастую компетенции синьора находятся не только лишь в плоскости написания алгоритмов. А уж задачи которые по идее должен решать сеньор — обычно вообще не относятся к вопросам задаваемым на собеседовании.
И знаете, это экономит как общее время так и мои нервы.
А если у сеньра нет гит хаб проектов?
Кстати, мои проекты не супер популярны и половина была написана «just for fun», но сам код и подходы я старался проработать по максимуму, что бы не стыдно было.
Если у сеньера все таки нет ничего из open source, тогда возможно есть один два домашних проекта, которые не стыдно показать.
У меня 11 проектов, но ни один не доведён до конца.
Нет идей, просто.
Поигрался, понял, и забросил.
В результате 11 сырых pet-репозиториев.
Времени на всё не хватает, и идеи нет, на самом деле.
Не Todo'ху миллионную же писать на новом стеке.
Представьте себе, что вы директор маленькой средней школы, который ищет нового учителя.
Мои домашние проекты — это фото и diy, а программирую я на работе. Из всех людей, что я прособеседовал (в том числе успешно) гитхаб был хорошо если у 1%
Если условия задачи поменяются — перепишу.
Поэтому все репозитории приватные :)
Как узнать, что это ваш гитхаб, а не набранный откуда-то ещё? Встречал людей, которые из приватных репозиториев набирали чужие проекты. Один парень тупо форкнул другой проект, переименовал все сущности, похачил историю в гите и выдавал за свой. Правда, особо внимательные люди нашли там куски которые переименовать он забыл, но это другая история.
Будут вопросы — с радостью пообщаемся, расскажу почему и как выбрал то или иное решение.
Т/е за каждую строчку своего кода я готов ответить. Это самый дейтвенный способ проверить, мой это код или нет :)
Ну вы-то допустим да. А рандомный челвоек спокойно скажет "да это было полгода назад, я уже не помню че там". Особенно если не давать ему распечатку с его же кодом, а просить на память вспомнить. И что с ним прекрасным тогда делать?
Вы никогда не видели, как студенты сдают списанные задания? Видел как раздолбаи, которые ни строчки кода написать не могли, забалтывали преподавателей. Почитать чужой хороший код и как-то что-то внятное о нем сказать на порядки легче, чем этот самый код написать самому.
Расскажите мне менее затратный и более эффективный способ найма синьоров, например, в гугл, когда на вакансию подается несколько сотен человек. Кстати, помимо кодинг интервью там обязательно будет пара раундов системного дизайна, где как раз синьорность и проверяют.
Да что они могут понимать в этом вашем гугле, вон по гитхабу можно без интервью нанимать людей на 500к в год!
Так что ваш сарказм неуместен.
Подобный хайр хорош, когда вы нанимаете одного из нескольких лучших разработчиков в компании, в надежде построить хорошую инженерную культуру в компании, и у вас в компании прямо сейчас мало кто может хорошо интервьюировать звёзд.
Он плох, когда у вас тонны хороших инженеров, сложившаяся культура и процессы и вы этих сениоров с гитхабами нанимаете по триста в год.
Ваш стартап не кажется гуглом. Мой комментарий был про гугл-скейл компании.
В гугл попасть хотят далеко не все из-за 5+ раундов собеседований. Забугром десятки историй как рекрутеры FAANG'ов раз за разом пингают кандидатов на предмет собеседования, а те в свою очередь спрашивают нужно ли до сих пор стоять у доски и когда получают утвердительный ответ говорят до свидания.
Или еще может так получится — Google Tried to Patent My Work After a Job Interview
Через знакомых, которые сами хорошие программисты.
Получается комбо-эффект. С одной стороны собеседование проходит в легком режиме, с другой стороны пред-подготовка позволяет показать себя с лучшей стороны.
— использование тонких моментов языка/платформы, ибо: их дохрена и больше, я сам могу ими завалить собеседующего, но в работе тщательно их избегаю;
(за годы практики выработались способы обходить эти самые острые углы, потому что чаще проблем существенно больше, чем пользы)
— 100500 вопросов по «азам» языка/платформы, от синтаксиса до примитивов синхронизации потоков и работы GC, ибо многое проще найти, чем вспомнить, некоторое слишком редко используется;
(я вообще предпочитаю lock-free архитектуру и пишу без утечек памяти)
— «олимпиадные» задачки, ибо: в реальной жизни не встречаются, скилл разработки для реального бизнеса не прокачивают;
(там, где я работаю, не пригодится навык найти единственный непарный элемент в целочисленном массиве)
— «стандартные» алгоритмы/структуры, ибо: в реальной жизни мне крайне редко приходится опускаться до этих низин, вполне спасают библиотеки и поиск;
(например, мне только раз после института пришлось писать дерево, это было давно и я не помню алгоритмы обхода вглубь и в ширину, помню, что бывают разные виды деревьев, где-за углом притаились графы… т.е. я знаю, что гуглить, если потребуется, но с вероятностью 99% это всё равно не пригодится)
— тестовые задачки на «сферического коня», ибо: надо узнать, первое — что именно имеет ввиду автор, второе — что же он хочет получить на выходе, третье — какой стиль программирования он предпочитает, четвёртое — какие он подразумевает ограничения;
(тут вообще сложный момент, т.к. чаще всего собеседующие хотят увидеть конкретный код, который сами придумали, а я привык решать задачи в контексте, когда все эти параметры либо известны, либо требуют уточнения, и без этого контекста у меня сотня-другая вариантов решения может найтись, какой выдать на собеседовании?)
Иначе говоря, кодинг на собеседовании лишает меня того, чем я должен заниматься в реальной работе — много узнавать про задачу, думать про архитектуру, анализировать типовые решения, работать с командой — всё это время и ресурсы, которых нет на собеседовании.
Да и вообще, сеньоры бывают разные. Точнее говоря, под это название подписывают и ходячие энциклопедии, и тимлидов, и архитекторов, и специалистов широкого профиля, и узкоспециализированных профи, и просто мастеров, умудрённых годами опыта.
(из этого списка двум категориям уместен кодинг на собеседовании).
PS
лично я собеседовался несколько десятков раз, но интервьюировал более сотни кандидатов. И я не требую писать код на собеседовании. Мне достаточно того, что человек расскажет об этом вслух. Я и так пойму, в чём он разбирается, что помнит, что забыл.
Чуть иначе для молодых специалистов — я могу предложить написать что-нибудь совсем простое в той области, какую человек сам заявил, как изученную. Например, говорит, «знаю Linq» — ок, вот пример (заготовка кода) с парой коллекций, напиши простую выборку (одна строка кода, базовый синтаксис + один важный момент, про который стоит помнить). Знает JS — пусть напишет counter с приватным значением. И не даже не важно, получится ли написать это всё на бумажке/в блокноте/в чате, мне важно, понимает ли он задачу и знает ли, чем её решать. Остальное можно нагуглить и запомнить при частом употреблении.
Но к моему удивлению, почему-то «технари» остаются «технарями» и так мало при собеседовании обсужаются детали процесса разработки в компании. По мне так лучше поговрить к какому процессу привык разработчик, какой вид «стори на доске» считает нормальным и т.п. Ведь в большинстве случаев «уникальную» проблему можно решить выбрав подходящее типовое решение. И большая часть времени уходит как раз таки на определение проблемы и выбор, чем на программирование. Умение работать с проблемами внутри и есть сеньерити левел.
Столбиком делить не умею, только уголком. Такое прокатит?
Почему-то в подобных статьях всегда забывают, что собеседования могут преследовать совершенно разные цели на разных этапах и в разных компаниях. И иногда описываемый тип интервью — просто необходимость, с которой надо смириться (или не идти в такую компанию), а иногда — блажь интвервьюера (но тогда туда точно лучше не идти).
На мой вкус идеальное интервью: скрининг (с разговором про опыт) + тестовое домашнее задание (оплачиваемое, объемом на 4-8 часов, можно заменить богатым гитхабом) + блок обсуждения задания. Это и кандидату удобно и сразу видно, годится человек или нет. Но так очень мало какая компания может себе позволить сделать. По крайней мере у меня такое собеседование только одно было пока.
Получается Жуниор есть сениор, без настроеной среды.
Студентам pазных куpсов задают один вопpос «Сколько будет 2 умножить на 2?»
Студенты 1 куpса сходу отвечают: — Четыpе!
Студенты 2 куpса сначала pоются в шпаpгалках, потом отвечают: — Четыpе!
Студенты 3 куpса достают калькулятоp и посчитав тожедают пpавильный ответ.
Студенты 4 куpса пpосят вpемя, чтобы сходить в компьютеpный класс и составить для pасчета пpогpамму.
Спpашивают студента 5 куpса.
Он возмущенно: — Я что все константы наизусть помнить должен?!!!
– Никак не могу найти себе помощника, – пожаловался однажды Эдисон Эйнштейну. – Каждый день заходят молодые люди, но ни один не подходит.
– А как вы определяете их пригодность? – поинтересовался Эйнштейн.
Эдисон показал ему листок с вопросами.
– Кто на них ответит, тот и станет моим помощником.
«Сколько миль от Нью-Йорка до Чикаго?» – прочел Эйнштейн и ответил: «Нужно заглянуть в железнодорожный справочник». «Из чего делают нержавеющую сталь?» – «Об этом можно узнать в справочнике по металловедению...».
Пробежав глазами остальные вопросы, Эйнштейн сказал:
– Не дожидаясь отказа, свою кандидатуру снимаю сам.
(ц) "Физики продолжают шутить"
Только недавно была эпопея с поиском новой работы — чего только не случалось — забывал, что делает GROUP BY, не мог написать простой SQL-запрос с одним JOIN и WHERE, с кодом тоже были тупняки, но спасал TDD подход — написал вначале тест, а потом методом подбора (на третье собеседование в день абстрактное мышление будто ушло в оффлайн) писал алгоритм.
Новую работу так и так нашел. А на тех, кто не делает скидку на то, что собеседование для программиста это не рядовая рабочая ситуация — да и пофиг на них.
На мой взгляд, переживать надо только в тех случаях, когда нет внутреннего желания развиваться в своей области — читать книги, изучать что-то новое, писать в личное время код, что-то выкладывать на github.
Ну а знать ответы на них, к сожалению, абсолютно необходимо.
в последний раз сталкивались с некоторыми эзотерическими аспектами разработки программного обеспечения, такими как динамическое программирование, красно-чёрные деревья или даже рекурсия.
Рекурсия?! Серьезно? Сеньер не может в рекурсию? Про реализацию всяких деревьев согласен, но про динамическое программирование — нет.
Кто в команде, если не сеньер должен уметь в алгоритмы? Оно не каждый день каждому кодеру нужно, но иногда может понадобиться и без знания ДП вы не поймете даже, что его тут можно использовать, сократив код в 5 раз и ускорив программу в 20 раз.
В реальном мире рекурсии обычно крайне нежелательны, думаю не нужно объяснять почему ))
Думаю, вот это "и почему же?" было бы хорошей темой беседы для собеседования. С примера из практики(обезличенными) и вовсе отличной.
Связываются по поводу позиции. Суть позиции не вполне понятна, хочу ли я туда — не понятно, договоримся ли по деньгам — не понятно. И говорят: Для начала нужно сделать задачу по программированию, займёт не больше 4 часов (чтоооо?!). Сделаете ветку тестового задания на гитхабе, внесёте необходимые изменения, предоставите документацию. Первое желание было послать их, но задание показалось любопытным. В итоге сделал ровно то и настолько, насколько мне было интересно. Документацию делать не стал. В изначальном проекте были юнит тесты, довёл до ума один, чтобы протестировать свои изменения. Так часа 4 и заняло.
Резюме проверяющего:
1. Задание не выполнено (неправда, но ему было так же лень вникать в мой код, как мне писать документацию).
2. Документация не предоставлена (правда)
3. Юнит тесты не предоставлены (один предоставлен, но по заданию на 4 часа и того не требовалось).
Итог: нам не подходите. Ну как бы не очень и хотелось, но подход странный.
Когда работал в одной маленькой фирме, там офшорных разработчиков так пробовали: давали им задачу реальную, но несрочную. Если справлялись, им платили и продолжали, нет так нет. Один раз заплатили, но продолжать не стали: результат был получен, но мороки было невесть сколько. Но там честно, сделано — платили.
Ага, потом приходишь работать в %уважаемая_контора%, а там разработчики бинарный поиск реализовать не могут.
И проблема даже не в том, что они не могут написать код, они вообще не подозревают о том, что теоретически возможны алгоритмы, работающие быстрее линейного поиска.
А по резюме — серьезные ребята с 10+ летним опытом работе, куча реализованных проектов и опыт руководства.
Любая задача среднего уровня сложности с leetcode успешно бы отсеяла данных персонажей.
Остальные 50% это лайв кодинг. И я скажу там человека очень хорошо видно.
Я никогда не требую полного знания какого либо апи, то есть файловое, бд, cериализация. Апи я предлагаю додумать, если кандидат не помнит точного.
Я обычно предлагаю какое-то простое базовое задание, потом вокруг него можно задать много вопросов: как тестировать, что будет узким местом и почему, как ускорить, что может упасть, дизайн апи, стоит ли делать async/await… потом могу попросить реализовать одну из предложенных кандидатом улучшений.
Все это делается в дружественной атмосфере, чтобы свести волнение кандидата к минимуму.
В целом формат интервью, список тем, вопросов, и задания на написание кода сильно зависят от требований к позиции на которую человек рассматривается, цели интервью и времени которое выделено на интервью.
я бы на месте нанимателя просто нанял бы её на испытальный срок
С опытными программистами я поступал бы так же.
Всех 500 кандидатов?
В сущности, если искать человека на позицию из числа проверенных рекомендательных источников, то во-первых, откуда там взяться сотням кандидатов.
Вы, как заправский сеньор, решаете не ту задачу, которую вам поставили :) Если вы можете просто нанять проверенного друга, проблема вообще не стоит.
Идёте в Библиотеку, берёте там книжку "Законы Паркинсона" Открываете там главу «ОКОНЧАТЕЛЬНЫЙ СПИСОК, или Принципы отбора кадров» И читаете там подробнейший разбор того, что именно вы делаете не так. :)
Приходится признать, что система неверна
изначально. Незачем привлекать такую массу народу. Но никто об этом не
знает, и объявления составлены так, что они неизбежно приманят тысячи.
Если же подумать, увидишь, что идеальное объявление привлечет одного человека, и того именно, кто нужен.
P.S. Про найм по знакомству там тоже есть в конце главы. :)
Причём пол главы объяснению менеджерам почему настоящая задача состоит именно в этом, а не в отсматривании на очном собеседовании 500 человек.
Задачу домой — тоже ок, но это немного другой вид спорта и он тестирует другой набор навыков. Что клёво в лайв-кодинге — это то что можно вместе подумать над задачей и сразу посмотреть как кандидат мыслит и как он общается. А это тоже важные навыки для программистов.
Ваш пример про учительницу не совсем аналогичный, так как кодинг-задачи на интервью гораздо проще чем боевое программирование. А попросить учительницу объяснить умножение столбиком, чтобы посмотреть как она объясняет — это по-моему ок.
Ещё одно важное замечание про кодинг-интервью: люди, которые участвовали в соревнованиях по программированию, умеют лайв-кодинг гораздо лучше обычных программистов и стоит делать на это поправку. Ну и понятно что не кодингом единым ограничивается работа программиста, особенно если он сеньор, так что не стоит всё время собеседования на это тратить.
А большинство случаев надомного кодинга, — это когда девочка HR всё равно не способная понять что там написано, вставляет в собеседование такой этап, потому что по имеющимся у неё знаниям просто не способна отличить программиста от бобра строящего плотину в лесу. Ну и нафига тогда в этой процедуре такая девочка? Часто вообще аутсорсер, кстати.
3 дня? Звучит как задача на 2-3 часа уровня школьной олимпиады для 9 класса...
А вообще у меня к вам предложение. Если вы пишите на C# для Unity и сможете сделать задачку не за 3 часа, а например за день, я вас лично рекомендую в контору, которая платит примерно в полтора раза от рынка.
Там правила очень простые — стандартный кроссворд, то есть слова могут пересекаться, но не могут касаться. Словаря готового предоставить не могу, придётся поискать, но там около 50 тысяч слов, Поле 100x100. Правила очень простые — вы стартуете с центра поля с одного слова длинной 5 букв. В каждый ход вы можете только добавить две буквы (не обязательно в одно слово) так чтобы целостность кроссворда сохранилась. Если очередной ход окажется невозможен — вы можете откатить сколько хотите последних ходов и походить по другому. В зачёт идёт время которое у вас уйдёт на заполнение всего поля. Приложение однопоточное.
Скажем что кроссворд целостный если выполняются правила для кроссвордов и все слова в нем из исходного набора слов. Значит ли фраза выше то, что после добавление двух букв кроссворд должен остаться целостным?
>В зачёт идёт время которое у вас уйдёт на заполнение всего поля
То есть в каждой клетке поля вписана какая-то буква и кроссворд целостный? Или в поле есть незаполненные клетки, но добавить уже ничего нельзя не нарушая целостности?
Да, после добавления двух букв кроссворд опять должен быть опять целостным.
Одно важное, но самоочевидное добавление — два раза одно слово использовать нельзя.
>Или в поле есть незаполненные клетки, но добавить уже ничего нельзя не нарушая целостности?
Именно так. Но то что добавить нельзя ещё ничего не знгачит, потому что можно откатиться на сколько-то ходов назад и перестроить кроссворд.
Отсюда вытекает правило останова, которое я уточнить забыл — не надо пытаться клетки имеющие соседей так чтобы получился квадратик 2 на 2 заполненный буквами. Тоесть коротко говоря «Без касаний слов». Если это не уточникть, то у вас не будет понятия клеток, в которые нельзя добавить, и соответственно, не будет критерия для оставновки «во все клетки, в которые можно, уже добавленно, остались только те, в которые добавлять нельзя».
Жизненно, конечно бывало. Нормальную работу как раз находил там, где давали реальное задание и его можно было выполнить спокойно дома за день или, если большое, за неделю, если тестовое оплачивалось.
На самом деле кодинг — это главное что нужно проверять на собеседованиях. 25 пройденных курсов не делают тебя сеньором, только практика и практика. Я никогда не готовился к кодинг-интервью, но всегда показываю блестящие результаты, потому что кодинг — это то, чем я занимаюсь последние 15 лет. Кто плохо проходит кодинг — у того просто слишком мало рабочей практики, а значит какие у него основания называться сеньором, или даже хотя бы мидлом? Да, не все кто хорошо делают задания на кодинг — сеньоры, но все синьоры хорошо делают задания на кодинг, это же элементарно. Сказать, что сеньоры ненавидят кодинг — все равно, что сказать, что фигуристы ненавидят коньки, пчёлы ненавидят мёд, а менеджеры ненавидят разговаривать)
Возможно, автор перепутал сеньора с тим-лидом. Последний да, часто раздает задачи и командует разрабами (не всегда пишет код), но сеньор — это всё-таки именно программист, просто очень скилловый, и решить простенькую задачку с собеса (оценив асимптотику решения) должен уметь.
Это примерно, как человека, водившего 20 лет фуры с автоматом, гидроусилителем и парктоником, умным круиз контролем (и устраивающего водить такие фуры), предлагают сесть на разбитую леговушку-копейку на механике с плохо работающими передачами и выполнить учебные задачи на полигоне вроде змейки, старта в горку и парковки в гараж задом. Очевидно, такой тест почти ничего не скажет о профессонализме водителя фуры.
Аналогии — это дело такое. Написать псевдокод для той-же сортировки пузырьком — это скорее объяснить на пальцах как переключаются передачи на копейке. Написать псевдокод балансировки красно-чёрного дерева — объяснить на пальцах, но в деталях, как работает впрыск топлива на той-же копейке. Вменяемый интервьювер не будет спрашивать второе.
Вменяемый интервьювер не будет спрашивать второе.
А первое будет? Будете ли вы водителя фуры с 20 летним опытом просить «объяснить на пальцах как переключаются передачи на копейке», что он по-вашему вам ответит и что это вам даст?
Я легко могу представить отличного программиста, который забыл про сортировку пузырьком, которую он изучал 20-25 лет назад в университете.
Еще раз, я, в принципе, не против каких-то простых задач на кодирование для начального отбора, но чаще дают лишь очень-очень приблизительное понимание о реальных возможностях программиста, а что-то сложное алгоритмическое — скорее покажет навык тех, кто именно изучал алгоритмы.
Зато кодингом можно проверить, что потенциальный "синьор помидор" не тянет даже на джуна
Есть люди, которые болтают запросто, а вот писать не умеют. А на работе обычно надо больше работать, а не говорить, если мы не чисто тимлида-манагера нанимаем офк. Я бы наверное таких вопросов задавать не стал, но можно понять людей, которые это делают.
Конечно, этими вопросам всё не ограничивается, но вектор определить не сложно, если не относится к собеседованию слишком формально.
Что делать людям, у которых хуже с навыками собеседования и они не могут одним-двумя вопросами это сделать? Хороший программист/лид/архитектор не обязательно хороший интервьювер.
Вот серьёзно — ни одна методика не универсальна. Хороша только та, которая у вас работает.
Типовая и массовая ошибка — полагаться на «проверенные» шаблоны. Тут ведь как в программировании. Если задача типовая, то и методы решения типовые. Чем сложнее задача, тем больше шансов, то ни один типовой подход не подойдёт.
Нужен 10-й кодер в правом ряду — наверняка можно составить опросник/задачник, который будет работать максимально эффективно. Если у вас компания большая и сеньоры идут чередой — наверно тоже можно выработать стандартный подход. В остальных случаях все советы стоит рассматривать как «вон оно чего бывает...», и проверять, а подходит ли решение в вашем случае.
Дело не в этом. А в отношении "вопрос говно потому что Я и без него могу справиться". Ну вы наверное можете, но люди разные.
А на ответ: кто будет интервьювить интервьювера? Не говоря о том, что искать такого человека может быть тупо некода. В таких случаях обычно берут самого скиллового/софтскиллового чувака и просят пособесить. И это нормально.
Конечно отменяет, если мы говорим о решении проблемы для реальных компаний, а не для сферических в вакууме.
Нет, вы выдаете утверждение "если у них нет хлеба — пусть едят пироженые". Ну нет часто в организации "профессионального собеседующего" на каждого кандидата, особенно в компаниях на пару десятков человек.
Я в своей практике для не сеньоров использовал пару простых (на 2-3 минуты) заготовленных задачек на те технологии, которые были очень важны на текущем проекте. Если по ходу собеседования возникали сомнения — на ходу придумывал задачку на ту тему, которую кандидат указал как «хорошо знаю».
А вот для сеньоров у меня обычно есть задачка на поговорить, с кучей сложностей и возможных путей реализации. Мне интересно услышать, как человек подойдёт к обсуждению, что спросит, о чём подумает, какие варианты выберет, чем аргументирует. Одну такую задачку можно полчасика пообсуждать — этого с головой хватит. Если человек хороший специалист, то обсуждение заканчивается только из-за исчерпания лимита времени.
Вопрос, стоит ли тратить полчаса времени если простым вопросом в начале можно поставить точку?
В квалификации? Человека который идет на сениор позицию и не может написать физзбазз.
Не может написать в конкретный момент на конкретном собеседовании. Возможно, с конкретным собеседующим.
Проблема может быть далеко не только в собеседуемом ведь.
А каким образом сениор разработчик может не написать с конкретным собеседующим? Разве что как-то так?
Адекватный человек пожмет плечами и за 1 минуту напишет решение, а не будет 10 минут брызжать слюной что он весь такой алмазный, и наносек его времени уже стоит столько что с ним за век не расплатятся.
Интересно, что изначальное "сеньор не может написать" теперь превратилось в "10 минут брызжет слюной". Того и гляди, серой пованивать начнёт.
А почему может не мочь — читайте про стресс и его влияние на когнитивные способности.
Если у него стресс на дружелюбном собесе с чашечкой кофе — какой же у него будет стресс если его код на продакшн с каким-нибудь критическим багом вдруг попадет? Лучше хрустальных снежинок и не нанимать, да. Хардскилл это не всё что нужно от человека.
Теперь, внезапно, просто собеседование без деталей вдруг стало "дружелюбный собес с чашечкой кофе".
Стрессом оно от этого быть не перестало.
Ну значит такой стрессовый человек найдет более подходящую и менее нервную работу :shrug:
Можно за него только порадоваться
Теперь, внезапно, просто собеседование без деталей вдруг стало "дружелюбный собес с чашечкой кофе".
99% собесов что я проходил — это дружелюбный диалог, и в большей части случаев предложат чай/кофе по желанию. А проходил я их в районе полусотни за все время, мб чуть больше.
Только вот об уровне его квалификации(Ваш изначальный посыл) это ничего не говорит.
Q.E.D.
Ну неумение контролировать минимальный стресс в подобной ситуации как раз признак хреновенькой квалификации. Ведь софтскиллы мы тоже оцениваем, да.
Ну неумение контролировать минимальный стресс ...
… не является признаком квалификации вообще. Кроме квалификации проходить собеседования.
И восприимчивость нервной системы к внешним стрессфакторам это не софт-скилл, это врождённое; и степень стресса от собеседования нетренируемое без постоянных повторов стресса(с шансами только им перегрузиться). То есть — постоянными походами по собеседованиям.
Хотя согласен, если высокая стрессоустойчивость на собеседовании это обязательное требование для работы где-то — то такое собеседование лучше покинуть. Для здоровья.
Не высокая, а хоть какая-то. Я выше писал, если человек не может справитсья со стрессом в такой ситуации, как он поведет себя в дейтсвительно критической, когда прод упал и компания несет миллионы убытков? Спрячется в ванной и скажет "Не трогайте, я в домике"?
Если я не могу оценить человека на собеседовании, значит лучше я совершу ошибку первого рода, чем второго.
Я стараюсь сглаживать углы и уменьшать нервнозность кандидатов, чтобы они отвечали в наиболее близкой к обычной рабочей обстановке. Конечно, желательно смотреть и уровень ответственности, иначе будет работа спустя рукава, а не только брошенный упавший прод, но это тяжеловато увидеть.
Ещё раз повторю: такие задачки почти ничего не говорят именно про сеньорские скилы.
Они говорят только об умении решать такие задачки. С таким же успехом можно начинать с хелловордов и прочих задачек из учебника по языку с примерной такой же мотивацией «раз не умеет, то лох педальный».
И обратно — если не решил задачку, то почему? Для кого то сама по себе «задачка на 5 минут» стресс (лично знал одного такого, крайне полезного и эффективного сеньора, но на разгон ему нужно хотя бы полчаса), кто-то на бумажке код не писал лет 15, да и вообще плохо помнит, как ручку в руках держать, а кто-то увидит условие так, что с вашей точки зрения решит её неправильно.
А потому, лично для меня, такие задачки на собеседовании для сеньора — маркер квалификации интервьюера.
Задачка показывает то что это не вайтишник который прошел трехмесячные курсы по жаваскрипту, наврал в резюме и пошел на сениор девелопер вакансию тратить ваше время, вот и все.
А потому, лично для меня, такие задачки на собеседовании для сеньора — маркер квалификации интервьюера.
У меня буквально пару недель назад был кандидат, который отработал год на позиции какого-то куа и хотел 250к и позицию главы отдела тестирования. Амбиции людей очень часто не соответствуют их умениям.
… не вайтишник который прошел трехмесячные курсы по жаваскрипту,...
Я верю, что вы можете придумать тысячу задачек которые покажут, что это не самозванец. Но можете ли вы придумать задачку, которая покажет, что это именно сеньор?
Нет, а надо? Мне нужна именно задача на самозванца же :shrug:
Видимо это сениоры со слабыми софтскиллами, которые не могут поставить себя на место собеседующего и оценить важность задачки :shrug:
Ну, могу только пожелать удачи. Возможно если/когда вы наймете сениора который вас заболтает на собесе а на работе потом будет прыгать "developers developers" без какой-либо реальной работы у вас позиция изменится.
Я везунчик или мой метод работает успешно?
Так есть множество факторов.
Во-первых возможно вы гениальный собеседующий, а у других такого нет, но нанимать как-то надо.
Во-вторых найм 20 лет назад и сейчс отличается. Да даже 5 лет назад я не помню такого количества вайтишников "я прошел трехмесячные курсы девопса дайте мне 290к в месяц" (реальная история из уже позапрошлого года)
В-третьих… продолжать можно долго, anecdotal evidence работает в обе стороны. Поэтому прежде чем огульно подобные техники называть "недостойными" подумайте, что у кого-то может быть другой опыт. То что у вас такой потизвный опыт в свою очередь я тоже учту, но как я сказал выше, из ошибок двух родов лучше отвергнуть верного кандидата, чем нанять неподходящего, так вот у нас ТК устроен что фиг потом уволишь. Испыталка конечно есть, но не панацея. Некоторые вещи на собеседовании во-первых лучше видно, а во-вторых нет сожаления "ну мы уже столько потратились на обучение, может он ещё только вкатывается и скоро начнет работать эффективно".
А как у вас выстроен процесс первичного отбора, что к вам на собеседование приходят такие «сеньоры»?
Ну вот в резюме просто супер, а на практике оказывается что резюме тоже оформлено по методичке "как за 3 наносек попасть в айти". Зачем врут в резюме — непонятно. HR тоже не может на предварительном созвоне как-то нормально оценить скиллы, тем более, что все такие занятые и нервные что на "я не готовился" ей получится списать что угодно.
Зачем врут в резюме — непонятно.
Анекдот про «Прокатило» помните? Вот это оно самое.
Про место работы может и не врут, но про опыт — постоянно. Ну, написано в резюме: главный зам начальника отдела разработки. А по факту — в той конторе просто вместо повышения зарплаты выдают все более красиво звучащие звания. Написано, что 5 лет работал с технологией X. По факту — соседний отдел один раз что-то из этой технологии прикрутил куда-то. Эта часть даже ни разу в прод не запускалась.
Дополняя сказанное выше: как вы проверяете опыт по трудовой? По моему опыту её обычно приносят уже после офера уже только при оформлении, вместе с дипломом и пр. На этом моменте кандидат получил "добро", другие получили "извините, у нас вакансия закрылась", и даже если в этот момент сверить трудовую с резюме и выяснить подлог — то это потеря кучи других кандидатов, времени и т.п. Да, стоит того чтобы не спросить задачку на 1 минуту времени ровно.
Со стороны интервьювера: сеньор — это просто «опытный разработчик», поэтому каждый отталкивается в его определении от личного жизненного и профессионального опыта. Я не заморачиваюсь и спрашиваю разработчиков не то, что вроде как должен знать абстрактный сеньор Software Engineer, а то, что нужно нам на проекте (регулярные практики и вызовы), а мы по идее стараемся держаться всего самого лучшего или хотя бы иметь в планах. Это примерно соотносится с продолжительностью качественного роста в индустрии. Лично для меня лив-кодинг вообще никак не покажет будущий КПД кандидата. Неплохой фильтр на адекватность у нас ещё до интервью в виде небольшого ненагугливаемого опросника, а как мне понять будущий КПД по тому, как пишет кандидат на «доске»? Возможно, это лучше работает для других компаний.
«Назовите самый challenging проект». Ну извольте: работал в токсичной компании в наспех собранной команде (по рассказам, большую ее часть набирал директор, не имеющий технического образования, руководствовался только резюме, на собеседованиях знаний не проверял, ибо не имел компетенций). На момент моего присоединения к команде та успела продолбать все сроки. В итоге, с одной стороны, ты ни в чем не виноват, с другой — с тебя требуют результат уже завтра (с явным видом, что бы опоздал еще вчера, до того, как прислал им резюме). В процессе выясняется, что с командой полностью отсутствовала обратная связь, и о том, что в ней происходит, начальство узнавало исключительно из редких отчетов (никаких демонстраций не было отродясь). При ближайшем рассмотрении оказалось, что первая половина этих отчетов — выдавание желаемого за действительное, а вторая половина — откровенная ложь. Часть работ, про которые начальство было уверено, что у нас все сделано от и до, даже не была начата (при том, что успешное окончание было отрапортовано). Не шучу. В команде были полные разброд и шатание, инженеры не умели базовых вещей: чем сеньористее было звание, тем больше были пробелы, и тем яростнее такие инженеры воспринимали критику, предпочитая всячески вокруг себя мутить job security. На удачу в команде оказались два не-сеньорных полу-студента, которые быстро схватили тему и смогли заменить всех оставшихся (со стороны замененных job security вырос с простого бойкота до откровенных подковерных жалоб начальству). Историю о том, как начальство пожадничало на новый сервер, а старый закрыло в маленькой комнате без вентиляции, где в летнюю жару благополучно был потерян весь data storage, оставлю за кадром. Несмотря на все это одной третью команды удалось дать результат на 3 месяца раньше финального дедлайна (после которого обещалось всех разогнать). В итоге проект был закрыт, а наиболее адекватная часть команды была уволена, т.к. лживые отчеты директору нравились больше, чем героическая правда.
Интервьюер: вы нам не подходите. Ваш опыт не соответствует культуре нашей команды.
Что же предлагается:
я бы предложил вам дать очень короткое задание (которое занимает не более часа или двух и выполняется им дома). Большинство должны быть в состоянии найти небольшое количество времени для выполнения такого задания, особенно по той причине, что оно исключает работу по подготовке, необходимую для собеседования с программированием, и может быть разбито на временные отрезки, которые лучше вписываются в их напряженный график.
Дополнительное преимущество — тот факт, что соискатель может посвятить этому упражнению как можно меньше или как можно больше времени, позволяет вам понять, что ими движет. Внимательны ли они к комментариям? Подумали ли они о тестировании? Структурировали свой код разумно и понятно? Насколько они сосредоточены на качестве работы? Другими словами, вы будете знать, могут ли кандидаты программировать и могут ли они программировать хорошо и в более реалистичных обстоятельствах.
Ой! Ненавижу такие задания. Вместо одного часа лимитированного по времени задания тебе теперь приходится делать уже неограниченную сверху работу, вылизывать каждую строчку в меру своего перфекционизма и угадывать, на что же именно будут обращать внимание. IMHO лучше время от времени поддерживать свои базовые навыки в надлежайшем состоянии, чтобы при случае не испугаться какого-нибудь динамического программирования… И времени уходит меньше, и на порядок полезнее.
Добавьте к этому тот факт, что сеньоры стеснены во времени (у них есть неотложные задачи и часто значительные личные обязанности)
Собственно вопрос, кому нужна новая работа?
Если сеньора устраивает текущая, его устраивает его занятость, то зачем он идет на интервью?
Или зачем его тащить туда силой, а потом писать статьи, как сеньоры не любят интервью?
Если сеньор уже уволился и неспешно ищет новую работу, то если ему интересна компания, у него найдется время на тест. Не в каждой компании тесты идут несколько дней, а задание на пару часов или вечер — IMHO норм отбора в компанию, в которой хорошие условия.
Вообще странная позиция сеньоров, устраиваться на работу и не проходить элементарные тесты связанные с работой.
Это может говорить о большом ЧСВ, тогда сразу на месте компании я бы подумал о надобности такого работника.
Другой момент, что что то с образованием и подготовленной кадров у нас ж… в отрасли
Вообще профи обычно видно по сравнению речи и как он рассуждает на технические темы, тут и без кодирования можно.
Можно элементарно задать вопросы из текущей работы, которые не имеют однозначного хорошего решения и посмотреть на то как человек будет отвечать.
На одном собеседовании меня начали заваливать вопросами уровня «чем отличается дедукция от индукции» и «расшифруйте все буквы SOLID». Словно расшифровка букв и знание терминов как-то помогают в выборе специалиста. Мне так-то не сложно расшифровать и индукцию с дедукцией я в отличие от Холмса не путаю, но это же просто трата времени и появление подобного сразу звоночек о том, что люди которые тебя интервьюируют не очень понимают чего они вообще хотят.
Потенциальные работодатели как-то упускают, что не всегда они единственный вариант и не всегда человек является безработным.
На дворе бывает порой не только 2021 год, но и 2001, 2008, так что не зарекайтесь. И, кстати, в связи с таким томатным пюре на фонде (https://finviz.com/map.ashx?t=sec) 3ю неделю подряд как бы в этом ряду еще и 2022 не появился
«Они что, просто хотят, чтобы я был кодирующей обезьянкой?
Это автор статьи считает стажеров джунов и мидлов кодирующими обезьянками или он думает что сеньеры их таковыми считают?
Как-то неприятно было прочитать это.
Что бы я не стал делать — придираться к незнанию API, типа перечень встроенных методов на массивах и т.д. А вот в целом понимание платформы, с которой работаешь нужно довольно хорошее и я слабо себе представляю сеньоров абстрагированных от какой-то конкретной платформы.
Я неплохо помню собеседования и в качестве начинающего (не стажера), и среднего, и старшего… В нашем городе у большинства айти-контор принято небольшое тестовое задание + очная встреча до или с обсуждением задания после, у некоторых просто очная встреча + примитивный кодинг/тест на месте и лишь у немногих большие задания «на дом» или прямо на собеседовании, причем независимо от позиции, на которую претендует кандидат. Сам при поиске придерживаюсь именно первого варианта со встречей после выполнения задания, поскольку считаю его наиболее информативным: код, написанный в зоне комфорте, о чем и говорит автор, дает исчерпывающее описание специалиста. А все сомнения можно устранить при обсуждении. Задание не должно быть слишком простым или тривиальным (не информативно), не должно быть очень сложным (не каждый согласиться потратить много времени), должно коррелировать с интересами кандидата и вакансией (глупо ожидать качественного гуя от бэкэндера).
Если от джуна и мидла еще актуально ожидать знаний каких-то технологий, то с сеньором это уже не работает, тут имеет значение лишь абстрактный опыт и хочешь — не хочешь, а интервьюверу придется просто вникать в специфику рассказанного кандидатом, чтобы оценить уровень и соответствие человека вакансии. Вопрос о том какое задание считать простым, а какое сложным, все-таки, зависит от рода деятельности разработчика и сферы интересов компании. То, что для сишника элементарно, джависту просто не интересно и наоборот.
Есть у нас и конторы, где собеседуют с написанием кода пол-дня, с перерывом на обед или дают задание «на дом» с оценкой не в одну неделю, но весть о таких разносится быстро… хотя не слышал, чтобы они испытавали жесткий кадровый дефицит, видимо, работает просто как уровень отсеивания.
Приведу пример: я сам провожу собеседования и ни раз было, что кандидат норм говорит, объясняет, но когда дело доходит до кодинга, у меня иногда глаза на лоб вылазят. Чего я только не видел: и рекурсивный вызов метод, у которого в качестве параметров два массива просто для того, чтоб поменять параметры местами, и абсолютное не понимание того, что в коллекция или массив в котлине не должны быть обязательно var, чтоб быть мутабельными и много чего другого интересного. Это такие синьоры должны разрабатывать какие-то сложные системы, менторить джунов и многое другое? Для большинства уже просто создать массив, а не лист — это прямо серьёзный вызов, а уж перевести коллекцию в массив — это почти что-то недостижимое.
Помимо разряда в трудовом.
Или врач-(от бога), врача-средней руки, или только закончившего интернатуру и подтвердившего свой диплом?
И что, за 20 минут вы не можете разбить сторку на слова и один раз пройтись по списку слов сравнивая их с заданными словами? Я вообще удивлен, почему про эту задачу написано medium, если она совсем easy.
И вы считаете себя синьером? Или писать программы — это выше вас? Вас не смущает, что основная задача вас на работе будет именно что писать программы?
я сразу прошу, чтобы умный интервьюер решал параллельно задачу, которую я ему дам
Но интервьюверу не надо ничего вам доказывать. Это вы хотите попасть в компанию на работу и поэтому готовы проходить интервью. Интервьювера скорее всего заставили проводить это интервью сверху. Он бы с радостью сидел и писал свои задачи вместо общения с вами. Если вам такое интервью не по нраву — просто откажитесь до собеседования и не тратьте ничье время. Если бы вы были нужны компании больше, чем она вам, то с вами бы никаких интервью не проводили вообще.
Причем в вашей аналогии сразу много нестыковок. И если ей следовать, то мы не должны давать задачи сеньерам, а джунам должны, то выходит опытным преподавателям мы не должны давать провести урок по теории чисел, а тем, кто сразу после вуза должны?)
Если вы во время джунства не научились решать простейшие задачки, то как тот факт, что по прошествии n лет вы, уже называя себя сеньером, можете решать такие задачки?
Ну может вы и можете сделать там импорт..., но неумение решать задачки покажет, что вы скорее всего их никогда и не решали и не прошли этот этап и не обладаете, как и не обладали способностью мыслить подобным образом. Это просто ваша лень. имхо
А что с этой темой случилось, почему вдруг такой активный некропостинг?
Почему сеньоры ненавидят собеседования с кодингом, и что компании должны использовать вместо них