Здравствуйте, Donz, Вы писали:
D>Уже писал ранее. Возможно, для тебя использование не ArrayList'а — это преждевременная оптимизация. Для меня выбор правильной коллекции — норма. А еще я шурупы заворачиваю отверткой, а не всегда использую молоток. Хотя шуруп, забитый молотком, тоже будет держаться.
Лучше вбитый шуруп, чем вкрученный гвоздь
Здравствуйте, Klatu, Вы писали:
K>Единственное, что стоит спрашивать у программиста — какие проекты он сделал. Посмотреть, обсудить, разобрать по косточкам. Всё остальное, все эти высосанные из пальца задачи и тесты — это бред бездарных кадровиков и зубрил, которым надо как-то оправдать свое существование.
Если сделать так, как вы говорите. То вы на этом же форуме напишете, что нехороший человек на интервью спрашивал вас про берцовые кости, а должен был про ребра.
Здравствуйте, Философ, Вы писали:
Ф>Здравствуйте, vladimir_i, Вы писали: _>>От вас не убудет, если вы поймете как найти 1 фальшивую монету из 8 за 3 взвешивания?
Ф>Кстати да, нужно не про 8 монет спрашивать, а про 65536 монет. И спрашивать нужно о том, сколько взвешиваний понадобиться, чтобы вычислить фальшивую монету. Человек, никогда не слышавший о бинарном поиске, или не использовавший его выдаст слишком большую цифру
Я позанудствую чуток. Самый распространенный полный вариант формулировки задачи, известный мне — "за какое минимальное количество взвешиваний можно найти фальшивую монету из 8, если известно, что она весит легче настоящей?"
Ответ — за 2 взвешивания и к бинарному поиску отношения не имеет. Чтобы избежать флейм, это обсуждалось 100500 раз на этом форуме. Когда-то была свежей и оригинальной из-за необходимости срыва шаблона о поиске разбиением ровно пополам. Известно, что школьники в 1990 году уже справлялись с ней. Возможно, он тайно посещает синагогу ей более века и по степени актуальности для собеседований программистов она стоит в ряду задач про бабушек с фонариком, стеклянных шариков сбрасываемых со 100-этажного здания, числа бензоколонок и прочей чепухи, которая давно уже в гуглах и майкрософтах почти не спрашивается для выяснения того, подходит кандидат или нет. Может только для фана, когда понятно, что кандидат не торт.
Ну и как продолжение предыдущей мысли, чтобы не вставать дважды, не стоит из одиночного собеседования делать глобальные выводы. Например, если в вашем резюме есть маленький проектик, который выбивается из основной линии, а у вас на интервью уделилось ему хорошее внимание за приятной беседой, это может означать, что интервьюверу все ясно, просто надо убить время и расслабиться перед следуюшим кандидатом.
К этому моменту у меня внутри 0.5, 0.7, 0.33 (с) НС
Здравствуйте, Klatu, Вы писали:
K>А зачем? Мне не интересна должность старшего помощника младшего быдлокодера в команде рисования анимации на кнопке "Start"
Ну так и нужно было искать вакансии/переходить в другие команды Благо таковых имеется в огромногом количестве. А для должности младшего быдлокодера в команде кнопки Старт все перечисленное ниже, возможно, ожидаемо.
K>Я несколько раз собирался с духом и проходил аналогичные собеседования с дурацкими задачками, и каждый раз это заканчивалось одинаково: K>1) ПМ с изумлением обнаруживал, что я действительно хорошо умею писать код, но использовать этот факт оказывался не в состоянии
На самом деле, здесь должность ПМ не о том, чтобы понимать умение хорошо писать код. Это умение надо скорее демонстрировать лидам, синьорным коллегам, архитекторам и т.п.
K>2) собеседование оказывалось самой сложной задачей за все время работы в фирме
Реально есть проблема того, что многим людям с опытом занижают уровень при приеме на работу. Иногда ставят одинаково со свежими выпускниками колледжей. Отсюда и заниженные требования и сфера ответственности. И находясь на L59 можно хоть десять раз пытаться продвинуть гениальный проект, вот только это не оценят. Ибо не то ожидается от L59. Большая компания, что поделать. В итоге человеку скучно и противно.
Что делать? Варианта два.
Потерпеть, дойти хотя бы до L61, а лучше 63 , и будет уже намного веселее. Параллельно утешаясь чем-нибудь для души. Не супер как здорово, конечно.
Не наниматься в неинтересные команды на неинтересные должности/уровни. Стараться найти то, где сразу предложат больше. Либо найти что-то более интересное потом, и перейти туда. Но здесь есть проблема в том, что уровень при внутренних переходах никогда не повышают.
K>3) работать с людьми, которые прошли через сито такого интервью — весьма некомфортно, ибо к работе в реальных условиях они не приспособлены
Через такие интервью проходят и те и другие.
K>4) за годы работы эти люди успели произвести тонны невероятно уродливого быдлокода
Кроме того, еще большие тонны уродливого кода за эти годы произвели другие люди, которые тут уже и не работают давно. А переписать все не так-то просто по многим причинам. По моим наблюдениям, культура и требования к design/code review вырасли несравнимо. Хотя опять-таки, все зависит от подразделения/группы.
Здравствуйте, Klatu, Вы писали:
K>Есть ряд компаний, где такие задачи — это официальная политика, жестко прописанная в правилах. Включая упомянутые тобой гугл и майкрософт.
Это было правдой несколько лет назад. Сейчас — полнейший бред.
Более того, HR официально больше НЕ рекомендует таких задач.
Здравствуйте, sql13, Вы писали:
S>Это было правдой несколько лет назад. Сейчас — полнейший бред. S>Более того, HR официально больше НЕ рекомендует таких задач.
Между официальной рекомендацией и практикой есть большая разница
Впрочем, как сейчас — точно не знаю. Но некоторое количество лет назад ваше собеседование было лютым идиотизмом.
А от милой привычки передавать впечатления от первого интервьюера к следующим у вас еще не додумались избавиться? Схема "плохой интервьюер, хороший интервьюер" тоже еще используется?
Здравствуйте, sql13, Вы писали:
S>Потерпеть, дойти хотя бы до L61, а лучше 63 , и будет уже намного веселее.
То есть у вас продвижение зависит не от качества работы, а от стажа в фирме?
S>Через такие интервью проходят и те и другие.
Нет. Через них в основном проходят студенты и профессиональные ходоки по интервью, потому что сформировавшимся профи учить задачи про гномиков и заниматься прочей "спецподготовкой" просто противно.
Я например был на вашем собеседовании давно, года через 2 после универа. На должность программиста-тестировщика. И у меня на собеседовании спрашивали про radix sort. Вы не находите, что спрашивать такое у тестера — это просто за пределом всех допустимых границ идиотизма?
Ну то есть это я потом понял, что от меня хотели услышать про radix sort, а тогда про экзотические методы сортировки был не особо в курсе. Да и сейчас знаю про них главным образом потому, что на собеседованиях спрашивают
Здравствуйте, Klatu, Вы писали:
S>>Это было правдой несколько лет назад. Сейчас — полнейший бред. S>>Более того, HR официально больше НЕ рекомендует таких задач.
K>Между официальной рекомендацией и практикой есть большая разница K>Впрочем, как сейчас — точно не знаю. Но некоторое количество лет назад ваше собеседование было лютым идиотизмом.
Сейчас не встречался и не слышал, чтобы такие вопросы задавали. На самом деле, HR обычно проводит лишь легкий скрининг. На этом этапе, в принципе, могут спросить что-то простенькое на соображалку, не связанное напрямую с программированием. Но релистичное, не из серии люков, гномов, и горы Фудзи.
Основное интервью всегда проводят инженеры и менеджеры из команды (и смежных с ней), где предполагается позиция. Ну или если это hiring trip, могут быть представители нескольких команд.
Поэтому разных задач столько же, сколько и разных людей. Может, и бывают неадекваты, как и везде, но я не сталкивался.
K>А от милой привычки передавать впечатления от первого интервьюера к следующим у вас еще не додумались избавиться?
А что тут такого плохого? Обычно это не в стиле "я ставлю hire/no hire", а в стиле "я побеседовал на тему проектов, довольно интересно, но вот проверить coding skills нормально времени не хватило. Посмотри с этой стороны повнимательнее". Или "похоже, algorithmic problem solving хромает. Подкинь-ка ему еще другую задачку, может он просто нервничает на интервью с утра?".
K>Схема "плохой интервьюер, хороший интервьюер" тоже еще используется?
Здравствуйте, sql13, Вы писали:
S>Сейчас не встречался и не слышал, чтобы такие вопросы задавали. На самом деле, HR обычно проводит лишь легкий скрининг. На этом этапе, в принципе, могут спросить что-то простенькое на соображалку, не связанное напрямую с программированием. Но релистичное, не из серии люков, гномов, и горы Фудзи.
Ну у меня например спрашивали и дурацкую задачу про зажигание лампочек, и про тестирование пульта от телевизора, и прочую бесполезную муть.
K>>А от милой привычки передавать впечатления от первого интервьюера к следующим у вас еще не додумались избавиться? S>А что тут такого плохого? Обычно это не в стиле "я ставлю hire/no hire", а в стиле "я побеседовал на тему проектов, довольно интересно, но вот проверить coding skills нормально времени не хватило. Посмотри с этой стороны повнимательнее". Или "похоже, algorithmic problem solving хромает. Подкинь-ка ему еще другую задачку, может он просто нервничает на интервью с утра?".
Это создает предвзятое отношение.
Каждый замер должен быть полностью независимым, ваших кадровиков в универе основам проведения экспериментов не учили?
K>>Схема "плохой интервьюер, хороший интервьюер" тоже еще используется? S>О такой не слышал.
Очень просто. Один — въедливый и постоянно задает неудобные вопросы, другой жутко непонятливый и постоянно переспрашивает, третий очень добрый (по крайней мере с виду ) и прощает все ошибки. Слишком отличается от стандартно-нейтрального отношения, чтобы быть случайностью.
Здравствуйте, Klatu, Вы писали:
K>То есть у вас продвижение зависит не от качества работы, а от стажа в фирме?
Я бы сказал так: продвижение зависит от качества работы, ожидаемого на данном уровне.
Однако и работы на более низком уровне может хватать на full time, только она бывает скучная и неинтересная.
Соответственно, если чуваку неинтересно, он может двигать какие-то другие идеи, которые никому не нужны на этом уровне. Но забивать на ту работу, которую от него ждут. И получить underperformed вместо повышения. В результате наступает полный диссонанс.
Я ни в коем случае не говорю, что это хорошо. Просто есть такой факт, но с ним можно бороться. Как, я уже писал. Если немного терпеть и делать все здорово и чуть луше других но по работе, ожидаемой на этом же уровне, то повышение может наступить быстро, особенно на нижних уровнях. Но гораздо лучше сразу идти на позиции, где требования и уровень выше. А если на такие не возьмут, то и черт с ним. Лучше не портить себе жизнь проблемами, описанными выше.
S>>Через такие интервью проходят и те и другие.
K>Нет. Через них в основном проходят студенты и профессиональные ходоки по интервью, потому что сформировавшимся профи учить задачи про гномиков и заниматься прочей "спецподготовкой" просто противно.
Ну если нужны примеры, у меня было >10 лет опыта на момент прохождения интевью. Причем, на одом месте работы. И к интервью я почти не готовился. Спрашивали про всякие перестановки и танцы со списками и деревьями, но для которых знания никаких специальных алгоритмов не требовалось. А еще спрашивали как бы я задизайнил масштабируемый Web сервер.
Здравствуйте, Klatu, Вы писали:
K>Ну у меня например спрашивали и дурацкую задачу про зажигание лампочек, и про тестирование пульта от телевизора, и прочую бесполезную муть.
Наверное, это было несколько лет назад.
K>Это создает предвзятое отношение. K>Каждый замер должен быть полностью независимым, ваших кадровиков в универе основам проведения экспериментов не учили?
Предвзятое — не предвзятое. Тем не менее, не мешает одному в итоге сказать hire, когда предыдущий сказал no hire, и наоборот. Люди-то чай самостоятельные и со своей головой, зачем идти на поводу у других?
K>>>Схема "плохой интервьюер, хороший интервьюер" тоже еще используется? S>>О такой не слышал.
K>Очень просто. Один — въедливый и постоянно задает неудобные вопросы, другой жутко непонятливый и постоянно переспрашивает, третий очень добрый (по крайней мере с виду ) и прощает все ошибки. Слишком отличается от стандартно-нейтрального отношения, чтобы быть случайностью.
А сколько раз вы проходили интервью в MS? В разные команды?
Здравствуйте, sql13, Вы писали:
S>Ну если нужны примеры, у меня было >10 лет опыта на момент прохождения интевью. Причем, на одом месте работы. И к интервью я почти не готовился. Спрашивали про всякие перестановки и танцы со списками и деревьями, но для которых знания никаких специальных алгоритмов не требовалось.
И конечно с кодом на бумажке?
S>А еще спрашивали как бы я задизайнил масштабируемый Web сервер.
Здравствуйте, Klatu, Вы писали:
K>И конечно с кодом на бумажке?
Ну не без этого. Но существует масса небольших задачек, укладывающихся в scope "на бумажке", по которым можно увидеть, как кандидат мыслит, принимает решения, и пишет код. Все должно быть в течении часа. Времени на написание полноценно рабочего кода (на лаптопе/десктопе и и.п.), с обсуждением того как кандидадт пришел к нeму, какие проблемы были и остались и т.п. может не хватить. Бумажка тем и хороша, что позволяет поговорить много о чем без необходимости собственно иметь рабочий код.
S>>А еще спрашивали как бы я задизайнил масштабируемый Web сервер. K>Собеседовался в команду IIS?
Как ни странно, нет. Может, собеседователь был в прошлом из команды IIS, это я не проверял
24>Что нужно — это одно. А вот определение того, что кандидат этому соответствует — совсем другое. Я пока не видел ни одного адекватного способа определить, хороший программист или плохой, за исключением того, чтоб поработать с ним пару месяцев (но такой способ "собеседования" по многим причинам неприемлем).
Лично я смотрю на процесс найма просто: это набор фильтров, каждый следующий заметно дороже предыдущего (самый дорогой — испытательный срок).
24>Задачами про гномиков и взвешивание шаров в большинстве случаев можно определить лишь то, знал ли кандидат эту задачу раньше. Это тоже что-то показывает — человек любознательный, интересуется чем-то за пределами работы (хотя возможно и наоборот — целенаправленно готовится проходить собеседования, вместо того, чтоб потратить то же время на профессиональное развитие). К умению решать объёмные сложные задачи это имеет весьма косвенное отношение. Но если на работе нужно постоянно решать задачки про гномов (или искать решения в интернете) — тогда да, это хороший вопрос.
Как человек, не умеющий делать содержательный вывод из подобных задачек могу сказать только что лично мне они не подходили. Но у меня нет причин считать что подобного рода (но не именно такие) не имеют смысла. Все-таки реплики народа с задетым самомнением имеют маленькую ценность. Если можно дать задачку, не решив которую человек для собеседующего попадает в категорию не умеющих думать — why not? Наверное кому-то и задачки, которые я давал, казались глупыми, однако мне помогали отсеивать людей, которые с моей личной точки зрения не умели писать код.
aik>Для начала — ни тебя, ни меня не зовут ни в один гугль Не то чтоб прямо бедаааа, но все таки
Так в московский я сам не пошел. В сиднейский просто не пробовал (до вчера я даже и не знал, что он тут есть).
aik>Например, да. Поинт в том, что это существенно отличается от гномов.
Честно сказать, в моей жизни не было ни одного собеседования с задачами про гномов или канализационные люди. Это при том, что я в своё время собеседовался в микрософт и получил джоб оффер (но проиграл в H1B лотерею, а в Канаду ехать тогда не хотелось).
K>Гугл широко известен своими мозголомными задачками, равно как и майкрософт, о чем в инете есть масса обсуждений. Расскажи свои сказки кому-нибудь другому
Я бы на собеседованиях и там, и там. Получил джоб оффер от M$ (c гуглом просто сам не стал продолжать, т.к. не было спортивного интереса). Ни на одном из собеседований не было дурных "гномов". Списки, хеши, деревья (в т.ч. и довольно оригинальные задачи вроде того, как "соединить" разные виды деревьев, и какая будет сложность алгоритма) — было. Люков и гномов — ни разу.
D>Применил. Потому что знаю стоимость вставки и получения элементов из хеш-мапа.
О, прорыв просто.
Т.е. открыть algolist и выбрать нужный тип коллекции для конкретной задачи — это нынче как, недоступно большинству программистов? Кабы на собеседованиях спрашивали про то, какую выбирать коллекцию — это одно дело. Но спрашивают совсем другое, не про применение, а про реализацию структуры данных.
PS: я в своей нынешней работе использую порой нестандартные реализации структур (вот не далее чем вчера пришлось сделать свою реализацию односвязного упорядоченного списка — очереди таймеров, т.к. там требования специфичные, не подходили ни стандартные timer wheels, ни тем более priority_queue).
Здравствуйте, sql13, Вы писали:
S>Предвзятое — не предвзятое. Тем не менее, не мешает одному в итоге сказать hire, когда предыдущий сказал no hire, и наоборот. Люди-то чай самостоятельные и со своей головой, зачем идти на поводу у других?
Про эксперимент с "неправильным квадартом" не читал что ли?
S>А сколько раз вы проходили интервью в MS? В разные команды?
Да мне того раза с radix sort хватило, больше даже пробовать не стал. Не хочу иметь дело с людьми, которые начисто лишены чувства меры и здравого смысла.
Здравствуйте, sql13, Вы писали:
S>Ну не без этого. Но существует масса небольших задачек, укладывающихся в scope "на бумажке", по которым можно увидеть, как кандидат мыслит, принимает решения, и пишет код. Все должно быть в течении часа. Времени на написание полноценно рабочего кода (на лаптопе/десктопе и и.п.), с обсуждением того как кандидадт пришел к нeму, какие проблемы были и остались и т.п. может не хватить. Бумажка тем и хороша, что позволяет поговорить много о чем без необходимости собственно иметь рабочий код.
Эту байку я слышал уже 100 раз. Это не работает. Искусственная задача, в искусственных условиях.
S>Как ни странно, нет. Может, собеседователь был в прошлом из команды IIS, это я не проверял
Дурацкий вопрос для человека, который не будет архитектором проекта. И ответы могут весьма субъективными.
Здравствуйте, SkyDance, Вы писали:
SD>Т.е. открыть algolist и выбрать нужный тип коллекции для конкретной задачи — это нынче как, недоступно большинству программистов?
Судя по этой теме, да, видимо недоступно. К тому же, чтобы выбрать тип коллекции, надо бы знать особенности этой коллекции.
SD>Кабы на собеседованиях спрашивали про то, какую выбирать коллекцию — это одно дело. Но спрашивают совсем другое, не про применение, а про реализацию структуры данных.
Так и спрашивают. Сложность поиска элемента, сложность вставки и т.д.
Чтобы принимать, нужно знать основные принципы, как устроена коллекция. Никто полную реализацию HashMap'а на листочке не просит.
SD>PS: я в своей нынешней работе использую порой нестандартные реализации структур (вот не далее чем вчера пришлось сделать свою реализацию односвязного упорядоченного списка — очереди таймеров, т.к. там требования специфичные, не подходили ни стандартные timer wheels, ни тем более priority_queue).
