Какие вопросы надо задавать на собеседованиях?

Напишите, пожалуйста, какие вопросы вы считаете адекватными на собеседованиях на должности junior/mid/senior в вашей отрасли.

На данном форуме часто всплывали комменты в стиле «я синьор, а они меня про списки спрашивают».
Последний пример: www.developers.org.ua/...globallogic/comments/400
человека возмутило требование «писать код на бумаге».

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Отказываться писать код на собеседовании это отвратительно.
70% прособеседованых лично мной «синьор фронтенд девелоперов» не могут написать реверс массива in-place и (!!!) рекурсивную функцию для поиска n-го числа Фибоначчи.
как можно претендовать на зп 4к+ при этом не иметь базовых CS скиллов?

«синьор фронтенд девелоперов» не могут написать реверс массива in-place и (!!!) рекурсивную функцию для поиска n-го числа Фибоначчи
как можно претендовать на зп 4к+ при этом не иметь базовых CS скиллов?
А вот тут начинаются «махинации», собственно частично из-за которых и появилась эта тема.
С одной стороны, числа Фибоначчи или реверс массива — это не совсем показатель __необходимых__ фронтэндщику «CS скиллов».
С другой стороны, приведенные вами задачи — это __минимум__ «соображалки», не зависимо от уровня джун или синьор, такое можно придумать как написать (даже в стрессовой ситуации).
.
Если вас не затруднит, и это не секрет, то
Напишите, пожалуйста, какие вопросы вы считаете адекватными на собеседованиях на должности junior/mid/senior в вашей отрасли
С указанием отрасли.
реверс массива in-place
Я не сеньйор и спросить не стесняюсь, что имеется в виду здесь?

А фибоначчи я знаю, да:)

Тупо развернуть? Это же проще сортировки пузырьком, так совсем не интересно.

Да — и автор жалуется, что часть людей не могут такое написать.

Из той же серии: FizzBuzz и срач в темах «я Q мне N лет могу ли я стать программистом».
blog.codinghorror.com/...gramming-goats

И кто-то же им таки платит...эх....

Возможно я не прав, но я в упор не могу понять зачем в тестовые задания пихают числа Фибоначчи, ряды и т.п. Ок, Фибоначчи используются во всех книжах по любому ЯП в качестве примера написания рекурсивных ф-ций. Но на кой они нужны в реальных задачах? Почему нельзя просто дать задание: «Напишите рекурсивную ф-цию, которая считает от 10 до 1 и в конце выводит ’Рассчет окончен’»? Знания — те же, только не надо напрягать извилины, чтобы из закромов памяти достать информацию о том что же это за числа. А если человек еще и волнуется, то ему «откопать» эту инфу еще сложнее.

Есть еще один косяк, который частенько проскакивает даже у тимлидов/пм-ов, которые отсобеседовали не один десяток кандидатов. Порой они не могут корректно сформулировать задачу. Возьмем даже тот же

реверс массива in-place
. Вроде как и ок, но если задача так же звучит и на собеседовании то какого лешего в одном предложении используются слова из разных яхыков? Ладно был бы это какой-нибудь термин или общепринятое сокращение. Собеседуете на русском — спросите полностью на руском, не знаете как термин правильно перевести — спрашивайте на английском. Одно дело, когда вы общаетесь внутри коллектива и все привыкли уже к особенностям друг друга. Человек пришедший «извне» может вас сразу не понять, а вы это расцените как незнание.

Да запишите все вопросы на листочек, покажите его, например, HR, спросите все ли понятно (за исключением специфичных IT-терминов). И потом либо читайте с него, либо лучше дайте кандидату в руки. Тогда точно будет понятно причину почему кандидат не справился.

Приведу реальный случай из жизни. Телефонное интервью. Задача звучит следующим образом: «Как бы вы организовали БД для связки типа продукт-категория продукта». Вроде ничего сложного, но через 5 минут рассуждений и вопросов я узнал, что на самом деле хотели от меня услышать: «Опишите модель *реляционной* БД, таблицы, колноки и их типы, с учетом того, что это БД для интрнет магазина с поддержкой нескольких категорий одного товара с возможностью поиска и упорядочивания по категориям, набору категорий, названию товара и цене». Вот так на первый взгляд простое задание превратилось в «спроектируйте бд интернет-магазина по телефону». Благо собеседующий был хороший и с пониманием отвечал на мои вопросы и в итоге мы пришли к ответу, который устраивал нас обоих.

В таком случае более корректно выглядит тестовое задание, т.к. там все формализовано, но, я думаю, его мало. Имхо, в идеале это тестовое задание + собеседование, но не в формате «напишите мне рекурсивную фибоначю на листочке», а на темы типа: «Что интересного кандидат делал раншье, какие технологии использовал, может что-то читал интересного о новинках программного обеспечения, может приходилось ему сталкиваться с непрофильными задачами, например, разработчику надо было для оптимизации собрать на сервере RAID-0 из SSD»

PS: Я ни коем образом не оправдываю кандидатов котрые

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

поэтому лично у меня есть заготовка с вопросами которые я всегда задаю кандидату, c примерами использования функции и описанием чего от него хочется :)

если кандидату чтото не понятно — он всегда может спросить,
а если мы с кандидатом не найдем общий язык в формализации требований к простым функциям на 2 строчки — то о каком сотрудничестве можно говорить?

к тому же — это все стандартные вопросы.
если кандидат хоть капельку готовится к собеседованию, он наверное гуглит c++/javascript/php/java interview questions, и на первой же странице вы найдете все эти простые алгоритмические вопросы. и освежить голову какими либо алгоритмическими задачками хотя-бы перед интервью полезно. не говоря уже о том чтобы делать это регулярно.
а если кандидат спустя рукава подходит к интервью — как он будет относиться к работе?

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

Лично я звоню/пишу кандидату и говорю что я буду от него хотеть: писать код или говорить о политической ситуации в стране и т.д., уточняю когда бы ему было это удобно сделать и в каком виде.

тут вот у меня тоже был курьезный случай: звоню какому-то юному senior’у, говорю что хочу сделать предварительное собеседование, пописать код на collabedit и т.д., когда бы ему было удобно, он отвечает через 10 минут,
заходит в онлайн, пишу ему заголовок функции, прошу написать реализацию,
тут он мне говорит: «извините, мне живот болит, я не могу писать код, я вам перезвоню вечером». так и не перезвонил. ну и я не стал мучить его живот своим кодом. такие дела.

собственно по сабжу:
я считаю есть 4 основные категории скиллов которые можно и нужно проверять на собеседовании
1. основы так-сказать «Computer Sciense» — алгоритмические задачи, которые 23-х летние сениоры почему то так не любят
2. адекватность (в контексте предыдущего сообщения — если Вам чтото не понятно как минимум можно этот вопрос уточнить)
3. знание фреймворков и сопутствующих технологий
4. знание средств и методов разработки

я считаю что пункты 1-2 должны быть хороши у всех кандидатов не зависимо от их junior/middle/senior-ности

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

пункт 4: любой разработчик должен уметь пользоваться каким-либо редактором, уметь пользоваться системой контроля версий(хотя бы какой-либо), уметь дебажить, базово работать в консоли и т.д.
если senior разработчик не умеет помержить пару веток в гите. то это как минимум странно.

Какие вопросы надо задавать на собеседованиях?
Как дела?

Важно понимать что вам нужно, и на это проверять.
Но скажу сразу, я против написание кода на собеседование. Поясню почему:
1) У человека нет времени нормально подумать, а код который пишется сходу == 100% шлак
2) Человек не чувствует себя комфортно и если вы не ищети программиста который будет работать в горящем сдании, то это стоит учитывать
3) Показательный код нельзя написать за 5 мин, а не показательный ничего вам не скажет.
4) У каждого человека есть специфика работы, и резко перестроится никто не может. К примеру я знаю SQL, но не юзал его уже более 3 месяцев. Врядли я сходу смогу вспомнить все извороты.
5) Самое важное. Такая задача на собеседование зачастую говорит что вам нужна обезьянка умеющая быстро кодить, а если это не так, то человек сложит о вас неправельное впечатление.

Теперь что надо:
1) Программист должен уметь думать
2) Он должен уметь грамотно планировать свою работу
3) Он должен вписатся в коллектив
4) Он должен быть заинтересован в своей работе и видеть в ней перспективу лично для себя
5) Как и любая другая творческая личность он должен быть материально защищен работая на вас

Некоторые из этого есть не только его задача но и ваша. Обьяснение простое вы команда и должны решать проблемы друг друга.
Все эти моменты проверяются обычными вопросами без строчки кода. Задачи на ум должны быть исключительно логические не привязанные к подсчетам, а показывающие умение мыслить нестандартно, здраво и уметь решать любые задача(а не толкьо программерские)

Если человек это пройдет, то поздравляю вас вы нашли хорошего работника, друга и компаньена. Во всех инных случаях учитывая статистику все заканчивается плачевно.

Я бы порекомендовал, как источник вдохновения для вопросов, следующие книги:
www.amazon.com/...01244077&sr=8-4

www.amazon.com/...1244077&sr=8-15

Сам использую подобные задачки, правда созданные собственноручно, ну и естественно прошу писать код (точнее даже сойдет и псевдокод) на бумажке.

Интересно получается:
Все (ну или довольно много людей) против написания кода «на бумажке», но никто не может привести задачу для собеседования которую нельзя было бы решить не «на бумажке»
Из вменяемых альтернатив прозвучало только «попросить показать уже готовый код» — довольно классный вариант, но имеет пару недостатков:
1) Не всегда это возможно

2) Человек может показать не свой код (один мой знакомый так и сделал)

А тестовые задания уже не в моде?

Поддерживаю, даешь человеку комп, даешь задание, садишься рядом и смотришь как он его пишет

100%! Заодно проверяешь как он реагрует на дыхание в спину.

Именно! На работе достаточно часты такие случаи, когда придется делать что-то при ком-то

Именно! На работе достаточно часты такие случаи, когда придется делать что-то при ком-то
...а если ему не понравится как вы это делаешь, то вас уволят?
Отличие принципиальное, на работе — это нормальная обстановка, скорее всего со знакомыми людьми. Собеседование — стрессовая ситуация (особенно если человек реально хочет получить эту работу, а не просто пришел посмотреть «че и где»).
И в этом плане за компом или на листике мало отличается.
Возвращаясь к теме топика, приведите пример (лучше реально опробованный) таких заданий.

Вы хотите конкретный пример, для этого я прошу от вас конкретные входные данные :)

Вы хотите конкретный пример, для этого я прошу от вас конкретные входные данные :)
приведите пример (лучше реально опробованный) таких заданий.
Меня интересует ваш опыт (где-то про это вся тема), я так понимаю, что вы часто практикуете программирование с соискателем за одним компом.
я так понимаю, что вы часто практикуете программирование с соискателем за одним компом.
Именно)
А тестовые задания уже не в моде?
Примеры в студию! Если примеры вменяемых задачек я еще встречал, то вот примеры вменяемых ДЗ пока ни разу.

То, что наиболее часто приходится решать на проекте

То, что наиболее часто приходится решать на проекте
Классный ответ, часто встречаемый, по степени бесполезности лишь немногим уступает такому: «Подходящие» :)

1. Создаем список наиболее часто встречаемых задач на проекте (напимер: сортировка данных, многопоточность, работа с БД, работа с REST-сервисами и т.д.).
2. Создаем задание на основе списка (пример: Написать приложение которое отображает список <объектов> с <такогог-то (напр., twitter, github)> веб-срвиса. Полученные данные должны быть записаны в БД. На основе данных из БД отображаться в <определенной последовательности, согласно определенному признаку(ам)> и отображены так-то). В таком духе, в общем.
3. Дать возможность кандидату выполнить задание в удобной для него обстановке (читай: дома).
4. Смотрите код, оценивате его качество (не стиль!): читабельность, подходы, структуризация и т.д.
5. Если в п. 4 Вас все устраивает — уже на интервью просите рассказать о ходе выполнения, причинах применения того или иного решения, использования тех или иных фреймворов. Параллельно можно получить инфу о базовых знаниях кандидата («Здесь Вы используете <такую-то> структуру данных. Почему, не <такую-то>?»).
Вот как-то так...

такогог-то (напр., twitter, github)
записаны в БД
3. Дать возможность кандидату выполнить задание в удобной для него обстановке (читай: дома).
Итого, вы дали возможность кандидату потратить свое время на изучение АПИ, которое ему не надо, а так же возможность установить на __домашнюю__ машину СУБД. Кстати, далеко не факт что у него установлено даже ИДЕ (на домашней машине).
4. Смотрите код, оценивате его качество (не стиль!): читабельность, подходы, структуризация и т.д.
Допустим что человек сам написал код. Почему вы решили (что дает вам гарантию) что то как он писал этот код будет похоже на то что он будет делать на реальном проекте?
уже на интервью просите рассказать о ходе выполнения, причинах применения того или иного решения, использования тех или иных фреймворов. Параллельно можно получить инфу о базовых знаниях кандидата
А без ДЗ это сделать нельзя?
Итого, вы потратили впустую 1-2 вечера кандидата.
.
ДЗ эффективны в основном для просеивания потока кандидатов. Реально проверить то как человек будет работать, вы сможете только в рабочей ситуации, то есть на испытательном сроке.
вы дали возможность кандидату потратить свое время на изучение АПИ, которое ему не надо
Не надо — не давайте. Это просто пример.
то как он писал этот код будет похоже на то что он будет делать на реальном проекте
Вы пишите код дома для себя? Если да — неужели подходы к одним и тем же задачам дома и на проекте сильно отличаются? Если да — что-то здесь не так.
установить на __домашнюю__ машину СУБД
Если Вы считаете, что это избыточно — нет проблем. Я просто привел пример. Не обязательно делать все «буква в букву».
не факт что у него установлено даже ИДЕ (на домашней машине)
Скорее всего установлено, так как часто приходится что-то искать, пробовать и смотреть для себя дома. А если же нет — установить не проблема.
А без ДЗ это сделать нельзя?
Может и можно. Я предложил Вам один из подходов, который достаточно эффективен.
Реально проверить то как человек будет работать, вы сможете только в рабочей ситуации
Тогда к черту все вопросы — каждого кандидата на испыталку )))))))))))))))))))))))))))))))))))))))))
ДЗ эффективны в основном для просеивания потока кандидатов
И для этого тоже.

Преимущества подхода «ДЗ + последующее его обсуждение на интервью» заключается в том, что Вы видите как человек ориентируется в конкретных практических задачах. А ответы на вопросы типа «Чем указатель от ссылки отичается?» можно и вызубрить.

Если уж так сильно не нравится ДЗ можно попробовать расспросить о предыдущих/любимых проектах/задачах — такое тоже практикуют.

Если да — неужели подходы к одним и тем же задачам дома и на проекте сильно отличаются? Если да — что-то здесь не так.
«Не так» тут предположение. Почему вы решили что задачи дома и в реальном проекте хоть немного похожи? Например, на работе РЕСТ-сервисы с БД, дома небольшие скрипиты (для которых и вина хватит).
А если же нет — установить не проблема.
Еще одно утверждение без обоснования. Такой задачей вы отседаете людей для которых это проблема, ибо они не хотят ставить «какую-то муть» себе на комп.
Тогда к черту все вопросы — каждого кандидата на испыталку )))))))))))))))))))))))))))))))))))))))))
Вы привели это как пример абсурда, судя по смайликам. Так а почему это абсурдно? Потому что ИС требует больше ресурсов чем собеседование. Так вот новость в том что ДЗ так же требует больше ресурсов и при этом не отменяет проведение собеседования.
А ответы на вопросы типа «Чем указатель от ссылки отичается?» можно и вызубрить.
Немного примера из ВУЗа:
От вы ни разу даже не видели как сдают «намученую лабу» (чужую, сделанную другими людьми)? Рассказывать о «практику» значительно проще чем отвечать по теории, хотя бы потому что у вас поле знаний для заучивания значительно меньше. А если потом задавать вопросы по теории (вглубь), то пользы от решения практической задачи «на дому» нет, всю базу которую вы хотели спросить опираясь на ДЗ, вы можете спросить и так.
То есть если убрать в ваших примерах ДЗ, то что измениться? Какую до инку оно дает интервьюеру?
Я предложил Вам один из подходов, который достаточно эффективен.
А я вам пытаюсь объяснить почему это пример работает только для просеивания потока, например с джуно-трейни или когда Гугл-Шмугл делает ивент в стране 3-го мира.

ИМХО, срач детектед.

Почему вы решили что задачи дома и в реальном проекте хоть немного похожи
Я так не писал.
ни разу даже не видели как сдают «намученую лабу»
Видел. Не путайте грешное с праведным, пожалуйста.
если убрать в ваших примерах ДЗ, то что измениться?
В Вашем случае — ничего.
Если где-то и есть универсальный опросник по которому можно с 99% вероятностью определить уровень кандидата, то я о нем не знаю.
Удачи!
Почему вы решили что задачи дома и в реальном проекте хоть немного похожи
Я так не писал.
Рылли:
неужели подходы к __одним и тем же задачам__ дома и на проекте сильно отличаются
.
Видел. Не путайте грешное с праведным, пожалуйста.
И где грешное, а где праведное? То на что вы отвечали и было таким же примеров: Человеку сделали ДЗ, он его «защитил». Но поскольку собеседование свелось к теме ДЗ, то он его прошел. А уволили его через 2 месяца, года убедились в его уровне.
.
Если где-то и есть универсальный опросник по которому можно с 99% вероятностью определить уровень кандидата
Цель этой темы была набрать примеров на основании которых любой человек сможет сформировать/улучшить свои наборы вопросов.
к __одним и тем же задачам__ дома
Одни и те же задачи в рамках одной технологии(ий) решаются с помощью одних и тех же подходов. Хоть в офисе, хоть дома, хоть на Марсе.
И где грешное, а где праведное?
Вопрос риторический.
Человеку сделали ДЗ, он его «защитил». Но поскольку собеседование свелось к теме ДЗ, то он его прошел
От такого рода ситуаций не застрахован никто. Даже с самым продвинутым набором вопросов. Для того и испыталки придумали.
Цель этой темы была набрать примеров
Ловите:
1. Принципы ООП (наследование, полиморфизм и т.д.).
2. Паттерны ООП (Например, GOF).
3. Ссылки и указатели.
Далее уже идет привязка к языку/технологии.
Помогло?
Одни и те же задачи в рамках одной технологии(ий) решаются с помощью одних и тех же подходов. Хоть в офисе, хоть дома, хоть на Марсе.
От именно __все__ должно быть, одно и то же. Помимо технологии (допустим что дома человек пишет портреты под веб-сферу с Оракулом в качестве БД), долго совпадать, например, длительность проекта. И те или иные подходы могут быть не эффективны в коротких проектах, но при этом обязательны в долгоживущих. Например, ТДД может быть бесполезной на «КРУД однодневках».
Ловите:
1. Принципы ООП (наследование, полиморфизм и т.д.).
2. Паттерны ООП (Например, GOF).
3. Ссылки и указатели.
Далее уже идет привязка к языку/технологии.
Помогло?
От с этого и надо было начинать. Я то решил что вы некробампнули тему ибо вам было что сказать, а оказалось очередной джун со своим очень важным мнением.
Человек может показать не свой код (один мой знакомый так и сделал)
Так можна по коду почати питати. Для чого цей клас, що робить цей метод, д і т.д. Тут точно буде видно чий це код :)
Человек может показать не свой код (один мой знакомый так и сделал)
А что мешает расспросить об этом коде?
А что мешает расспросить об этом коде?
А тогда зачем человек тратил время на выполнение задания?
Суть в том что если вы начинаете спрашивать по коду хорошо, то ДЗ — пустая трата времени.
если вы начинаете спрашивать по коду хорошо, то ДЗ — пустая трата времени
Сомнительное утверждение
Сомнительное утверждение
Так скажите, наконец, какая от него польза? Какую инфу нельзя получить без ДЗ?
История о том, как искали сеньора и джуниора — job-interview.ru/...ticles/post/290 .
В принципе, тоже считаю, что вопросы должны быть простыми, но которые сразу показывают знаком с этой темой человек или нет.

Ну и писать код на бумаге тоже возмутил бы.

Ну и писать код на бумаге тоже возмутил бы.

Далее из статьи:
"выбрать все input’ы с атрибутом id="myID", которые находятся внутри <div class="myClass">"
«Необходимо выбрать города, в которых проживает не менее n пользователей»
«Есть 2 таблицы ... Необходимо вывести все email’ы пользователей, а также их логины.»
Разве это не подразумевает написания кода? Или бля таких задач необходима дев-машина? Это легко можна сделать на бумажке, или я не прав?
А учитывая что берут на работу не теоретика, а практика, то эти задачи можно расширить, например для SQL-задач добавить код который будет распечатывать результаты (посмотреть насколько «обобщенным будет этот код»), что таки легко делается даже на бумажке.

Для jQuery-задач, например, написать спойлер (див который скривается/показывается по клику на «+») и при этом сказать что их ровно 1 на странице или много и посмотреть как человек это сделает, какие селекторы бодет использовать, это тоже легко делается «на бумажке»

Говоря «код на бумажке», я имею ввиду не такие простые задачи все-таки.
Я согласен, для описанных вами задач подойдет ответ и на листке бумаги.
Меня просили как-то на собеседовании написать функцию, которой на вход подается текст, на выходе должен быть текст, в котором слова, начинающиеся на что-то, должны быть на выходе перевернутыми. Постановку задачи говорю по памяти, может еще какие условия там были.
Я против написания на бумаге вот таких задач.

Меня просили как-то на собеседовании написать функцию, которой на вход подается текст, на выходе должен быть текст, в котором слова, начинающиеся на что-то, должны быть на выходе перевернутыми.

Мда... Только такую задачу вас могли и на компе попросить сделать.

«На бумажке» значит без средств разработки: на листке бумаги, на доске, в простом тестовом редакторе (если удаленно).

Именно так. Был бы комп, можно воспользоваться документацией, есть возможность потестить, что получается.

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

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

А по моему такая задача требует хотя бы минимальной отладки и скорее всего работать не будет с первого раза.

Я на собеседовании эту задачу решил, но решил криво, т.к. забыл название одной функции и пришлось как-то без нее выкручиваться.

На собеседованиях обычно мало кого интересует правильность решения задачи (если она не совсем уж базового уровня),

обыно белее интересен ход мыслей.

Что отлаживать? У бумаги и чернил нет компилятора. Да и у собеседующего в голове его тоже нет. Поймите, проверяется умение человека решить задачу. Подход SMART и Getting things done пока никого не подводил.

И какая дополнительная функция нужна для решения задачи?

И при наличии компа здача «перевернуть каждое 5 слово которое длинне 17 символов» станет адекватнее?

Или я таки не понимаю о чем вы?

Про адекватность задачи я сейчас вообще не говорю. Просто считаю, что она не предназначена для написания кода на бумаге.

>> Напишите собственную реализацию ArrayList [на бумаге]
Реальный случай :)

+1

Меня тоже возмущало это требование

Требование «писать код на бумаге» — не возмущает. Можно потратить несколько дней и натренироваться писать код на бумаге. Но есть ли смысл тратить на это время??? Если можно найти работу в другой фирме, за такую же зарплату, и где не требуют написания кода на бумаге или на доске? Кстати за рубежем обычно предупреждают, типа: «На собеседовании необходимо уметь писать код на бумаге/ на доске».

> Можно потратить несколько дней и натренироваться писать код на бумаге.

Простите, абсолютно не понимаю чему тут недо тренироваться, особенно если учитывать что на собеседованиях обычно дают задачи «до 20 строк кода без использования заковыристых методов класса из глубин стандартных либ» (раньше давали). Если это не так, то могли бы вы привести пример задачи которую не комфортно написать на бумажке.

> Но есть ли смысл тратить на это время??? Если можно найти работу в другой фирме, за такую же зарплату, и где не требуют написания кода на бумаге или на доске?

А можно найти работу где вапше не требуют писать код;)

Наверное вы думаете, что ваша фирма — единственная в Киеве, в которой пишут код.:)

Кризис закончился. Появилось море вакансий. Зачем ходить в фирмы, у которых — жесткие собеседования, если можно найти другую фирму, в которой задают нормальные вопросы. Зачем учить вопросы, знание которых никогда в жизни не пригодится?

Кризис закончился. Появилось море вакансий. Зачем ходить в фирмы, у которых — жесткие собеседования, если можно найти другую фирму

Кризис дело такое сегодня нет, а завтро есть, а кушать хочетсо всегда.

Кстати кризис таки закончился, ибо все мои знакомые «попрыгунчики» нашли работу.

в которой задают нормальные вопросы.

Вот вопрос в том: Какие это «нормальные вопросы»?

Возвращаясь к «тестированию на бумажке»: Чем отличается «реверс строки» (или другая алгоритмическая задачка, средней сложности) при тестировании «на бумажке» или «в навороченной ИДЕ»?

В ИДЕ нет необходимости черкать неправильное. Если у программиста такой вид мышления, что с начала до конца реализовать задачу сходу он не сможет — код на бумаге будет выглядеть криво.
Среда, в принципе, привычней чем бумага. Не все практикуют кодить на бумаге хоть чуток.
В ИДЕ можно сразу и проверить правильность решения, не напрягая, особо, мозги вычислениями.
Ну, и наверное, чем большие у людей вызывают трудности решения таких задач — тем меньше они хотят писать код на бумаге.

А по сути вопроса, то конечно же, реверс не будет отличаться ничем, просто условия для его написания на бумаге «типа» хуже.

В ИДЕ можно сразу и проверить правильность решения, не напрягая, особо, мозги вычислениями.

для цього питання і задають на бумазі, щоб перевірити як людина може напрягти ті сасі мізки

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

і знову, якщо в людини викликає труднощі написання досить простого алгоритму, потрібно задуматись наскільки ця людина може вирішувати поставлені задачі

“і знову, якщо в людини викликає труднощі написання досить простого алгоритму, потрібно задуматись наскільки ця людина може вирішувати поставлені задачі”

Не на всех собеседованиях задания простые — уровня реверса строки. И не все задания приятно решать в голове, без предварительной реализации/проверки/тестов. Да и умение эффективно пользоваться средой разработки/окружением и т.д. как ни странно тоже не у всех получается.

И совсем даже не факт, что человек умеющий, в голове, создать и реализовать алгоритм полностью, будет работать эффективней человека “исповедующего” другой подход и программированию.

Опять же не факт, что человек который не напишет на бумаге решение, но реализует задачу через тесты/дебаг и другие подходы будет хуже в реальной работе. Да и работа разная есть. Если люди которые не могут реализовать реверс на бумаге, но вполне нормально работают — это что-то да значит.

Не на всех собеседованиях задания простые — уровня реверса строки.

підтримую, це вже проблема інтервьювера, тести на бумазі актуальні лише для простих алгоритмічних задач, імхо.

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

перевіряти вміння дебага і ресерча баги через завадання на бумазі ніхто не буде, це абсурдно.

я мав на увазі, що написання коду на бумазі яктуально тільки для задач які зможуть показати логічне мислення, вміння думати і аж ніяк не вміння користуватись гуглом, дебаг тулзами, знання функцій і їх параметрів з тої чи іншої ліби і т.д.

Правильно. А теперь прикиньте сколько, в процентом соотношении, времени тратиться на думанье(придумывание и реализация алгоритмов, усиленный брейншторминг и т.д.) и на «банальное» пользование гуглом, документацией, либами и прочими вещами далекими от алгоритмов как таковых.

Что-то мне подсказывает, что чем выше абстракция разработки тем процент думанья может уменьшаться. Кучи ПХПшников не умеющие реализовать этот реверс просто ужасают, бо им и не надо это в работе. При этом я не знаю ниодного низкоуровневого писаку(асм, низкоуровневый си и т.д.) который бы такое не осилил, т.к. им это очень даже надо в работе.

Кучи ПХПшников не умеющие реализовать этот реверс просто ужасают, бо им и не надо это в работе.

И поэтому реверс строки в их случае проверяет «соображалку», умение составить не сложный алгоритм без лазення в гугл и 2 дневного чтения форумов.

Я не утверждаю что такой способ едино верный, понятно что тестирование «на бумажке» не раскроет всех знаний и умений человека, но по большому счету для этого испытательный срок, задача собеседования убедится что на человека надо тратить ресурсы компании в течении 2 месяцев.

Я конечно далек от собеседования ПХПпистов.
Но почему-то мне кажется, что проверка человека на умение решать «стандарнтые» для его среды задачи, «нестандартными» задачами и тестами не лучший вариант.
Конечно можно отобрать смышленых в конкретно таком направлении ребят, но где гарантия, хоть какая-то, что непрошедшие отбор по такому критерию принесут(или принесли бы) пользы компании меньше?

Тем более, чем больше компания, тем меньшим винтиком является разработчик. И уж найти работу под программиста можно.

Конечно можно отобрать смышленых в конкретно таком направлении ребят, но где гарантия, хоть какая-то, что непрошедшие отбор по такому критерию принесут(или принесли бы) пользы компании меньше?

Цель отбора — отбросить тех кто не подходит. Если отсеются стоящие кандидаты — это очень плохо, но такова жизнь.

Возвращаемся к основному вопросу темы: Предложите что-то эффективнее (в том числе и с экономической точки зрения) чем тестирование «на бумажке».

Возвращаемся к основному вопросу темы: Предложите что-то эффективнее (в том числе и с экономической точки зрения) чем тестирование «на бумажке».

А как это делается в США и в других странах? Вы уверены, что «на бумажке»?

Если бы я обладал полной и объективной информацией я бы не спрашивал :)

Из 3 случаев которые искали работу (устраивались на работу) на западе все писали «на бумажке»: иногда это была доска иногда бумага.
Уточнение 1 из 3 системный программист, 2 остальных веб-девы (РоР).

Иногда, в дополнение, просили показать код и работающий проект, если это возможно.

Нет. В США редко просят писать на бумаге. Примерно 1 случай из 100. Вероятность — 1...5 %

Нет.

Интересно, Вы оспариваете тот факт что 3 человека о которых вы, скорее всего ничего не знаете, проходили несколько собеседований «на бумажке»?

В США редко просят писать на бумаге. Примерно 1 случай из 100.

А теперь исходный вопрос:

В остальных 99 случаях как проводят собеседования?

Как эффективнее провести его, в условиях небольшой компании? Или большой, это лично мне менее интересно?

1) Согласно теории вероятности, 3 человека — это бесконечно малая величина, чтобы делать выводы. У меня — более достоверные источники информации о собеседованиях в других странах.
2) В остальных случаях — по разному. Могу рассказать, позже.

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

У меня — более достоверные источники информации о собеседованиях в других странах.

Я и не говорил что моя инфа объективна.

Могу рассказать, позже.

Вот это я и прошу с «9 февраля 2011 17:06» :)

А США законодатель мод что-ли в этом вопросе? И следовать MS и Ко показатель качества отбора? Если и ссылаться на других, то, имхо, на маленькие конторы, где разработчик ценный персонаж и к его выбору надо подходить скурпулезно и тщательно(что бы не попасть на сроки, бабки, жизнь компании в целом), а не конвеерно как в больших компаниях.

Лично я бы разделил поиск кандидатов на 2 типа:
1. Поиск кандидата под конкретную должность в конкретный проект.

2. Поиск кандидата и определение его сильных, слабых сторон, и поиск ему, конкретному, места на фирме где бы его сильные стороны проявлялись, а слабые были незаметны.

В 1ом случае заменить тестовое безсмысленное(относительно практической реализации) задание на бумажке на мини-таск в ИДЕ из реальной или около-реальной системы, над которой кандидат будет работать, если, конечно, успешно закончит собеседование. Времени уйдет, пускай час, а не 15-20 минут как на реверс(или сколько там в среднем?). Но результат покажет больше чем проверка соображалки.

Во 2ом случае все намного сложней и дольше — долгий анализ резюме, много разговоров с кандидатом, «думанье» относительно каждого кандидата в отдельности. И это конечно же не вариант для компаний занимающихся конвеером при подборе кадров, так как нужен индивидуальный подход к каждому кандидату со стороны технических специалистов, а не только HR.

Писать алгоритмы на бумажке имхо действительно тупо, нужно писать на доске, тогда интервьюирующий сможет следить за полетом мысли человека, и обсуждать по ходу детали.

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

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

По-моему это не причины для отмены теста на бумажке и перехода на доску ИДЕ, т.к. все делается на бумажке с таким же результатом.

В парном программировании никто никому в затылок не дышит.

Парное программирование и собеседование — это 2 принципиально разных ситуации.

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

С адекватным, незнакомым, специалистом мне было бы приятней и интересней накидать что-нить за часок, чем писать реверс на бумажке.

Т.е. устроить с кандидатом парное программирование на 1 час что-то не позволяет?

А код будет кто писать кандидат или интервьюер?

Не вижу большой проблемы, если честно, в этом.

А много ли у вас простаивает свободных машин на которых будет комфортно работать (если да, пора увольнять манагеров)?
А если человек привык работать и идее и на то что бы освоиться в эклипсе ему надо пару дней?

А к клавиатуре привыкать не надо? Или надо на собеседование свою приносить?

А теперь вопрос:
Что такого можно напрограммировать за 1 час чего нельзя «написать на бумажке»?

Кстати, пример задачи можете привести, хоть для своей области?

Кандидат конечно, интервьюер будет «следить за полетом мысли человека, и обсуждать по ходу детали», а при необходимости помогать.

«А много ли у вас простаивает свободных машин на которых будет комфортно работать (если да, пора увольнять манагеров)?»
Наверное мы живем в разных мирах.
По-моему сейчас нормальный ПК стоит 20% от месячной ЗП сеньйора в Киеве. Это ли проблема для ИТ конторы?
Да и вообще, пока простаивает — в кластер другому прогеру. Нужна — вот собеседуйтесь.

Если в офисе оборудования на, например, 50 000$, которое 98% времени простаивает тоже увольнять манагера только из-за того что оно простаивает столько-то? Дело ведь не в простое, а необходимости чего-либо.

«А если человек привык работать и идее и на то что бы освоиться в эклипсе ему надо пару дней?»

Эклипс и идея на одной машине это проблема? Ну поставьте все жаво ИДЕ охапкой сразу, нашли проблему...

«А к клавиатуре привыкать не надо? Или надо на собеседование свою приносить?»

Сделайте выборку по своему офису какие типы клавиатур используются. Что-то мне подсказывает их будет совсем даже не 10 видов, что-бы делать из этого проблему. Да и вообще, стандарной клавиатуры должно быть достаточно.

«Что такого можно напрограммировать за 1 час чего нельзя „написать на бумажке“?

Кстати, пример задачи можете привести, хоть для своей области?»

На бумажке нельзя за час сделать того, что требует каких-то дополнительных областей знаний.
Вообще правильная задача в этом контексте и есть ключ к успеху такого задания.
Если из области веба, то пусть будет задача в стиле:
написать бизнес логику работы с корзиной в инет-магазине(реализовать созданную заглушку):
1. добавление товаров.
2. сохранение корзины в персистентом виде.
АПИ к ОРМ такой-то.
АПИ к слою отображения такой-то.
Допонительные возможности такие-то.

Если кода нужно строк 50-80 то вполне реально, имхо.

Если из своей области, то пусть будет следующее:
Модифицировать обработку протокола, что-бы исключить возможную потерю сообщений, если дано(пускай выполнение сообщений это будет рендеринг текста что-ли:)):
Дано:
1. Обработчик прерывания на получение сообщения, который производит выполнение сообщения.

2. Бесконечный цикл программы который ничего не делает.

Время выполнения сообщения: 5мс
Время обработки прерывания без выполнения сообщения: 0мс
Минимальное время между сообщениями: 1мс

Макс количество сообщений в секунду: 50

Ну это задания, так набросаны, естественно переписать их нужно в такой вид, что-бы кандидат сразу начал думать о реализации задания и проблем около реализации, а не тратил час на вникание в суть дела.

По-моему сейчас нормальный ПК стоит 20% от месячной ЗП сеньйора в Киеве. Это ли проблема для ИТ конторы?

Комп который будет использоваться несколько раз в год, а остальное время простаивать — это проблема.

Да и вообще, пока простаивает — в кластер другому прогеру. Нужна — вот собеседуйтесь.

Угу. И пофик шо у этого дева там выполняется какая-то важная задача, надо ведь собеседование проводить.

А про то что он там может хранить какие-то данные конторы и любой Вася пришедший на собеседование их увидит — это не проблема.

Эклипс и идея на одной машине это проблема? Ну поставьте все жаво ИДЕ охапкой сразу, нашли проблему...

Снова же платим бабло за ИДЕ, которые будут использоваться пару раз в год.

Да и вообще, стандарной клавиатуры должно быть достаточно.

Сужу строго по себе: мне сложно набирать код на «чужой» клавиатуре, стиль набора превращается в «падающего орла» (двухпальцевый) :)

"Комп который будет использоваться несколько раз в год, а остальное время простаивать — это проблема."<p>Собеседований у больших компаний по многу в день. Да и вообще — комп это не разработчик. Простаивающая железяка это не простаиващиюй без работы инженер. Вы же не делаете из офиса интернет-кафе, когда рабочий день заканчивается, только для того что бы увеличить нагрузку на железо?</p>
"Угу. И пофик шо у этого дева там выполняется какая-то важная задача, надо ведь собеседование проводить.«<p>А в чем проблема составить план доступности «той» машины в определенные дни? </p>
<p>"А про то что он там может хранить какие-то данные конторы и любой Вася пришедший на собеседование их увидит — это не проблема."</p>
<p>Я не говорю про использовании этой машины как основной для разработки. По сути только вычислительные мощности использовать из этой машины и не хранить ничего — не проблема на сегодняшний день.</p>
<p>"Снова же платим бабло за ИДЕ, которые будут использоваться пару раз в год."</p>
<p>Не хотите платить — можете ограничиться только опенсорсными. Тестовые задания не требуют глубоких знаний эклипса, если человек привык к идее.Тем более я не сильно много людей знаю, которые пишут в идее, не зная совсем эклипса.</p>
«Да и вообще, стандарной клавиатуры должно быть достаточно.<br>

Сужу строго по себе: мне сложно набирать код на «чужой» клавиатуре, стиль набора превращается в «падающего орла» (двухпальцевый) :)«<p>Только потому что она чужая? Может опишете чем отличается стандартная от вашей? Каждому человеку удобней на своей, но я, по себе судя, не вижу проблемы накидать пару строк кода «придя» на чужую машину .</p>

Собеседований у больших компаний по многу в день.

Ну не всем же работать в глобале или епаме :)

А в чем проблема составить план доступности «той» машины в определенные дни?

Проблема не в самой машине, а в админ расходах на нее.

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

А вот тут проблемы у больших компаний. Любой аудит безопасности, за такие фокусы скинет существенно балов.

Может опишете чем отличается стандартная от вашей?

КапсЛок не выдран. Делит/Интсерт не в том месте, у некоторых. У клавиш более/менее тугой ход, у некоторых более короткий/длинный. И еще куча всяких мелочей, которые в «мышечной памяти» и к которым надо привыкать хоть пару часов.

Если компания маленькая(например текучка работников 1-2 человека в год) то либо гостевой аккаунт на одной из машин, либо «новая» машина которая будет 363 дня в году выполнять парралельную работу.

А какие админ расходы? Маленькие компании занимаются всем и сразу и им нужно все пару десятков коммерческих ИДЕ на все мейнстрим направления? Занимаетесь жавой — ну купите лицензию на идею.
Занимаетесь дотнетом — купите лицезнию ВС.

Я уже молчу про эвалуэйшен на ограничение по размеру, а не по времени, что вообще бесплатно.

«А вот тут проблемы у больших компаний. Любой аудит безопасности, за такие фокусы скинет существенно балов.»

Не понял смысла этой фразы. Можете обьяснить поподробней?

«КапсЛок не выдран. Делит/Интсерт не в том месте, у некоторых. У клавиш более/менее тугой ход, у некоторых более короткий/длинный. И еще куча всяких мелочей, которые в „мышечной памяти“ и к которым надо привыкать хоть пару часов.»

Стандартная, полноразмерная, с уменьшеным или стандартным ходом клавиш будет достаточно.

Хотя, я заметил, что многие программисты пошли балуваные, как девочки какие-то. Пока выполнишь все капризы — постареешь :)

А какие админ расходы?

Машина и система на ней должны быть работоспособны, там надо хоть иногда обновлять софт, проверять что железка не деградировала (у меня был случай: комп не включали год, после включения задымил блок питания).

Занимаетесь жавой — ну купите лицензию на идею.

А если разработка ведется поголовно в эклипсе? Покупать лицензию на идею, джБилдер чисто для собеседования?

Не понял смысла этой фразы. Можете обьяснить поподробней?

При аудите безопасности разработки не допустимо что бы данные пользователей или служебная инфа попали к людям без соответствующего уровня доступа (например человек на собеседовании). И вам придется очень долго доказывать что ему сделали «гостевой доступ» и скорее всего не докажете.

Хотя, я заметил, что многие программисты пошли балуваные, как девочки какие-то. Пока выполнишь все капризы — постареешь :)

На работу можно и со своей клавой прийти или за время испытательного срока привыкнуть к выданной.

«„А какие админ расходы? “

Машина и система на ней должны быть работоспособны, там надо хоть иногда обновлять софт, проверять что железка не деградировала (у меня был случай: комп не включали год, после включения задымил блок питания).»

Если год простоит машина без обновления ПО, то тестовое задание нельзя будет сделать? Нескомпилится потому что скажет «ой старая у вас ждк стоит, ну вас...»

Опять же, если она будет парралельно использоваться — будет на ней все свеженькое и актуальное.

Обновление всей системы в одну команду тоже отменили?

«А если разработка ведется поголовно в эклипсе? Покупать лицензию на идею, джБилдер чисто для собеседования?»

Тут уже зависит от того, будет ли такой человек продолжать писать в идее или эклипсе.
Если заставите переходить на эклипс — то пусть и пишет в нем.

А ЖБилдер сильно от эклипса отличается? Что-бы кандидат не осилил задачу в эклипсе...

«При аудите безопасности разработки не допустимо что бы данные пользователей или служебная инфа попали к людям без соответствующего уровня доступа (например человек на собеседовании). И вам придется очень долго доказывать что ему сделали „гостевой доступ“ и скорее всего не докажете.»

С чего вы взяли кандидат сможет получить что-то большее чем гостевой доступ?

У вас есть публичные сервера? Вы имеете возможность получить доступ к служебной информации не только из офиса? Безопасность этих вещей как-то же доказывается?

«На работу можно и со своей клавой прийти или за время испытательного срока привыкнуть к выданной.»

Ну вот дайте кандидату выбор решить, что будет лучше. Никто ж не знает, все равно ему относительно клавиатуры, или он согласиться делать тест только на какой-нибуть Logitech G19 Keyboard.

Наше обсуждение похоже не на «какие вопросы надо задавать на собеседованиях?», а на «как можно ничего не делать(или делать минимум телодвижений) и идеально отбирать кандидатов?»

Обновление всей системы в одну команду тоже отменили?

И всего ПО. Это нормально только в линухах, если все из репов ставилось.

А ЖБилдер сильно от эклипса отличается? Что-бы кандидат не осилил задачу в эклипсе...

К новой среде необходимо привыкнуть, а привыкать за 1 час собеседование, это лишний напряг.

Безопасность этих вещей как-то же доказывается?

Да, если это серьезный аудит.

или он согласиться делать тест только на какой-нибуть Logitech G19 Keyboard.

Суть не в том что кандидат сознательно говорит «не буду кодить за этой клавой», а в том что он, по привычке, вместо таба попадает на КапсЛок, или вместо делита на слип (и вырубает комп :))

«И всего ПО. Это нормально только в линухах, если все из репов ставилось.»
А мы говорим тут о винде что-ли?

Единственное в чем кандидату надо будет поработать это ИДЕ. Любая обновляется одним кликом и парой минут ожиданий.

«„А ЖБилдер сильно от эклипса отличается? Что-бы кандидат не осилил задачу в эклипсе...“

К новой среде необходимо привыкнуть, а привыкать за 1 час собеседование, это лишний напряг.»

А на собеседование придти не напряг и рот открывать отвечая на вопросы?

Какие именно функции ИДЕ нужны для реализации задания? кнопки и быстрый вызов сборки, дебага и хоткеи на конктекстную помощь и автодополнение кода? Да, такое ощущение что мы тут обсуждаем переход не «жава идея» на «жава эклипс», а какой-нить «IAR асм» на «нетбинс пхп», где действительно надо время что-бы «аклиматизироваться».

«Да, если это серьезный аудит.»

Таким же образом и докажете что гостевой доступ в нормальной ОС не даст никаких дополнительных возможностей относительно NDA.

«Суть не в том что кандидат сознательно говорит „не буду кодить за этой клавой“, а в том что он, по привычке, вместо таба попадает на КапсЛок, или вместо делита на слип (и вырубает комп :))»
Покажите мне клавиатуры где там и капслок пересекаются.
А на слип — вот и надо простая клава. За все время видел только одну модификацию которая приводила бы в подобному результату. Что-то типа этого — hotline.ua/...omfy_kb-06x_ps2

Ну и ладно, даже если выключится комп, ребут столько займет? минуту времени? не подождете?

Итого:
Контора поимела напряг с покупкой/настройкой/поддержкой дополнительной машины (или переключения ее в «кластер разработчика» и назад), установкой некоторого, не всегда бесплатного ПО, для выполнения задач которые вполне можно было выполнить «на бумажке»,

потому что некий великий гуру разработки считает что писать код на бумаге западло (ведь «он же не студент и это не входит в его обязанности»).

Нет. Контора поимела эти проблемы что-бы дать возможность выполнить задачу аналогичную выполняемой работе, а не взятой с потолка и «типа» показывающей умение кандадата думать.

Еще раз: «кастрированную корзину» которую вы предложили, можно легко написать на бумажке.
Но есть одно отличие задачи которую вы предложили от реальности:

Оне не интегрирована с остальным продуктом, и такая интеграция занимает больше всего времени и ее смоделировать на собеседовании довольно сложно, поэтому на собеседованиях все задачи «виртуальные».

Кстати пример реальной задачи: Определить по локали браузера файл локализации который надо использовать.

Задача делается в пределах часа (20 мин) и при этом не требует наличия ИДЕ.

Можно, не спорю. Все можно написать на бумажке. Разговор разве об этом?

Интеграция с реальной системой это 5-6 вызовов функций/методов между слоями. Где тут больше всего времени?

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

Вам приятней такое делать на бумаге или пользоваться современными средствами? Мне второе.

Не все задачи, даже 10минутные, реализация которых хоть 5 строк подходят под задачи для собеседования.

Проблема не в самой машине, а в админ расходах на нее
WHAT?

По-моему сейчас нормальный ПК стоит 20% от месячной ЗП сеньйора в Киеве. Это ли проблема для ИТ конторы?

Комп который будет использоваться несколько раз в год, а остальное время простаивать — это проблема.

Да и вообще, пока простаивает — в кластер другому прогеру. Нужна — вот собеседуйтесь.

Угу. И пофик шо у этого дева там выполняется какая-то важная задача, надо ведь собеседование проводить.

А про то что он там может хранить какие-то данные конторы и любой Вася пришедший на собеседование их увидит — это не проблема.

Эклипс и идея на одной машине это проблема? Ну поставьте все жаво ИДЕ охапкой сразу, нашли проблему...

Снова же платим бабло за ИДЕ, которые будут использоваться пару раз в год.

Да и вообще, стандарной клавиатуры должно быть достаточно.

Сужу строго по себе: мне сложно набирать код на «чужой» клавиатуре, стиль набора превращается в «падающего орла» (двухпальцевый) :)

Простите за повторяющиеся комметы, сайт лагает :)

1. добавление товаров.

Легко пишется на бумажке, тут самый интересны момент как человек спроектирует страницы. Если основная логика на клиенте, то задача на пару строк, если же сабмит после каждого добавления, то тут таки надо ИДЕ

2. сохранение корзины в персистентом виде.

Снова же самое интересное как спроектирует, если все правильно, то код уместится в несколько строк на бумажке.

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

Есть люди, например я, которые сначала пишут что-то работающие, а потом несколько часов исправляют «механические недочеты». Например, скорость схлопывания/раскрытия элементов на странице, замена Листа на более подходящие коллекции. При чем все это довольно нудные и механические вещи, которые вряд ли интересны интервьюеру.

Я верю в то, что вы и реверс легко напишите. И то что 2 вышеописаных примера просты.
По поводу проектирования страниц — человек может хорошо проектировать, но отвратно кодить. Встречали такое? И бывают ситуации полностью наборот.

Нам не надо сложные задания. Простое задание из реальной жизни достаточное.

Но вы же видите, что мы уже обсуждаем вопрос о проектировании и реализации относительно того, что будет делать человек к реальной работе.
Какое отношение к реальной работе имеет реверс?
Ждать полной реализации без ошибок в ИДЕ никто не требует, если человек адекватно пройдет этап проектирование и займется логической реализацией — то можно и не заканчивать.

Опять же, если человек не захочет писать реверс на бумажке, но в 5 предложенях обьяснит реализацию этого будет недостаточно?

Какое отношение к реальной работе имеет реверс?

Суть не в реверсе. Основной посыл:
На данный момент я не знаю способа лучше чем проведение собеседований «на бумажке».

Проведение собеседований «в ИДЕ», не решает ни каких проблем способа «на бумажке», а только добавляет работы ИТ-отделу конторы (хотя может я просто не заметил ваши доводы)

Тогда если отбрасываем суть задания, а сводим все к методу тестирования: бумага vs IDE, то, относительного того, что многим не нравится бумага: людям непривычно делать привычную работу в непривычной обстановке(читай писать на бумаге). И все, других вариантов не много. Или я каких-то проблем не заметил?<p>Думаю если разработчикую владующего идеей дать на выбор сделать задание на бумаге или в эклипсе, то, думаю, меньшнее из зол будет для него эклипс. Опять же, если в работе он вправе пользоваться внешней информацией — то логично дать ему доступ и на собеседовании к ней. Задачу нужно решить любым способом, главное что-бы в конце небыло плохого кода.</p>

Вообще мне кажется, людям больше не нравится суть заданий(реверс строки, реверс линейного списка и т.д.) — потому что они не из реальной жизни. Будет нужное задание — меньше людей будут и бумажкой брезговать. <p>Хотя это все мои догадки, мне не лень на собеседовании и на бумажке написать, и в идее место эклипса и т.д. Т.к. хозяин-барин :) </p>

Бумажла вообще плохой вариант, т.к. нужно либо ждать пока испытуемый все дорисует или заглядывать через плечо.

> > Если можно найти работу в другой фирме, за такую же зарплату, и где не требуют написания кода на бумаге или на доске?

А вот тут я с тобой не согласен.

Возможно в Киеве ситуация в чем-то отличается, больше контор, больше програмистов, но в нашей деревне при определённом уровне требовательности найти подходящую работу не так уж и просто. Нет, вакансии есть, много, во многих конторах, но если из первичного списка вакансий отфильтровать то что по тем или иным _существенным_ причинам мне заведомо не подходит то остаётся не такой уж и широкий выбор.

И моё мнение как работника если и выёживатся, то выёживатся насчет чего-то важного как то: — Зрплаты — Интересной и развивающей работы (что в офшоре ещё поискать надо) — Перспектив — Нормального коллектива — Нормальных условий на рабочем месте,

а не насчёт того что там и как спрашивают на собеседовании.

Переезжай работать в Киев, если у вас так плохо

А где я сказал что у нас так плохо? Я всего лиш сказал что стоит быть разборчивым относительно чего-то существенного а не всякой фигни

Джуе актуально, про топові питання на співбесідах: habrahabr.ru/...logs/hr/114124

Кому интересно похожая тема на рсдн: www.rsdn.ru/...at.aspx#4164242

По поводу собеседования на java-developer — www.javenue.info/post/88

Статья еще не полностью окончена, но, уверен, что найдутся люди, кому она уже будет интересна.

только один!
какую зарплату вам можно предложить?...

да!

Мой любимый вопрос джава джуниорам: «Допустим вам надо быстренько реализовать хеш мап. Расскажите ход ваших мыслей, как вы это будете делать? »

Попробую на скорую руку отписать, какие знания, на мой взгляд, должен суметь продемонстрировать разработчик.

Junior. Надо понимать, что реального опыта разработки скорее всего нет или очень мало. На первом месте на собеседовании — знание основ и умение думать. Базовые алгоритмы, базовые структуры данных, понимание того, как код исполняется, где в памяти хранится, что такое стек, как происходит вызов функций и так далее. Обязательно должен показать практическое умение писать код. За сотню собеседований я встречал непростительно большое количество «программистов», которые не могли на доске набросать простую функцию типа расчета факториала или реверса строки (если позволите, моя прошлогодняя заметка на эту тему — demiurg.com.ua/...ogram-russian) В последнее время именно с просьбы реализовать на доске простую задачу я и начинаю, постепенно раскручивая беседу в сторону интересных мне тем.

Mid. Все то же самое, что и выше + структуры данных, библиотеки, алгоритмы, управление памятью, особенности конкретных OS, базовая многозадачность, синхронизация и так далее.

Senior. На этом уровне к знаниям j/m должны добавиться вопросы уровня дизайна, проектирования систем и (обычно) вопросы производительности. Человек должен не только знать, скажем, что вектор быстрее списка в таком-то случае, но и хорошо понимать причины этого на уровне кода контейнера. Это касается и всех остальных областей — multithreading, ipc, networks и так далее.

Общий совет — пусть люди покажут свои знания, а не расскажут о них. 200 строк кода, написанные кандидатом, расскажут знающему интервьюеру больше, чем полчаса беседы о высоких материях.

и опять, если вначале поста, можно соглашаться, то в конце пошли специфические термины явы, дотнета и спп.,

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

Когда уже наконец люди поймут, что водитель автобуса будет иметь дургие навыки от водителя дальнобойщика и тем более отличаться от водителя формулы 1.

А еще есть джипперы, кольцевые гонки на серийных машинах, и т. д.

Я сосбственно к чему.
Каким образом,
multithreading, ipc, networks и так далее.

относятся к веб-сениору?

По этому я и попросил написать каждого «для его специализации».

> мультипотоков
Что такое мультипотоки?

> multithreading, ipc, networks и так далее.
> относятся к веб-сениору?
В доскональности веб-деву это знать не всегда надо, но понимать основные принципы необходимо, что бы не задавать глупых вопросов в стиле «почему у меня счетчик увеличился не на 1, а на 2»

основные принципы надо знать любому синиору.

8 бит в байте оно как ни крути пока так и остается.

> сори, Multithreading я обозвал мультипотоками. не со зла. у меня тут 180 спамов в травиане идет:)

Кстати, кто еще в травиан играет?

Да, я именно об этом:)

Возможно, я невольно наложил специфику моей области (C++, server-side, high load) на ответ. В любом случае, если досконально особенностей, скажем, сетевого стека программисту web ui знать не надо, то уж основы — знать надо наверняка.

И конечно, для python, ruby, php, любого ЯП и любой технологии всегда есть свои области, знать которые хорошо должен человек, претендующий на позицию senior.

> 200 строк кода, написанные кандидатом

Сужу исключительно по себе: 200 строк эффективного алгоритмического кода (исключая описания класов, комментарии, объявление аксессоров и тд, забыл термин) — это примерно часа 4 активной работы + поправка на стрессовость ситуации (собеседование). И не всегда есть возможность (у обоих сторон выделить такое время)

Да, хорошо, когда у кандидата есть возможность написать, а у компании — оценить эти 200 строк. Согласен — так бывает не всегда, да и не всегда необходима такая сложность.

В любом случае, за 45 минут интервью с маркером у доски (или с shared google dos по телефону) можно набросать несколько десятков строк, по которым понятен уровень программиста как программиста, а не специалиста разговорного жанра:)

было забавно когда в GL спрашивали о жизненном цикле бага. о том что через этот вопрос у меня хотели узнать о работе с CVS я понял только когда вышел из их офиса xD

Если говорить о технической стороне. То в первую очередь, хорошие вопросы — это вопросы на понимание азов программирования.

Чтоб много не писать, вот примеры из достоверных источников:
habrahabr.ru/...lations/111843

habrahabr.ru/...lations/112561

А вот как одна широко известная в узких кругах компания набирает junior инженеров))

ip.cqg.com.ua/participation

Это еще даже не junior’ов, это — студентов на обучение:)

ИМХО шаблонные вопросы/анкеты/задачки годятся только для студентов и начинающих программистов. Их большой недостаток: после 10ого интервью соискатель будет знать ответы наизусть, но при этом до сих пор ничего собой не представлять.

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

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

Вопрос был в целом. Так же интересно ваше мнение, по поводу того что должны были у вас спрашивать.

Нет, требование не возмутило.

Простите, значит я не правильно понял вашу фразу:

3) Заставляют код писать на бумажке. Когда-то я был студентом, писал на бумажке. Теперь я — уже давно не студент. А по-етому, это как-бы и не входит в мои обязанности.

P. S. АДМИНЫ! Когда наконец к комментариям прикрутят хоть бы простенькую панель форматирования текста!1АДЫН

> Какие вопросы надо задавать на собеседованиях?

От позиции и соискателя (резюме) зависит. Если серьёзная позиция с соискателем, имеющим в/о по специальности + 5 лет работы в приличных компаниях и хорошие рекомендации, то на собеседовании надо понять, насколько такой подходит к проекту/фирме в плане бэкграунда (использованных до сих пор средств/технологий), мотивации.

Для этого рассказать о фирме, проекте; поинтересоваться видением претендента на те или иные технические вопросы, связанные с проектом; узнать, чем проект претенденту интересен, итп.

Именно, должна быть беседа, а не односторонний поток несвязанных вопросов.

Меня спрашивали, что такое инкапсуляция

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

Хммм... А разве это не задача архитектора? Во-вторых, если говорим о более-менее простеньком чем-нить, то сиравно на то, чтобы нарисовать что-то толковое надо времени некоторое количество, нет?

> Хммм... А разве это не задача архитектора?

Еще не встречал конторы в которой был б некий архитектор, которй б разработал весьдизайн, а кодер кодили по спецификациям.

> Во-вторых, если говорим о более-менее простеньком чем-нить, то сиравно на то, чтобы нарисовать что-то толковое надо времени некоторое количество, нет?

Если синьёр девелопер не способен сходу обозначить классы скажем парсера json или графического редактора, пусть идет манкипатчить гавнокод в другое место.

> Еще не встречал конторы в которой был б некий архитектор, который б разработал весьдизайн, а кодер кодили по спецификациям.

Ну так бы и сказал, что работаешь в быдлокодящих каловых конторах.

> Если синьёр девелопер не способен сходу обозначить классы скажем парсера json или графического редактора, пусть идет манкипатчить гавнокод в другое место.

Если синьор девелопер в состоянии за 5 минут это сделать, без осмысления, чтения ТЗ, общения с заказчиком — то грошь цена такому девелоперу, т. к. его гАвноархитектуру потом прийдецца 100500 раз перепиливать. И самое главное ты даже не отрицаешь, что «манкипатчить гавнокод» прийдецца и на сией конторе по производству каловых масс, которая предлагает такое. Ч.Т. Д.

> Ну так бы и сказал, что работаешь в быдлокодящих каловых конторах.

А можно имена «продвинутх» контор в студию?

> Если синьор девелопер в состоянии за 5 минут это сделать, без осмысления, чтения ТЗ, общения с заказчиком — то грошь цена такому девелоперу, т. к. его гАвноархитектуру потом прийдецца 100500 раз перепиливать.

Тебе для того что бы нарисовать классы парсера JSON нужно общаться с заказчиком?

> И самое главное ты даже не отрицаешь, что «манкипатчить гавнокод» прийдецца и на сией конторе по производству каловых масс, которая предлагает такое. Ч.Т. Д.

lurkmore.ru/Butthurt

> А можно имена «продвинутх» контор в студию?

Без понятия. Я — фрилансер. Полагаю, что таки и в формошлепских конторах должны иметь место, но доподлинно неизвестно. В промышленности встречал на той же КриворожСтали.

> Тебе для того что бы нарисовать классы парсера JSON нужно общаться с заказчиком?

Безусловно. Как минимум, чтобы выяснить, какой должен быть выхлоп парсера (например, стоит ли джсону формировать классы или сразу писать в БД и оттуда все тягать, а можеть вообще в виде диктионари оформить и дальнейшие манипуляции производить вручную), также, надо выяснить, насколько устоявшееся апи, которое выдает на гора джсоны, дабы не перепиливать по 100 раз парсер при смене апи, если апи еще на стадии допиливания, соответственно парсер должен быть предусмотрен с определенной долей гибкости, также, надо выяснить, не захочет ли заказчик в дальнейшем еще и часть выхлопа в виде хмл или вотще бинарщины добавить и опять же предусмотреть это в возможностях парсера, дабы, если что, он был расширяем и чтобы формировались нужные данные после парсинга.

А вы этого не делаете в своих конторках? На шаг вперед думать — это слишком сложно? Причем, насколько я понимаю, настолько сложно, что лучше по 100500 раз все перепиливать, чем точно определицца с требованиями и желаниями заказчика?

> lurkmore.ru/Butthurt

От человека истерившего про манкипатчинг звучит, как минимум, забавно.

> Без понятия. Я — фрилансер. Полагаю, что таки и в формошлепских конторах должны иметь место, но доподлинно неизвестно. В промышленности встречал на той же КриворожСтали.

Понятно, то есть про архитекторов это были фантазии наивного юноши...

> Безусловно. Как минимум, чтобы выяснить, какой должен быть выхлоп парсера (например, стоит ли джсону формировать классы или сразу писать в БД и оттуда все тягать, а можеть вообще в виде диктионари оформить и дальнейшие манипуляции производить вручную), также, надо выяснить, насколько устоявшееся апи, которое выдает на гора джсоны, дабы не перепиливать по 100 раз парсер при смене апи, если апи еще на стадии допиливания, соответственно парсер должен быть предусмотрен с определенной долей гибкости, также, надо выяснить, не захочет ли заказчик в дальнейшем еще и часть выхлопа в виде хмл или вотще бинарщины добавить и опять же предусмотреть это в возможностях парсера, дабы, если что, он был расширяем и чтобы формировались нужные данные после парсинга.

Это все намного удобнее сделать, если уже есть парсер парсящий его в промежуточный набор классов, и он совершенно не должен знать ничего о БД, хмл, и прочем. Если напрягает держать промежуточное состояние в памяти, то можно написать/заюзать sax подобный парсер.

> А вы этого не делаете в своих конторках? На шаг вперед думать — это слишком сложно? Причем, насколько я понимаю, настолько сложно, что лучше по 100500 раз все перепиливать, чем точно определицца с требованиями и желаниями заказчика?

Мы в «конторках» так делаем, поэтому я в своем первом посте и указал на важность и необходимость навыка ОО дизайна.

Возвращаясь к вопросу о собеседовании, то там твой заказчик — интервьюирующий, и ты можешь смело задавать все вопросы ему. Но если в ответ пойдет поток поноса, про тупизну таких заданий, то фрилансь лучше дальше, у каждого свои задачи, кому то хелловорды и казуалки для айфонов писать, а кому то и чем то посложнее заниматься.

> От человека истерившего про манкипатчинг звучит, как минимум, забавно.

Я называю вещи своими именами, и от слов не отказываюсь, а вот ты очевидно ничего не знаешь о «моих конторках» как и о конторах вообще, так что помолчал бы.

> Понятно, то есть про архитекторов это были фантазии наивного юноши...

Ок. Архитекторы есть в МС, Эппл, Тим Бонди — это то, что известно из первых уст. Также, есть в промышленности в Украине. Вывод, ты работаешь в формошлепской быдлоконторе.

> Это все намного удобнее сделать, если уже есть парсер парсящий его в промежуточный набор классов, и он совершенно не должен знать ничего о БД, хмл, и прочем. Если напрягает держать промежуточное состояние в памяти, то можно написать/заюзать sax подобный парсер.

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

> Мы в «конторках» так делаем, поэтому я в своем первом посте и указал на важность и необходимость навыка ОО дизайна.

К чему тогда этот пердеж в лужу:

> > Если синьор девелопер в состоянии за 5 минут это сделать, без осмысления, чтения ТЗ, общения с заказчиком — то грошь цена такому девелоперу, т. к. его гАвноархитектуру потом прийдецца 100500 раз перепиливать.

> Тебе для того что бы нарисовать классы парсера JSON нужно общаться с заказчиком?

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

Возвращаясь к вопросу о собеседованиях, вспомни, что я сразу указал, что нормальную архитектуру продумать мгновенно не выйдет, на что получил кал на вентиляторе.

> Но если в ответ пойдет поток поноса, про тупизну таких заданий, то фрилансь лучше дальше, у каждого свои задачи, кому то хелловорды и казуалки для айфонов писать, а кому то и чем то посложнее заниматься.

Посложнее? Мусье явно не в курсе, на счет весьма многих особенностей того, о чем пишет. Ну оно и понятно, исходя из того, что мусье будет пхать лишние сущности, куда ни попадя, ибо тебе, по-видимому, платят за количество строк кода, как индусам.

> Я называю вещи своими именами, и от слов не отказываюсь, а вот ты очевидно ничего не знаешь о «моих конторках» как и о конторах вообще, так что помолчал бы.

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

> Ок. Архитекторы есть в МС, Эппл, Тим Бонди — это то, что известно из первых уст. Также, есть в промышленности в Украине.

Да, там есть архитекторы (я как бы обратного и не утверждал), но они не генерируют диаграммы абсолютно всех классов.

> Вывод, ты работаешь в формошлепской быдлоконторе.

Это потому что в Эпле есть архитекторы я работаю в формешлеперской контроре? Логика потрясающа.

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

Капитан, ты открыл великую тайну, что если текст не нужно парсить то парсер не нужен.

> Я так понимаю, про такие страшные вещи, как бритва оккама и отказ от избыточных сущностей для тебя — просто слова?

И откуда ты это понимаешь если не секрет?

> Вывод — даже при написании парсенра надо спрашивать, а если формошлепоконтора считает, что не надо, то созадет себе излишние пробелмы, что и приводит нас к моему первоначальному постулату о том, что архитектуру придумывать без первоначальных требований и быстро накидывать — минус конторе и собеседующему.

А пацаны из «конторок» амазона и фейсбука и не знают:

www.glassdoor.com/...w-RVW812707.htm
www.glassdoor.com/...w-RVW606062.htm
www.glassdoor.com/...w-RVW740842.htm
www.glassdoor.com/...w-RVW374431.htm

www.glassdoor.com/...-QTN_133314.htm

И к чему смешивать ситуацию на собеседовании с реальными проектами?

> К чему тогда этот пердеж в лужу:

Хорошо что напомнил, так ты ответишь на вопрос необходимо ли тебе общатся с заказчиком для написания JSON парсера?

> Возвращаясь к вопросу о собеседованиях, вспомни, что я сразу указал, что нормальную архитектуру продумать мгновенно не выйдет, на что получил кал на вентиляторе.

Не суди о всех по себе. Парсер JSON и еще куча всего вполне реально спроектировать на собеседовании.

> Посложнее? Мусье явно не в курсе, на счет весьма многих особенностей того, о чем пишет.

Ну так может просветишь в чем я не прав?

> Ну оно и понятно, исходя из того, что мусье будет пхать лишние сущности, куда ни попадя, ибо тебе, по-видимому, платят за количество строк кода, как индусам.

Давай конкретно, какие сущности куда я пихаю, и что дало тебе повод делать такие выводы?

> Очевидно, о твоих ничего не знаю, о формошлепоконторах знаю достаточно, чтобы с них и их работников ржать.

Ну так и направляй свою критику на такие конторы (кстати имена в студию), и не делай лишних выводов.

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

> Да, там есть архитекторы (я как бы обратного и не утверждал), но они не генерируют диаграммы абсолютно всех классов.

Ты уверен?

> Это потому что в Эпле есть архитекторы я работаю в формешлеперской контроре? Логика потрясающа.

Потрясает твое неумение читать и осознавать прочитанное.

> Капитан, ты открыл великую тайну, что если текст не нужно парсить то парсер не нужен.

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

> И откуда ты это понимаешь если не секрет?

Потрясает твое неумение читать и осознавать прочитанное. Перечитай то, что я написал ранее. Тебе сразу все станет понятно.

> А пацаны из «конторок» амазона и фейсбука и не знают:

> И к чему смешивать ситуацию на собеседовании с реальными проектами?

Ты хоть сам ходил по тем ссылкам, которые дал? Сходи, будешь удивлен, когда чутку почитаешь и поймешь. И да, перечитай наш разговор до этого, чтобы быть совсем в теме и заметить, что подтвердил ты сиими ссылками мое мнение. ХОтя да, учитывая то, что ты плохо умеешь читать и не умеешь осознавать прочитанное, ничего удивительного.

Собеседование — это не только возможность конторы оценить тебя, но и твоя возможность оценить контору. Очень часто кал начинает вытекать еще на собеседовании. И, если челвоек мыслит узко на собеседовании, то совсем не исключено, что и в проектах срачЪ.

> Хорошо что напомнил, так ты ответишь на вопрос необходимо ли тебе общатся с заказчиком для написания JSON парсера?

Перечитай выше. Я уже отвечал. Хотя да, учитывая твою убогость и неумение воспринимать прочитанное, я тебе отвечу совсем уж прямо: «Да. Я считаю, тчо по любому взаимодействию с системами заказчиками надо выяснить все детали прежде, чем начинать что-то делать. »

> Не суди о всех по себе. Парсер JSON и еще куча всего вполне реально спроектировать на собеседовании.

Да? ГАвнопарсер ДЖСОН — вполне. В принципе, нормальная практика дял формошлепоконтор, посему, ты вполне входишь в общее поток формошлепов, пилящих проекты по десяткам челвоеколет и никогда не успевающим выполнить весь заявленный к выполнению функционал.

> Ну так может просветишь в чем я не прав?

Я уже просветил. Ну, а если уж пишешь про ифон и обжектив, то неплохо бы разобрацца в том, о чем пишешь. Если пишешь, про промышелнному робототехнику о том, что его работа элементарно, и проектики у него простенькие, в отличии от формошлепания, то тоже бы не помешало хотя бы слегка разобрацца в специфике. Иными словами, ты не прав во всем. Что тебе в соседнем треде про архитектуру популярно пояснили.

> Давай конкретно, какие сущности куда я пихаю, и что дало тебе повод делать такие выводы?

Читай выше по треду свои сообщения. Не пойму никак, ты склеротик или у тебя дислексия?

> Ты уверен?

Уверен.

> Потрясает твое неумение читать и осознавать прочитанное.

Слив.

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

Слив. Ты говорил не это.

> Потрясает твое неумение читать и осознавать прочитанное. Перечитай то, что я написал ранее. Тебе сразу все станет понятно.

Слив.

> Ты хоть сам ходил по тем ссылкам, которые дал?

Ходил конечно. Ссылки явно показывают что в «конторках» амазоне и фейсбуке практикуют вопросы по ОО дизайну, что и является обьектом твоей критики.

> И да, перечитай наш разговор до этого, чтобы быть совсем в теме и заметить, что подтвердил ты сиими ссылками мое мнение. ХОтя да, учитывая то, что ты плохо умеешь читать и не умеешь осознавать прочитанное, ничего удивительного. Собеседование — это не только возможность конторы оценить тебя, но и твоя возможность оценить контору. Очень часто кал начинает вытекать еще на собеседовании. И, если челвоек мыслит узко на собеседовании, то совсем не исключено, что и в проектах срачЪ.

Слив.

> Перечитай выше. Я уже отвечал. Хотя да, учитывая твою убогость и неумение воспринимать прочитанное, я тебе отвечу совсем уж прямо: «Да. Я считаю, тчо по любому взаимодействию с системами заказчиками надо выяснить все детали прежде, чем начинать что-то делать. »

Да, согласен, я пропустил твой ответ, тем не менее идея общения с заказчиком по поводу написания парсера JSON считаю бредовой.

> Да? ГАвнопарсер ДЖСОН — вполне. В принципе, нормальная практика дял формошлепоконтор, посему, ты вполне входишь в общее поток формошлепов, пилящих проекты по десяткам челвоеколет и никогда не успевающим выполнить весь заявленный к выполнению функционал.

Слив. Очень странно слышать от тебя критику того чего ты никогда не видел (имеется в виду результатов проектирования парсера на собеседовании и моя успеваемость по проектам).

> Ну, а если уж пишешь про ифон и обжектив, то неплохо бы разобрацца в том, о чем пишешь.

Я разбираюсь в вопросе на достаточном для суждения уровне.

> Если пишешь, про промышелнному робототехнику о том, что его работа элементарно,

Что за больная фантазия, где я об этом писал?

> Читай выше по треду свои сообщения. Не пойму никак, ты склеротик или у тебя дислексия?

Слив.

> Иными словами, ты не прав во всем. Что тебе в соседнем треде про архитектуру популярно пояснили.

Полный бред. Можно ссылку на пост где мне это «обьяснили»?

> ХОтя да, учитывая то, что ты плохо умеешь читать и не умеешь осознавать прочитанное, ничего удивительного.
> В принципе, нормальная практика дял формошлепоконтор, посему, ты вполне входишь в общее поток формошлепов, пилящих проекты по десяткам челвоеколет и никогда не успевающим выполнить весь заявленный к выполнению функционал.

> Не пойму никак, ты склеротик или у тебя дислексия?

Диагноз — батхерт.

Ах, старые добрые срачи на доу:)

ХЗ. Скажу честно, что вопросы на собеседованиях отвлечены от жизни, некоторые с подколкой, более того, слишком теоретические. Хотелось бы видеть на собеседованиях вопросы, которые более приближены к реальности и реальным задачам, еще лучше бы вообще не видеть вопросов технических, а просто выполнять тестовое предварительно. Также, хотелось бы, чтобы собеседующие, задающие вопросы с подковыркой, знали бы хотя бы базисные вещи в полном объеме и на них не наламывались.

Второй вариант, если оцениваецца соображалка, чтобы просто давали задачу в которой не шарю, садили за машину, давали доку и смотрели, как я сию задачу выполняю.

Если уж хотят алгоритмических задачекЁ, то мне, как пользователю автокомплита, очень помогло бы написание на листке не кода, а псевдокода.

Пока только одна компания сумела в себя просто влюбить своим собеседованием, хотя я туда в итоге не пошел.

> > Если уж хотят алгоритмических задачекЁ, то мне, как пользователю автокомплита, очень помогло бы написание на листке не кода, а псевдокода.

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

Требуют. Я некоторое время назад ржал, как конь, когда мне заявил интервьюер, что у меня ошибка в функции, ибо я malloc по невнимательности на листке бумаги с одной Л написал.

Но, по факту, тестовое — намного лучше. Я не люблю эти неротрепки и т. п. чушь, когда тебе какой-нить прыщь пытаецца доказать, что ты — дурак, а ведь такое случаецца зачастую. И да, лично я согласен провести часа 4 выполняя реальную задачу в конторе на машине, а не устраивать пустую болтовню, по которой должны определить мою квалификацию.

Ты уверен что не пропустил какую-то нотку юмора? Я вот недавно с трудом вспомнил сколько там аргументов у этого Маллока, и ничего.

С тем что тестовое лучьше поспорить трудно. Но толковое тестовое требует и бОльших трудозатрат с обеих сторон. Я вот к примеру хожу сейчас активно по собеседованиям и не в каждой конторе я готов потратить 4+ часа тем более в рабочий день, ну разве что из большого интереса к компании позиции или самому заданию. Кроме того такие тестовые дают только лучьшие компании. Те в которые стоит хоть какая-то очередь из кандидатов.

На следующей неделе иду на собеседование в качестве интервьюера. У меня припасены задачки на бумажке, а вот тестового на 4 часа нету.

Уверен. Мне на этом основании пытались доказать, что я дурак и долго тыкали в это, как в самую главную ошибку в моей жизни.

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

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

всех вышеупомянутых спрашивать про списки (хороший вопрос) и просить написать пример кода на бумажке (можно на доске или ещё на чем-нибудь).

Всех возмущающихся «синьёров» либос сразу посылать как неадекватов, либо популярно обьяснять что дескать «видиш ли дорогой, мы и не думали тебя обидеть но просто у меня есть час (пол-часа) времени для того что бы удостоверится в том что ты нам действительно подходиш, умееш в принципе писать код, знаеш основы, умееш соображать. И делаю я это самым лучьшим сопсобом до которого смог додуматся».

Я с таким подходом абсолютно согласен. Но все же еще хотелось бы избежать громких «обсыраний на форумах» в стиле тех что я описал в начале темы.

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

Извини, но это — не знания. Это простая зубрежка, либо человек пишет в среде без автодополнения.

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

Единственное что можно сделать — вести себя с кандидатом максимально вежливо и корректно. Вот и все.

подходиш, знаеш, умееш...

:)

«„синьёров“ сразу посылать»

Думаю, толковые инженеры в такой конторе работать вряд ли когда будут с подобными подходами к соискателям.

Собеседование, вообще, сложная штука. К каждому кандидату нужен свой подход и не так-то просто определить человека за пол часа беседы с ним — часто на это уходят месяцы. Кого-то нужно загрузить задачками, кому-то эти задачки — издевательство, ибо вы еще сами докажите, что ваша контора и предлагаемая мизерная ЗП стоит его времени ;).

>>Думаю, толковые инженеры в такой конторе работать вряд ли когда будут с подобными подходами к соискателям.

Не согласен. Чем более разборчивая компания тем более профессиональные и зрелые люди в неё попадают. Моя компания к примеру несколько раз отказала сеньёрам, моим знакомым, на основании неадекватного поведения на собеседовании. Просто если интервьюер (не я) после интервью даёт заключение «с профессионально точки зрения подходит, но не дай бог мне когда-нибудь с этим moodаком работать» то в таком случае просто нет смысла смотреть на профессинальные качества.

>>Собеседование, вообще, сложная штука

А масло вообще штука маслянная, с этим никто не поспорит

>>ибо вы еще сами докажите, что ваша контора и предлагаемая мизерная ЗП стоит его времени ;).

Видиш ли, ты сам сказал что собеседование штука сложная и для того что бы разобраться кто кому и насколько подходит вполне логично сделать хоть по пол-шага навстречу друг другу с _КАЖДОЙ_ стороны.

Насчет времени просто коментировать не буду. Если пришел значит почему-то решил что стоит таки компания его времени. И ещё одно — кандидат не делает компании одолжения просто прийдя на собеседование, даже в условиях кадрового голода, даже если НР упросила.

Хочу сказать что сам я в данный момент неспешно ищу работу, хожу по собеседованиям. Вот последнее собеседование с НР у меня совсем не сложилось — бывает. НР проводила паралели между наёмом работников и покупкой и возвратом назад по гарантии фенов. Мне не понравилось но я сдержался. не стал обяснять ей почему она не права. Вобщем прошел тех интервью потом дошел до офера. Теперь и я и компания можем судить о том насколько подходим друг другу. В том числе учитывая и «политику фенов».

Если человек отказывается опускаться на собеседовании до уровня задач/головоломок, то есть 2 варианта:

1. Он профан.

2. Предлагаемая Вами работа ему очень мало интересна и он не желает тратить свое время и энергию на ненужные вещи.

Вариант 2 — это жирнющщий минус представителям компании, в этом случае провалили собеседование именно они.

> > есть 2 варианта:
> >1. Он профан.

> >2. Предлагаемая Вами работа ему очень мало интересна

ППКС

> > Вариант 2 — это жирнющщий минус представителям компании, в этом случае провалили собеседование именно они.

-1. И опять я категорически с вами не согласен. Вы почему-то исходите из того что в случае интервью обе стороны принипременно заинтересованы в его удачном исходе? Вы считаете что все вакансии подходят всем? Есле человек по какой-то причине не заинтересован в компании настолько что даже не желает довести до конца начатое интервью то собственно выяснить этот факт и перестать тратить общее время и есть задачей интервьюера.

Интервью для того и проводятся что бы обе стороны оценили насколько они друг другу подходят. И если в результате разговора они приходят к заключению что дальнейшее развитие отношений не целесообразно — то в этом может не быть ничьей вины. Это просто может быть не более чем фактом. Вот и всё. И плевать слюной про вину компании и скудные зарплаты в этой ситуации это совсем излишнее.

Если уже разговор зашёл за java, то:

— core (i/o, serialization, exceptions etc.)
— multithreading (не просто какие есть, а например напишите свою реализацию CountDownLatch)
— collections (как же без них, многопоточные сюда же)
— regular expressions
— base algorithms (binary search etc.)
— patterns (можно по GOF)
— 1-2 алгоритмические задачи

— sql — если работа того требует

А так ли важна память регекспов, что бы спрашивать на собеседовании?

reality_hacker-ам думаю не помешает ))) это я так навскидку, html верстальщику regexp знать не надо, а JavaScript программисту — надо.

А если не секрет, зачем программисту на js regexp-ы?

1) Валидации, а их довольно много
2) «Выкусывания» из текста нужных кусков (если не все разбито тегами правильно)

3) Есть любители хранить ид серверных объектов (энтитей) в ид ДОМ-элементов (иногда в сложенном виде, например id_[listId]_[elementId])

Валидации согласен. Остальное может быть, я с таким не сталкивался..

На Ваш вопрос очень правильно ответил silverwolf. Очень часто видишь, как люди выкусывают какую-то информации из текста в виде (str.substring(str.indexOf("..."), str.indexOf("...«))) и тд. Со мной работал очень грамотный js developer, так вот он на собеседовании очень часто задавал вопросы по regexp. Когда я работал на php — это тоже была весьма популярная тема. На java это как-то не сильно актуально, но я люблю пользоваться regexp. По-сути, regexp — это грамотная работа с текстовыми данными. Вы когда работаете с данными и вам нужно сделать время поиска элемента константным O(1) или O(lg N), Вы же не будет использовать LinkedList например. Так и тут. «Есть 10 типов людей — те, кто понимает двоичный код и те, кто не понимает.» © )))

Я все еще не понимаю зачем js кодеру что то выкусывать из текста. Хотя не исключаю что это может быть результатом какой то кривоты апликухи.

не готов скзаать за JS (думаю там тоже самое), но питон, пхп открыто заявляют, что если надо надо просто найти один фрагмент в тексте, то регекспы лучше не использовать. Они МЕДЛЕННЕЕ простых функций поиска. И это логично, так как у них сложнее логика работы.

Поэтому .indexOF() решение лучше для нахождения чего-то в тексте.

За скорость согласен (swtch.com/.../regexp1.html) В python, java etc. regexp-ы реализованы приблизительно одинаково. indexOf конечно быстрее. Но это подходит только для простых случаев.

Классический пример: проверьте корректен ли ip и выкусите все 4 числа из него.

Вот java:
final Pattern IP_PATTERN = Pattern.compile( «^((([01]\\d{2})|([0-2][0-5]{2})|([1-9]?\\d))(\\.|$)){4}$»);

Можно найти и более простой regexp для этого случая. Я навскидку написал.

ну собственно, согласен, что если возникают случаи с более-менее разными условиями, регескпы незаменимы, но изначально то про это не было скзаано :)

А так регескпы это как демократия. Они ужасны, но ничего лучше пока человечество для сложной обработки текста не придумало.

Я просто вёл к тому, что нужно спрашивать вещи независящие от языка программирования. А получились целые выкладки с доказательствами )))

Не забывайте про специфику: короткие задачи за приемлемое время, 500 мс или 300мс — для обработчика клика — это практически одно и то же.
Второй момент размер кода — для джаваскрипта это важно.

Пункт 3 — скорость написания.

Поэтому .indexOF() решение лучше для нахождения чего-то в тексте.

А если кусок не непрерывный?

ну доп условий можно много накидать :) изначально ничего не было.

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

Не забывайте про специфику: короткие задачи за приемлемое время, 500 мс или 300мс — для обработчика клика — это практически одно и то же.

с одной стороны да, а с другой когда сейчас уже куча логики переносится на клиент-сайд, то в одиночку это мало, а суммарно по накоплению уже может ощущатсья.

Не будет ощущается. Когда вы нажимаете на кнопку то обработчики должны быть не большими, и при тех временах отличие даже в 2 раза не ощущается, если у программиста руки прямые.

А складывать 1 лимон кликов в суммарное время — это не совсем корректно.

да, и еще... вопросы НАДО задавать всем, кто встретится в конторе: HR, интервьюеры, просто знакомые-не знакомые. цель- не просто отсобеседоваться, а собрать инфу для принятия решения.
чтобы не увольняться затем из конторы по причинам, которые открылись пост-фактум.

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

Если в свете озвученной проблемы, то я прошу показать мне три небольших куска Вашего лучшего кода (естественно, человек предупреждается заранее). Потому, что далее по работе будет не write code fast contest, а только write fast code contest.

Больше всего не люблю, когда просят предоставить свой код на собеседовании. Не знаю почему, но мне это совсем не нравится. Не можете адекватно протестировать человека, узнать его уровень, найдите профессионалов, пусть они вам найдут человека (это чисто мои соображения).

«Не можете адекватно протестировать человека, узнать его уровень-?» - если ответ на этот вопрос положительный, то лично моё решение обычно отрицательное, независимо от того, насколько я удачно прошел собеседование и сколько мне предложили.
не сочтите за членомерство.
в контору стОит идти работать, чтоб расти. иначе — потерянное время.

Бывает ... у каждого своё видение. Я очень негативно отношусь к коду на бумаге.

А можно все таки сказать почему? Лично мне, субъективно, эта идея (тестирования на бумажке) очень нравится.

Скорее всего сферы очень разные, я всё-таки только на low level system и embedded development завязан. Поэтому мне важнее отличный кусок кода, который скажет, опять же, лично мне, гораздо больше.

Я часто встречал людей, которые не могут выдать экспромптом ничего путного, но если им дать подумать, то они достигнут конечного результата за то же время что и те, кто могут кодить ad hock.

Вот реально, кому нужен вот такой вот real-time programming на листике ? Мне не нужен.

При написании кода на бумаге, как правило, проверяют знание базовых вещей — конструкций языка программирования, основных алгоритмов и структур данных, и т. п. И подумать при этом, разумеется, какое-то время дают. Ни один вменяемый интервьюер, ИМХО, не ожидает, что кандидат начнет сразу же «строчить» код с низкого старта:)

Но что касается времени на размышления, вообще-то предполагается (если речь не идет о разного рода головоломках), что подобные вещи кандидат УЖЕ знает, и не раз применял на практике.

И насчет псевдо-кода. Разумеется, требовать зазубривания количества и порядка параметров функций — маразм. Но вот все же приведенный выше пример с malloc — спорный. С одной стороны, если это единственное, к чему можно было придраться в решении — то интервьюер явно был неправ. С другой, если кандидат систематически пишет с ошибками основные операторы языка и наиболее часто используемые функции — то это, как бы, наводит на размышления.

по Джаве как-то встретил ЭТО в чьем-то блоге,
надеюсь, автор не обидится. копипаст:

Чтобы пройти собеседование на Java-программиста в серьезную компанию нужно всего три вещи:

1) Хоть какой-нибудь опыт работы Java-программистом (чтобы было, что написать в резюме).
2) Достойный уровень английского.

3) Правильно ответить на вопросы интервьюера.

I. ООП
1. Назовите основные принципы ООП.
2. Что такое наследование?
3. Что такое полиморфизм? Какие проявления полиморфизма в Java Вы знаете?

4. Что такое инкапсуляция?

II. Java core
1. Опишите модификаторы доступа в Java.
2. Чем абстрактный клас отличается от интерфейса? В каких случаях Вы бы использовали абстрактный класс, а в каких интерфейс?
3. Может ли объект получить доступ к private-переменной класса? Если, да, то каким образом?
4. Какие существуют типы вложенных классов? Для чего они используются?
5. Что такое autoboxing?
6. Что такое Generics?
7. Каким образом передаются переменные в методы, по значению или по ссылке?
8. Какие методы есть у класса Object? Какие методы можно переопределять, а какие нет?
9. Правила переопределения метода Object.equals(). See Bloch «Effective Java» ch 8, 9, 11
10. Правила переопределения метода Object.hashCode().
11. Правила переопределения метода Object.clone().
12. Что такое конструктор по умолчанию?
13. Опишите метод Object.finalize().
14. Чем отличаются слова final, finally и finalize?
15. Опишите иерархию исключений.
16. Что такое checked и unchecked Exception?
17. Как создать свой unchecked Exception?
18. Что такое Error?

19. Опишите работу блока try-catch-finally.

III. Collections framework
1. Назовите основные интерфейсы коллекций и их имплементации.
2. Чем отличается ArrayList от LinkedList? В каких случаях лучше использовать первый, а в каких второй?
3. Чем отличается HashMap от Hashtable?
4. Чем отличается ArrayList от Vector?
5. Обясните отличия между HashSet, LinkedHashSet, TreeSet.
6. Каким образом можно синхронизировать методы HashMap, ArrayList?
7. Особенности интерфейса Set.
8. Каким образом можно отсортировать коллекцию?

9. Как правильно удалить элемент из ArrayList?

IV. Multithreading
1. Каким образом можно создать поток?
2. Какие способы синхронизации в Java?
3. Как работают методы wait и notify/notifyAll?
4. Чем отличается работа метода wait с параметром и без параметра?
5. Как работает метод Thread.yield()? Чем отличаются методы Thread.sleep() и Thread.yield()?
6. Как работает метод Thread.join()?
7. Что такое dead lock?
8. Как правильно завершить работу потока? (Иногда говорять, убить поток).
9. На каком объекте происходит синхронизация при вызове static synchronized метода?

10. Для чего используется ключевое слово volatile?

V. Сериализация
1. Для чего используется ключевое слово transient?

2. Как изменить стандартное поведение сериализации/десериализации?

VI. Swing
1. Что такое Event Dispatch Thread (поток обработки событий)? Как он работает?
2. Как можно производить обработку событий клавиатуры в JTextField?

3. Для чего исользуется класс SwingWorkers?

VII. JDBC
1. Этапы работы с базой данных с использованием JDBC?
2. Как создать Connection?
3. Чем отличается Statement от PreparedStatement?
4. Как вызвать хранимую процедуру?

5. Как правильно закрыть Connection? — блок finally{conn.close()}

VIII. Hibernate

1. Что такое lazy-initialization?

IX. JSP, Servlets
1. Чем отличается redirect от forward?
2. Как сделать redirect незаметно для пользователя?
3. Какие скоупы переменных существуют в JSP?
4. Какие есть методы отправки данных с клиента на сервер? Чем они отличаются?
5. Методы сервлета (обычно имеется ввиду HttpServlet).

6. Чем статический include отличается от динамического? (вопрос по JSP)

X. EJB
1. Какие есть типы бинов?

2. Какие есть типы session bean’ов?

XI. Базы данных
1. Что такое нормализация.
2. Какие есть типы связей в базе данных. Приведите пример.
3. Что такое primary key (первичный ключ)?
4. Что такое foreign key (внешний ключ)?

5. Что такое индексы в базе данных? Для чего их используют? Чем они хороши и чем плохи?

XII. SQL
1. Какие есть типы JOIN’ов. Кратко опишите каждый из типов.
2. Что такое LEFT JOIN, RIGHT JOIN? Чем они отличаются?
3. Для чего используется слово HAVING?

4. Задача: есть две сущности АВТОРЫ и КНИГИ, связь М-М (многие к многим). Создайте структуру таблиц для этих сущностей и напишите запрос, который выберет всех авторов, которые НЕ являются соавторами ни к одной из книг.

Меня собственно не список вопросов интересует. Хотелось бы услышать ваше мнение: что бы вы спрашивали или хотели бы что бы вас спрашивали.

список вопросов как таковой не критичен.
когда идет конкретный разговор о перспективах на конкретную вакансию, то это должен быть разговор, а не набор вопросов.

касательно кода на бумаге, я сам плохо к этому относился, пока пришлось ...
тут важны 2 момента:
1- не пугаться.
2- набросать блок-схему решения задачи в принципе.
дальше, можно писать-черкать код, который в IDE не скомпилится.
важно показать ход решения, алгоритм, знание API.

мелочи не играют роли.

> > мелочи не играют роли

Как сказать. Многие на мелочах как раз и заваливают

Если вас пробуют поймать на «пропущенной точке с запятой», то это минус не вам, а конторе.

Хотелось бы, конечно же, конкретный пример — о каких именно мелочах идет речь. Потому что могут быть, на самом деле, различные сценарии: неадекватное ЧСВ собеседующего, продуманная политика прессинга с целью взять на заниженную зарплату, или же именно эти мелочи оказались действительно важны для того проекта, на который собеседовали.

Вот такая еще ссылка проскакивала в комментариях:

В процессе своего путешествия по разным компаниям насобиралась у меня целая пачка вопросов, которые обязательно следует спрашивать работодателя во избежание последующих недоразумений. Мой список был смёржен со списком, обнаруженным на хабре.

nmihouse.com/?p=31

К «Условия работы, Тип помещения»

наличие и эфективность приточной вентиляции (или альтернативное решение) — если собеседование летом (при отрытых окнах).

Парень из Канады об офисе «окна не открываются, но воздух всегда свежий»!

Подписаться на комментарии