Собеседование
У нас с Сергеем Чистовичем сейчас проходит примерно по 1—2 собеседования в день. Для оптимизации (чтобы быстрее понять что знает кандидат, а что нет), приходится придумывать вопросы с подвохом.
Например (это Python), что будет тут — True или False и почему:
u'ВАС' == 'ВАС'
str('') == str('')
object() == object()
Добавлено через несколько часов: ребята из комментариев, вы что правда считаете этот элементарнейший тест «тонкостями» и «хитростями» языка? То есть вы в коде никогда не сравниваете два объекта? Два числа, например, да что числа, просто любые два объекта?
А такие вещи как разное поведение наследования у «классических» и «новых» классов, наверное, вообще у вас считается заумью?
И какие знания помогает определить этот вопрос?
(какой ужасный урл, жж-ый openid что-то не хочет работать)
Это вопросы не для того что бы взять, а для того что бы отсеять. :)
Первый с подвохом =)
Комментарий для Splurov:
Массу. Попробуйте без интерпретатора ответить на эти вопросы, потом объяснить почему так, потом внести в интерпретатор и посмотреть, сойдётся ли.
Комментарий для fulc.ru:
Точно :)
Комментарий для Евгения Степанищева:
Я к тому, что знание этих тонкостей в реальной работе могло никогда и не встретиться, поэтому не может сказать ничего о знаниях кандидата.
Комментарий для Евгения Степанищева:
Мы всем кандидатам ещё до собеседования письмом отправляем два вопроса с подвохом (C++):
char *a = new char[n];
char *b = new char[n];
f(a,b,n);
delete [] b;
delete [] a;
if( argc > 1 )
printf( argv[1] )
В обоих случаях предлагаем указать на недостатки предложенного кода.
Если кандидат не справляется с этими вопросами, мы вообще не приглашаем его на собеседование.
За всё время попался только один кандидат, который явно не сам ответил на эти вопросы. Остальные, насколько я могу судить, играли честно.
Тем, кто приходит на собеседование, мы предлагаем для решения несколько не слишком сложных ситуаций, просим написать код и смотрим, можем ли мы допустить кандидата к разработке. Т. е. способен ли он в принципе писать код, который потом не придётся переписывать кому-нибудь другому.
Комментарий для Splurov:
«Тонкости»? Это по-вашему, тонкости? :) Это базовые знания — сравнение двух объектов.
Первый False, так как юникодная строка != обычной строке, если в ней находятся не ASCII символы
Второй True, пустая строка == пустой строке
Третий False, так как идентификатор первого объекта != идентификатору второго объекта
Комментарий для sergey-cheban.livejournel.com:
Не могу оценить, так как не знаю C++
Комментарий для djangonaut.blogspot.com:
А кто сказал, что в ней находятся не ASCII символы?
Дальше следует вопрос почему две одинаковых строки — True, а два пустых экземпляра одного класса object — False?
Комментарий для sergey-cheban.livejournel.com:
Впрочем, ответ на второй вопрос я знаю.
Комментарий для Евгения Степанищева:
False скорее всего потому, что сравнивать больше нечего, кроме указателей.
правильно?
Комментарий для Евгения Степанищева:
Да. 2 и 3 из области того, что можно знать из мануала, но никогда на практике не применять. А вот результат «u’ВАС’ == ’ВАС’» мне интересен, предполагаю, что если запустить из консоли будет ошибка, а если файлик сохранить в юникоде, то ошибки не будет :-) Но это всё гадание...
Комментарий для Евгения Степанищева:
Хотя после последнего комментария troll признаю свою неправоту, нечего мне лезть не в свою степь :-)
Комментарий для troll:
1 — True
Комментарий для indeec17:
ага, с первым я ошибся — если ASCII символы — то True, если нет — то False
Комментарий для troll:
Правильно.
Комментарий для Splurov:
Вы сейчас говорите полную ерунду. На практике вы никогда не сравнивали объекты? Магический метод __eq__, по-вашему, придумали «чтобы был»?
Ещё раз: это не «тонкость», это элементарное знание о том, что разные экземпляры не равны между собой, но операция сравнения может быть перекрыта.
Комментарий для indeec17:
Да, если не определён __eq__ то сравнивается — один и тот это экземпляр или нет, иначе зависит от.
Комментарий для indeec17:
Впрочем, я не совсем точен. Есть ещё __cmp__.
Абсолютно не зная питона, ответил правильно на все вопросы (судя по комментария) исходя из принципа «как наиболее ожидаемо»
Можно спрашивать, чем отличается ’вася’ от u’вася’ и наслаждаться ответами типа «тем, что вторая строка в cp-1251». Тех, кто ответит правильно, нужно спросить, чем они отличаются и почему не равны даже, если локаль юникодная.
P.S. Вообще всем, кто считает, что в каких-то нерусских продуктах кодировка по умолчанию может быть cp-1251, нужно ставить жирный минус.
Комментарий для mrkandy.wordpress.com:
я также, абсолютно не зная питона, запустил его командную строку (давно инсталлировал для гуглодевелопердея) и скопировал туда каждое из условий. И только потом начал думать. По моему скромному имхо, самая правильная последовательность. Именно из-за наличия компа и интернета, которые на работе, связанной с инетом, отнимать не будут, считаю, что тесты такие отсеивают способных, оставляя опытных. У опытных же свои недостатки... А новичку покажи True-True-False, он же посидит минуту подумает, где это пригодится, поймёт и всё, уже не отличается от опытного. Сделали бы просто обучение «Питону от Яндекса», можно ж и платное...
Комментарий для indeec17:
Если на работу предполагается взять знающего питон, а не готового его выучить, такие тесты очень к месту. Тесты для способных, но не опытных, хорошо давать для стажеров.
А если человек с хорошим алгоритмическим мышлением и умением находить правильные решения, структуры данных, но абсолютно без знаний питона?
Комментарий для indeec17:
Нам нужны способные и опытные. Кстати, должен пояснить, что у нас нет такого «провалил один тест — гуляй». Это влияет, конечно, но не столь однозначным образом.
Нанимать человека за хорошие деньги, а потом его ещё и учить тому, что он должен уметь — это как-то странно. У нас есть стажировка в «Яндексе», Володя Москва (который fulc.ru) именно так и пришёл.
Комментарий для wiktar.com:
Я думаю, в «Яндексе» для него найдётся место. Но это вряд ли место «разработчика на Пайтоне», не так ли?
Комментарий для indeec17:
Думаю, ваше предположение строится из ложной предпосылки, что человек должен писать код, ну или читать свой. Это, конечно же, не так.
Придётся читать и быстро разбираться в тоннах чужого кода, что-то дописывать, выправлять и т. п. Необходимо уметь понимать хотя бы бОльшую часть кода, который перед глазами.
Для данной вакансии это куда ценнее, чем уметь написать/придумать алгоритм, который ищет циклы в связанном списке за O(n), используя память O(1).
Комментарий для Евгения Степанищева:
Спасибо, я понял предпосылки свои и ожидания от пайтоновцев. В тоннах неизвестного заранее кода скорее всего встретится магия с экземплярами объектов =) Используемый быстрый тест хорош. И замечательно то, что он используется совместно с другими, которые напрямую относятся к обязанностям. Типа вот тебе тонна, пойми задачу и исправь 10 ошибок =)
Я вот тоже всегда такие тесты считаю немного ущербными.
Например, если человек любые такие задачки сходу решает, то скорее всего ему нравится. Если ему нравятся такие задачки, то вероятно его код будет состоять из многих тонкостей и хитростей. Сложный код сложно читать, а как ты сам заметил, работа программиста на обычного размера проекте — это в основном чтение чужого кода. То есть взяв такого программиста вы усложняете работу остальным. В чем смысл?
Мне кажется, что понятный код — это одна из основных ценностей промышленного разработчика, разве не так?
Кстати, проблема с чтением существующего кода вполне может расти из критериев отбора на проект.
Комментарий для www.shcoder.by:
Ребята, вы чего все? Какие «тонкости» и «хитрости»? Это тест на понимания очень базовой вещи, сравнения объектов. Это то, что встречается очень и очень часто.
Комментарий для indeec17:
Не, неверно понял. Откуда такие выводы?
Комментарий для www.shcoder.by:
Это не какие-то хаки, а базовые вещи — знать, что возвращает str(), и как сравниваются строки. Не нужно думать, что человек, знающий ответ на первый вопрос, будет таким способом всегда проверять, есть ли в строке ASCII-символы.
Умение писать читаемый код не должно пропадать от знания таких вещей, но по ним можно понять, насколько глубоко человек знает тему, и оценить реальный опыт.
Комментарий для Евгения Степанищева:
это не выводы, я не утверждаю, что у вас так. Это краткое описание теста, с адекватностью которого описанным задачам «читать и быстро разбираться в тоннах чужого кода, что-то дописывать, выправлять и т. п.» я бы согласился. Евгений, тебе твоя ситуация ближе, поэтому оставляю за собой право не понимать задачи отбора в точности, только в общем приближении. Хотелось бы, конечно, понимать.
Комментарий для Splurov:
http://roem.ru/2010/07/23/addednews15686/
Bolk, не знаю ответ на первый вопрос — в Java/.NET все строки в Unicode :) Наивно понял, что зависит от того в какой кодировке сохарнен исходник, так что ли? Или это действительно разные типы? Если так, ну немного «хитро» выглядит. Остальные вопросы в принципе одинаковы везде и базовые, согласен.
Просто по первой строке сделал вывод, что многие тесты из разряда посчитай результат многоэтажного выражения — любимое развлечение сишников кода в стиле write only — хотя, наверное, ошибаюсь.
На самом деле недавно участвовал в собеседовании, один из товарищей начал гонять человека по внутренностям Java похожими вопросами. Человек в итоге немного разнервнечался, в конце уже даже простой логичской задачи в коде не мог решить. Ловил себя на мысли, что в некоторых областях сам плаваю (хотя уже пару лет серьезно не кодировал, да и Java не мой родной язык), но уверен, что многих товарищей заткну за пояс при решении реальных задач. Просто дело не в деталях, дело в подходе.
Мы вот один раз брали .NET-чика на Java позицию (была уверенность в человеке просто), так вот писать код он смог сразу, а писать код лучше всех остальных жаверов — уже через пару месяцев. Не в знании языка дело.
Комментарий для www.shcoder.by:
Зависит от того русские буквы или латинские :)
Ну, слава богу, в Python3 это не так.
Комментарий для sergey-cheban.livejournel.com:
а в первом коде в чем недостаток, кроме бесмыссленности?
Комментарий для Евгения Степанищева:
насчет опеид и жж:
http://ksena.livejournal.com/2526151.html?mode=reply%26style=mine