Вопросы для собеседования (php, mysql)

Ну и нагуя оно нужно ? Спрашивай то с чем были трудости у тебя

Меня когда-то просили написать на запросах mysql поиск всех простых чисел от N до M, но это уже извращение.
А так - часто люди не знают разницу между разными JOIN-ами. Ну а по джаваскрипту - традиционный вопрос «Сколько там потоков? Один? А как тогда setInterval/setTimeout?»

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

Любимый сорт пива спроси. Обычно сильно помогает понять, подходит ли чел лично тебе :)

Расскажите о себе

Почему Вы выбрали именно нашу компанию?

Где вы видите себя через пять лет?

тупее вопросов быть не может, ты очередной HH?

А так - часто люди не знают разницу между разными JOIN-ами.

Если честно - это не нужно. Освежается за 5 минут в гугле при необходимости.

php и mysql не собеседую. Если человек утверждет что знаком с JavaScript, даю такую задачку (интересна тем что есть в хорошей книге, которую полезно читать):

var white = new Array(256).join(' '); // что будет в white?

Если утверждает что _хорошо_ знаком с JavaScript, то задачки интересней:

var just_array = [[]+[], []+{}, {}+[], {}+{}]; // что будет в just_array?

alert({vap: 'mau'}); // что здесь происходит?

Ну и конечно спрашиваю как человек управляет сложностью в своих JS-проектах, как пришел в JS, какие книги и блоги читает.

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

Освежается за 5 минут в гугле при необходимости.

было бы что освежать.

Я обычно даю такое как самый минимальный тест на знание БД.

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

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

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

Нужно нарисовать нормализованную схему базы (а еще лучше - написать запросы CREATE TABLE ...), которая бы позволила ответить на запросы типа таких:

• Кто покупал палочки тьмы с 20 по 23 октября этого года?
• Какой покупатель принес магазину больше всего выручки за ноябрь этого года?
• Какие типы палочек есть в текущем ассортименте, но у которых в ноябре этого года продано менее 5 штук?
• Сколько денег выручено магазином в сентябре этого года?
• Тут еще много чего можно придумать по поводу аналитики.

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

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

Рисовать нормализованные базы конечно интересно, но на практике при высоких нагрузках от них толку нуль. Обычно для ускорения запросов все пихается в 2-3 плоских таблички ( как пример резкий рост популярности БД типа MongoDB ).

А насчет CREATE TABLE это ЛОЛ. Вы знаете весь синтаксис диалекта SQL для вашей БД наизусть ?

Ну вот кстати, насчёт CREATE TABLE - это жестоко. Вот пользуют Sequel Pro, и уже просто забыл, как там всё пихать, могу только интуитивно составить.

И как эта задача коррелирует с практикой программирования на Javascript ?

но на практике

пф... собеседование --- это чтоб вообще понять что за человек такой пришел. какие «высокие нагрузки», если человек банальный join не в состоянии из 3-х таблицек слепить?

опять же, твой вариант?

Пусть класс какой-нибудь напишет, объяснит как работает, небольшая выборка с разных таблиц. Для жквери - выборка, применение разных методов.

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

это чтоб вообще понять что за человек такой пришел

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

пять же, твой вариант?

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

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

Есть люди, которые прекрасно решают задачки, но на практике от них толку - ноль.

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

Есть люди которые теряются на простых вопросах, но прекрасно работают в будущем. Так что это все субъективно.

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

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

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

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

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

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

все субъективно.

именно.

но почему-то метод «от простого к сложному» как правило работает лучше всего.

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

Я бы не стал сидеть полгода на голом окладе ( или испытательном сроке - как вас у там это называется ). Такая контора - гавно. Как и контора, которая платит голый оклад - тоже гавно.

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

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

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

Видимо поэтому Ъ Ынтирпайз такой глючный и дорогой ?

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

Загадка про два стула универсальна.

Я бы

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

Не смог выцепить полезное тестовое задание из жиры

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

Ынтирпайз такой глючный и дорогой

с другой стороны за это платят. это работа. это тестовое задание. риальне!

http://ru-scala.livejournal.com/29601.html?thread=187553#t187553

Плагин для эклипса - прекрасное тестовое задание, имеющее связь с жизнью. Ты его не осилил ?

Плагин для эклипса - прекрасное тестовое задание.

подожди, я не понял, на js или sql? это реальный пример из жизни, ты с этим сталкивался и человек берется писать плагины для эклипса?

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

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

?

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

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

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

какие «высокие нагрузки», если человек банальный join не в состоянии из 3-х таблицек слепить?

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

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

Это студент ?

не тому ответил :-)

Я как то устраивался на работу, так мне кидали задачки из жиры. задачки заранее решённые, (т.е. баги закрытие уже). Давали версию из svn где эти баги не пофикшены. Давали ссылки на клоны этих багов в жире с необходимым обсуждением. Было три задачки, одна из них нерешаемая. Вполне себе подход на самом деле.

Возьми на собеседование человека, который у вас занимается такой разработкой

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

Глупый совет. Человек может быть мегаквалифицированным, но не сталкиваться с такой ситуацией - ну и что ты выяснишь? Сам то гуглил небось и трахался непонятное время - ему тоже возможность такую предоставишь? Он может 150 других ситуаций решить нестандартно, или вы можете решить нестандартно по-разному - или собеседовальщик решил, что он умнее собеседуемого по-умолчанию, только потому что он собеседует? Еще тупейшие советы, как делать что-то хитровыпиленное или искать евангелистов собственной шизы, прочитав какую нить хню в интернете и добиваться от человека «почему дивы лучше таблиц».

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

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

Во - пример глупостей о которых я говорил. Ты в работе массивы с объектами складываешь чтоли?

джойны жрут сервер и не нужны

шок! сенсация!!! скачать без смс.

Ты в работе массивы с объектами складываешь чтоли?

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

Это студент ?

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

Молодец, ты меня правильно понял =)

Есть два стула, на одном пики точеные, а на другом фаллосы эрегированные. Куда сам сядешь, куда мать посадишь?

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

Да, таки складываю «массивы» с «объектами».

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

Таблицы лучше дивов, ибо поддержка/отображение в любом движке/браузере будет почти идеально одинаковой и не требующей 100500 хаков на каждый браузер.

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

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

Таблица в тексте HTML называется table. Слитный текст - это span. Плавающий кусок - это div.

HTML, открытый без CSS и JS должен выглядеть как простой текст, а все элементы должны быть названы понятно, в соответствии с содержимым.

Это та же схема, что используется при MVC-like паттернов при создании серверной части сайта. Ты не можешь внести дизайн в Controller (пример грубой ошибки: пронумеровать четные и нечетные элементы таблицы прямо в контроллере, чтобы во view было удобней рисовать «полосатую» таблицу. Контроллер оперирует бизнес-логикой и не должен ничего знать о том, что это будет показано как таблица).

В HTML получается нечто, похожее на MVC. Бизнес-логика лежит в JS, презентация - в CSS, данные - в HTML/XML. Данные в HTML/XML должны быть организованы как семантическая база данных.

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

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

Если верстальщик этого не понимает, то он не нужен.

Если верстальщик этого не понимает, то он не нужен.

Все выше сказанное верно, если бы у браузеров был единый движок. А так для div необходимо заюзать с десяток хаков, чтобы получить одно и тоже отображение во всех браузерах. Таблицы в 99% случаев отображаются всегда одинаково.

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

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