Pull to refresh

Comments 72

На мой взгляд, эта история напоминает буддистский коан. Чтобы ее понять, надо не только прочитать, но и подумать над ней.
Чтобы её понять, достаточно прочитать её. Думать же над нею опасно: можно ненароком обрести просветление.
И вот тут возникает вопрос: а так ли нужны были Эдисону эти знания у помощника для его работы?
Чем-то напоминает требования знания основ администрирования AD\Exchange для вакансии курьера.
Сегодня на его вопросы можно отвечать: — Google.
Если бы сегодня Эйнштейн искал бы помощника, сначала бы это ему встало бы в копеечку.
А через три года его помощник начал бы свой бизнес или ушёл бы и слил технологии Эдисону.
И это ещё при условии, что рядом не было бы, запрещающих всё новое, властей.
<irony>безысходность..</irony>
Достали эти статьи про собеседования — одни пишут: «Ха, зацените какие идиоты к нам на собеседование приходят! Не отвечают даже на простейшие вопросы, но я такой крутой — всех режу», вторые жалуются на идиотов-интервьюверов\идиотские вопросы.
Ну согласитесь, иногда действительно приходят идиоты и без разницы с какой стороны, но чаще всего это оправдания себя.
Мне очень повезло, когда я поступал в военное училище. На экзамене по физике была задача, решить которую можно было просто подставив исходные данные в одну формулу. Но я забыл эту формулу но точно знал что она есть и где ее взять. Так я и ответил преподавателю. Он дал мне справочник, и я нашел ее достаточно быстро. Получил четверку вместо тройки, или даже двойки. Извините за оффтопик, просто вспомнил. Уже много лет успешно работаю программистом, но просматривая очередные вопросы для собеседований понимаю, что сходу на все не отвечу и, вероятно, не пройду такое собеседование. И в процессе работы постоянно обращаюсь к документации и просматриваю типовые решения
У нас преподаватель в институте всегда говорил, что все запомнить не получится, но главное понимать где это можно посмотреть.

Я, например, не помню некоторые запросы и операторы SQL (их синтаксис), но знаю где это можно посмотреть. Нужно быть очень узким специалистом чтобы досканально знать какую-то область.
А у нас говорили, что на тройку знает студент, на четверку преподаватель, а пятерка сам бог. И это говорил преподаватель по физике)
Довольно бессмысленная шкала оценки выходит :)
— Что должен знать студент?
— Всё!
— А что должен знать лаборант?
— Почти то же, что и студент.
— А Аспирант?
— В какой книжке находится то, что должен знать студент.
— Доцент?
— Где находится эта книжка.
— Профессор?
— Где находится доцент.
У меня у отца так же в институте говорил преподаватель по сопромату. Видимо, это распространенное выражение.
UFO just landed and posted this here
Ну когда я проходил сетевые технологии в институте — в глазах преподавателя я, на тот момент обладатель честно заработанной карточки с буквами CCNP на ней и датой получения годичной давности, а также записи в трудовой «сетевик в крупной компании», был божеством :)
Я сам до конца не понимал этой фразы, рассказываю действительность.
Но благодаря этому комментарию получил в ответ более интересный факт из жизни.
А у нас на физмате часто говорили, что студень — это человек, который с легкостью может взять сложнейший интеграл, но не сразу сможет вспомнить таблицу умножения. Что, как мне кажется, легко переносимо и в сферу программирования… Отсюда и смешные ситуации на собеседованиях, когда человек с большим опытом и серьезными проэктами за плечами с ходу не может строку инвертировать :)
Наш завкаф говорил: главное не всё знать, а знать у кого спросить.
Это модно так стало — писать посты вместо того, чтобы просто оставить комментарий к изначальному посту?
Я сомневался — написать отдельный пост или только оставить комментарий. Но все же решил остановиться на первом варианте по двум причинам:

1. Отдельный пост увидит больше людей. Например, это посмотрели уже более 10 000 раз.

Количество просмотров — это не цель, а лишь средство. Я надеялся, что люди, прочитав эту историю, начнут лучше понимать друг друга. Работодатели поймут, что задавать конкретные вопросы, особенно далекие от темы собеседования, — это, мягко говоря, не очень хороший вариант. А соискатели поймут, что работодатель задающуй такие вопросы не всегда идиот, стремящийся унизить других.

2. Отдельный пост может спровоцировать дискуссию. В ходе которой будут сформулированы мысли, которые я написал чуть выше. ль, что пришлось делать это самому.
Ниже просто пара мыслей, которые не касаются самой темы поста.

Я предполагал, что тема топика людям уже поднадоела, да и не был уверен, что история заслуживает отдельного поста. Но все-же решил рискнуть и опубликовать.

В целом я рад, что так сделал. Все-таки материал получили 33 плюсика, 18 звездочек и 20 комментария на момент публикации этого ответа. Видимо, он людям интересен.

Меня расстраивает, что у Вашей точки зрения много агрессивных союзников. Например, после публикования этого топика моя карма опустилась на 10 пунктов. Для меня это не критично, так как уровня все равно хватает для публикаций, но для новичков такое падение было бы «фатально». В целом это плохой сигнал. Он говорит о том, что атмосфера на Хабре не способствует публикованию спорных топиков, а ведь они часто самые интересные. Я бы хотел, чтобы люди было более терпимыми по отношению друг другу.
Атмосфера на Хабре не способствует публикованию комментариев в виде топиков.
Вы видимо, очень серьезный автор, который не написал ничего, но при этом отгреб себе плюсов за крутой комментарий

Согласен с вами, писать статьи широкой публике нынче действительно неблагодарное дело, лучше писать комментарии
В точку же, так и происходит!

Задаются вопросы — место, которым в справочнике, а не в голове.
А голова человеческая нужна для того, чего справочник делать не может мыслить, анализировать, сопоставлять, решать…
Тем более, чем шире возможности человека, тем менее шансов охватить всю справочную информацию по отраслям.

Лучшее, что остается, это предложить подобным «работодателем» посадить в кресло «Большой справочник»:
там есть ответы на все вопросы
ему не надо платить зарплату
он никогда не заболеет, не опоздает и не покинет рабочее место!

Отличный вариант, вот и посмотрим, как он «заработает».
Тут важен баланс. Всегда нужно проверять наличие каких-то знаний. В противном случае на любой вопрос человек ответит — погуглю. Давать человеку прямо на собеседовании решить более-менее сложную задачу с помощью гугла — никто на это не согласится, потому что это займет времени больше чем любое собеседование. А давать простую задачу, которая гуглится за 5 минут — так это ничего не показывает.

Если вы считаете что я не прав — было бы интересно увидеть пример, как надо проводить собеседование, например на senior программиста со знанием математики, без вопросов на знание чего-то (как вы говорите — «из справочника»).
со знанием математики, без вопросов на знание чего-то


Мы как-то проводили большое ревью кода в конторе и смотрели, кто как пишет. Так вот, оказалось, что большинство занимается copy/paste своего же кода, потому что просто не хочет помнить, как пишутся простые вещи. И в результате вместо простого знания и написания 90% времени занимает поиск такого же уже написанного куска и его переделка. В то время как реально быстрее, если помнишь, написать то же с нуля.

Это к вопросу о том, что некоторые вещи все-таки надо знать наизусть, а не лазить по справочникам или по своему ранее написанному коду — иначе думалка разучится думать.
Полностью поддерживаю. А еще очень важно осознавать, что «вот здесь надо залезть в справочник», а не писать просто так. Но если человек осознает что где-то может быть проблема, он обычно уже знает как ее решить.

А знание того, какие проблемы могут возникнуть, чтобы их недопустить (без разницы — справочником, гуглом, мозгами) — это то, что у многих прособеседованных, к сожалению, отсутствует.
В то время как реально быстрее, если помнишь, написать то же с нуля.

Для меня это серьёзная проблема. Действительно, написать с нуля быстрее, чем вспоминать, где написано. В итоге по коду проекта оказываются разбросаны десятки методов Гаусса, линейных аппроксимаций методом наименьших квадратов, сглаживаний массивов медианным фильтром (с различными тонкими настройками), линейных интерполяций по табличке, и прочее. Каждый кусок написан с нуля — для этого типа данных, для этого их источника, с этими дополнительными фильтрами. Разумеется, всё это намертво воптимизировано в окружающий код. И совершенно некогда собрать все примеры использования одного метода, выделить для него правильный, устраивающий все вхождения, интерфейс, и заменить его вызовами все нужные участки.
Это уже совсем другая проблема, скорее архитектурная и проблема рефакторинга.
Но если «совершенно некогда собрать все примеры использования одного метода» — это значит, что как раз надо остановиться и поразмышлять и подумать, что вообще творится в проекте. Оно же так всегда — написал раз, написал два — на третий обычно уже четко осознается, что код как минимум общий и его надо в отдельную либку класть.

Вообще, по моему опыту, если вдруг понимаешь, что что-то не успеваешь или что-то начинает уж жить совсем своей жизнью — надо говорить «стоп» и начинать думать, а не кодить :)
Оно же так всегда — написал раз, написал два — на третий обычно уже четко осознается, что код как минимум общий и его надо в отдельную либку класть.

Не помогает. Выделил, положил в библиотеку, раз использовал, второй использовал, на третий — сунулся — оказалось, что конвертацию данных к виду, пригодному для вызова, писать дольше, чем написать код на месте. Да и памяти на создание копии этих данных жалко. А на четвертый раз — вообще забыл, как метод называется. И всё по новой…
Да, это архитектурная проблема. Но и проект развивается, и не всегда удаётся вообразить новые реалии, в которые его занесёт…
Может быть имело смысл на третий раз предусмотреть второй вариант ввода данных в эту функцию? Прямо в самой функции?
Вот у циски есть уже двадцать лет как одна из наиболее престижных сертификаций в мире IT. Состоит экзамен из легкой теоретической части и тяжелой 8-часовой практической. На практической доступна примерно вся документация, причем даже с нормальным поиском (но никаких внешних ресурсов). Там есть всё, что требуется знать для успешной сдачи экзамена.
Но есть нюанс. Тех 8-и часов и без всякой документации не всегда хватает для выполнения всех заданий. Не удастся в процессе работы с нуля изучить какую-то технологию — все сроки будут просраны. А вот какую-то маленькую опцию, которую знал, но забыл — легко.
К чему я это говорю: можно дать кандидату набор вопросов, гугл и, скажем, полчаса времени. Если ответит с гуглом или без — значит, он либо много знает (хорошо), либо умеет грамотно искать информацию (даже лучше), либо и то и другое.
Я пока не могу придумать задачи, которые бы были объективны и укладывались в пол часа. Да и на собеседовании если человек забыл что-то я всегда подскажу и не буду считать это за его ошибку — если он «разбирается, но что-то подзабыл».
Ну я же условно про сроки…
Про «подсказать» — интереснее было бы дать человеку самому найти ответ.

В институте один из преподавателей разрешал нам пользоваться гуглом в процессе ответа. Т.е., рассказывая билет и получив вопрос, на который не знаешь ответа, можно один раз уйти к компьютеру и поискать ответ в интернете, или в литературе, или еще где. Но только вариант «зазубрил формулировку» не сработает, требуется понимание — он это проверял.
Вот с этой условностью и проблема. Я могу придумать задачу часов на 5, но никто столько не будет сидеть на собеседовании. Мы не Microsoft или Facebook, чтобы позволить себе это. А задачу чтобы уложиться в час-полтора, и чтобы с гуглением она показала уровень — я не могу придумать.
Ну какой-нибудь метод на пару строк, но требующий придумать хитрый алгоритм. Где можно на самом деле найти готовый, очень похожий алгоритм и адаптировать его. Не знаю, я не разработчик.
В качестве забавного вопроса можно дать гугл и попросить написать «сортировку строк методом Пуатье».
А ведь совсем недавно была другая тема, спрашивать убер пупер логические задачки. Из одной крайности в другую.
Образно говоря, вопросы, которые гуглятся — показывают, что у человека есть «в кэше» — т.е. с чем он сталкивался настолько часто, что уже запомнил и без гугла.
Ну и опять получаем очень узкого специалиста. Я вот ни в жизнь не вспомню как правильно писать конфиги для sphinx'a или nginx'a, например — но я знаю где найти эту информацию. Или с ходу написать какой-нить SQL-запрос, т.к. постоянно через ORM работаю — забыл уже, нужно почитать будет.

Но это не говорит ни о чем. Запомнить все невозможно, да самое главное и не нужно. В голове должна рождаться схема/шаблон, а детали реализации уже можно позже поискать.
По моему мнению, это близко к программированию. С любым кешем будут «промахи» — потому что не все хранится в кеше, его размер ограничен.
Т.е. один отдельно взятый «промах» ничего не значит, но 90% промахов мимо «кеша» кое-что да значат.
Как можно работая с ORM забыть SQL? Постоянно же нужно следить, чего он там негенерировал.
Абсолютно не важно, что именно он там нагенерировал. Вопрос только в том, работает ли то, что он нагенерировал и как быстро. Даже в случае самописного ОРМ через полгода только примерно помнишь, как там строятся сложные выборки.
Хочу в ваш мир, где hibernate и eclipselink не глючат. С самописными, наверное, лучше. Они скорее заточены под узкий круг запросов, с которыми работают хорошо. И под них никто не станет писать сложные criteria запросы, потому что самописные такие запросы вообще не станут обрабатывать.
В моем мире то, что глючит, перестает глючить. Так или иначе. Рано или поздно :)
Разве что люди… я думаю люди будут глючить всегда.
Пункт N из теста Джоэля: даете ли вы кандидатам писать код во время собеседования?

Ничто не говорит о человеке лучше, чем написанный им прямо при тебе код. Вместо дурацких вопросов «чем отличается X от Y».
Очень много постов на тему собеседований, поиска работы, зарплат и людей.

Сам хожу на собеседония и сам провожу технические собеседования, потому выделил для себя 2 основных правила собеседования человека:
1. Человек не должен быть **даком
2. Человек должен любить программирование
<habracut />
Не выполняется первое правило — вся комманда может начать работать плохо, так как человек новый человек может нарушить сложившиеся в команде связи, начнет отнимать время других участников команды.

Со вторым пунктом — несколько сложнее, в нем заключены следующие утверждения:
— желание идти вперед, учиться, развиваться в профессиональном плане.
— ощущение себя творцом, человек любит то что он делает.
— желание сделать лучше.

Если человек подходит по этим двум пунктам, то можно брать на испытательный срок, который и покажет насколько человек подходит команде и команда человеку. Это тоже важно, поскольку грамотный и толковый человек при работе в команде, которая ему не подходит, будет постоянно пребывать в дискомфорте. Неизвестно, что получится в итоге: человек тихонько найдет другую работу; попытаться переделать под себя других людей(как правило неудачно). Испытательный срок хорош тем, что можно так же посмтотреть на уровень развития спопбности Думай Головой. Эта способность нужна не только в сфере IT, но и в любой другой. Понятно, что если человек пишет код быстрее чем думает, то такой человек может не подойти команде(а может и подойти, если надо именно писать код быстро). И последнее(по порядку, но не по важности) на что я обращаю внимание — оценки, которые делает человек. Будь-то время прихода на работу, срок выполнения задачи или новый смартфон от company_name, аргуметированность суждений для меня очень важна.

Что де касается самих собеседований, каждый их нас может задать такой вопрос на собеседовании, на который сходу не ответит даже профессионал, как пример:

— Как заменить все названия TestSuite в отчетах JUnit на русские названия, которые берутся из собственной аннотаций к классу? Версия Junit 4.10.
(Вопрос для программистов Java)

Сидим думаем. Без поиска по гуглу. Есть только тест, аннотация и IDE.

Не смогли придумать? Вы нам не подходите… Очень жаль..

Это НЕ подход, но он очень часто встречается на собеседованиях. Получается что-то типа такого: «Мы нашли нестандартной решение для нашей нестандартной задачи, после чего решили, что все должны об этом знать и спрашиваем об этом у каждого собеседуемого человека.»

— Напишите код программы, которая… на этом листочке

Очень, здорово, а компьютера у вас нет? А можно своим ноутбуком воспользоваться? А у вас все программисты на листочках пишут?
Тоже, по моему мнению, не подход.

Собеседование — процесс на котором можно задать самые разные вопросы, но почему-то мы забываем об этом.
Вопрос типа: «Каким кодом вы гордитесь?», не слышу уже давно.
(Для меня лично правильный ответ — никаким, код старше месяца хочется переписать).
«Придумайте алгоритм для ....что-то интересное», так же давно не задают.
«Вот вам задачка на логику, порассуждайте над ее решением вслух» — единицы, а ведь этот вопрос реально покажет вам то как человек думает. Даже если задача решена неправильно, человека можно оценить по его рассуждениям.

И напоследок — очень важное для меня замечание — поддерживайте связь с человеком! Позвоните ему после собеседования, особенно если он не прошел его, объясните почему, ведь возможно, что через полгода-год, к вам придет тот же человек, но теперь он подойдет вам!

Всем удачного дня!

>Для меня лично правильный ответ — никаким, код старше месяца хочется переписать
Печально :). Должны быть все таки такие места, которым потом даже сам воспринимаешь как «озарение» :). По мелочи конечно правки надо вносить, но не верю, что за весь опыт работы нет удачных архитектурных решений, которые даже не возникает желания переписывать.
Я думаю, что гордиться нужно алгоритмами и методами решения задач, а не кодом.
Зависит от решаемых задач. У меня например алгоритмические задачи встречаются раз в несколько лет. Зато архитектурные довольно часто. И алгоритмические решения это чаще всего прозрение + эвристики, тогда как архитектурные решения это опыт и большая большая работа.
Но архитектура — это же не код :) Да и архитектура прекрасно вписывается в понятие «методы решения задач».
Остановимся на том, что у нас разное понимание этих терминов ;)
Наверно это моя проблема, но когда через месяц открываешь старый код, постоянно хочется что-то улучшить, сделать лучше, применить другой подход или оптимизировать.
— Напишите код программы, которая… на этом листочке

habrahabr.ru/post/111843/

Вполне разумный вопрос.
Ну так там по-моему ничего о бумаге не говорится. Я думаю, что программисту гораздо быстрее и проще написать программу на привычном для него компьютере, чем брать в руки ручку, которой он возможно и не пользовался. Я не против писать код на собеседованиях, но против того чтобы делать это непривычным способом. Если я ошибся в третьей строчке, то уже не смогу ее переписать или заменить.
Если для решения подобной задачи нужен компьютер, диагноз однозначен. Не находите?
Я недавно собеседовался по подобной задаче, так сделал где-то три ошибки в вызове функций, но зато сделал с форматированием и прочими плюшками. Я и не особо вижу, где там нужен компьютер.
Я считаю, что это удобно для человека. И не сторонник собеседований типа: «Соберите стул и садитесь». На листочке можно написать алгоритм решения, простой кусок кода, как в выше приведенной статье. Но когда вас просят написать уже что-то сложнее на листке бумаги — меня это вводит в ступор. Я не умею рефакторить код написанный на листочке.
Так и проверяют не способность рефакторить и даже не способность отлаживать, а способность быстро написать код по простому ТЗ.
Собеседование — много сложнее чем просто знание ответов на вопросы. Это беседа, а уж о чем вы будете беседовать? — какая разница. Если общение не клеится тут, то скорее всего и команды не получится
Пара слов в защиту Эдисона.
1. Сколько миль от Нью-Йорка до Чикаго.
Поставим вопрос в наших реалиях. Сколько километров от Питера до Москвы? Для украинцев это звучит как от Киева до Львова или от Киева до Харькова?
Это же 2 главных города США в начале 20-го века, человек должен мотаться между ними и помнить сколько часов занимае поездка на поезде (или самолёте). Все газеты/журналы должны быть завалены рекламой поездов/самолётов/машин с этим расстоянием. Должен же этот человек знать хоть что-то про свою страну.
В конце концов Микрософтовский вопрос про то сколько шариков для пинг-понга влезет в Боинг.

2. Из чего делают нержавеющую сталь.
Эдисон инженер, изобретатель и бизнесмен. Не учёный как Эйнштейн. То есть помощник ему был нужен именно как бизнесмену. Не так уж трудно запомнить хром.
Не могу не воткнуть цитату.
«Елена Станиславовна, имевшая о плашках в три
восьмых дюйма такое же представление, какое имеет о
сельском хозяйстве слушательница хореографических курсов
имени Леонардо да Винчи, думающая, что творог добывается
из вареников...»

Соискатель должен обладать определённым кругозором. Любой человек должен. Даже для программиста позорно не знать сколько будет семью восемь или правило написания не с глаголами, даже если это можно посмотреть в справочнике. «Читаю со словарём» это
Для некоторых позиций нужно знать некоторые факты. Не уметь подсмотреть, а именно знать. Умение должно быть на кончиках пальцев, нельзя знать всё, но для работы вам будут нужны конкретные навыки.
И либо вы должны предъявить эти навыки/знания, либо компания должна быть готова вас учить.

Поставим вопрос в наших реалиях. Сколько километров от Питера до Москвы?


Собеседование на путеукладчика? Я знаю, сколько ехать, могу примерно прикинуть и сколько километров,— но только потому, что живу между. Километры… Спросите тоже. Совершенно бесполезная информация.
Собеседование на помощника бизнесмена.
Сколько ехать от Нью-Йорка до Чикаго? Какой примерно длинны будет линия электропередач (сколько будет стоит, какие будут потери в ней)?

Я, например, не хочу покупать тур.путёвку у человека который не знает географию. Если одна из обязанностей помощника будет организация поездок, то он должен знать расстояние между всеми крупными городами в США и Европе и отели в каждом городе.
Я в смятении. С одной стороны, логично, с другой — ведь тех, кто пишет с ошибками, не должны даже из школы выпускать, какие ещё собеседования? Надеюсь, «длинна» и пропущенная запятая были иронией с Вашей стороны.
Из школы выпускают по возрасту, а не по ошибкам. Конечно длина. А запятую не вижу :(

PS А программистов делающих ошибки в коде вообще надо расстреливать?
Запятая, вероятно, имеется в виду перед «который не знает»… А ещё предыдущий оратор не заметил пропущенного мягкого знака… А собеседования всё равно устные, в них «длинна» и запятая не видны, так что всё это большого значения не имеет, пока оно не в коде программы.
…Но это же не я, а Вы тут снобируете тех, кто не знает километраж от Москвы до Петербурга.
Хм, но ведь Эйнштейн знал, где добыть конкретные ответы — причём не просто «в книжках», а в каких конкретно. Т.е. можно предположить, что он их читал. Если не читал, то хотя бы знает об их существовании. Многие даже понятия не имеют, где искать ответы. Google? Хе, в нём ведь тоже надо уметь искать (:
Я бы не взял Эйнштейна к себе в помощники. Правда.
Эйнштейн точно бы нашёл ответы на эти вопросы, но это бы потребовало времени. Если ответы на эти вопросы нужны часто, то Эйнштейн терял бы время.

Я знаю где посмотреть перевод любого французского слова (франко-русский словарь), могу ли я писать, что знаю французский?
Если ответы на эти вопросы нужны часто, то Эйнштейн терял бы время.


Это что, он дурак по вашему или склеротик, что не сможет их запомнить с третьего раза?

Меня как-то на собеседовании спросили, чем отличается группа от кольца, и я каким-то чудом вспомнил и ответил. Это учитывая, что это было только на первом курсе (учась на 2ом году аспирантуры, то есть прошло без малого 8мь лет), а не занимаясь абстрактой алгеброй, вообще такие вещи редко приходится повторять. :) Всякое бывает.
Sign up to leave a comment.

Articles

Change theme settings