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

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

вакансия - разбираться в обычном наборе LAMP (PHP, Apache, MySQL, Linux) + втыкать прочий широкий профиль разработчика (html, javasript, xml)
работа - натягивать новые дизайны на существующие сайты (что подразумевает нормальную ориентировку в чужом коде), и писать функционал под процессы (к примеру, по документации сварганить платёжный интерфейс со всеми плюшками - поддержка от обрывов, запуск доппроцессов по фиксации оплаты и т.д.)

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

спасибо за внимание.

bars80080

Я лично считаю, что набор следует проводить в два этапа.

1. Тестовая задача
2. Техническое интервью

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

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

Это мое личное мнение.

допустим

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

А какой уровень знаний необходим? Я вообще немного далек от web программирования, но можно в принципе поискать по интернету.

не, понятное дело, что ищется.

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

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

bars80080, http://www.rsdn.ru/article/career/interv.xml

классная штука. очень полезная

осталось найти только аналоги вопросов по C на php и javascript.

хотя вот это

применимо и для php, и особо важно для js

но вот ещё бы по паре каверз

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

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

Читал эту статью на английском. В чем-то я с ним несогласен.
Подобный принцип применяется и в Google, я полагаю в этом причина того, что в их библиотеках и приложениях находятся примитивные недочеты и ошибки. В последнее время часто приходиться править ихние баги в Google Drive SDK, так-что кода написанного гуглом я насмотрелся достаточно.
Может я неправильно понимаю, но когда в coding style guide-е одного из софтварных гигантов написано следующее



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

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

Добавлено через 4 минуты и 51 секунду
Есть и другое мнение насчет тестовых задач.

http://www.brandonsavage.net/why-coding-te...view-technique/

Сложно сказать, что лучше. У каждого свой опыт.

Добавлено через 9 минут и 41 секунду
bars80080

Можно дать написать какой нибудь простенький web-сервис с базой данных.

да, кое с чем можно не соглашаться. но подход в целом имхо верный. мне, например, нравятся не примеры типа strrev, а выводы "если есть сомнения, значит - нет"


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


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

bars80080, есть еще два соображения:
1. проверить текущий технический уровень не так сложно: форма, класс, функция - это уже более чем достаточно для начала обсуждения, а там ниточка потянется... еще важна динамика развития соискателя. спроси, каких авторов по ИТ теме читал соискатель за последние полгода. спроси, кого из наиболее крупных читанных авторов он помнит/уважает. что они написали?
2. прими на работу сам себя. проведи с собой собеседование, давая себе "хорошие" задания, с которыми ты отлично справляешься. потом посмотри на результат критическим взглядом чужого дяди. задай себе вопросы. в результате станет ясно о чем и как спрашивать.

С этим согласен.


Только не знаю почему SDK у них пишут именно те, кто еще много чего не знает.  
Потому у них в потоках возникают не пойманные исключения, которые из своего кода никак не поймаешь и которые кладут весь сервис.
А из за юниоров, за которыми лень следить и обучать вся компания отказалась от исключений. Весело у них 
Если принимать на работу людей, которые умны и могут написать на бумаге strrev, то через некоторое время вся компания будет завалена умными людьми, которые ни хрена не умеют 
Одна довольно серьезная компания в своей базе хранила связь в виде разделенных запятой ссылок на другую таблицу. Т.е.

Может этот программист написал бы strrev с первого раза, но в базах он ничего не смыслил 


Это сообщение отредактировал(а) azesmcar - 26.3.2013, 13:58

Кстати вспомнилось интервью в Яндексе.
Там задали написать сортировку больших (>4Gb) файлов на C++ используя все процессоры и максимум 256Mb оперативной памяти.

Задача была весьма интересная, хоть и непростая. Там точно не час работы был, почти все воскресение просидел.

зато у них можно в шортах, и кинозал есть :P