Собеседование на junior позицию. Антипатерны собеседующих

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

Здесь не будет представлено типичных вопросов-ответов, и наверняка данный материал будет больше полезен собеседующим, нежели тем, кого будут собеседовать. Хотя в конце статьи я выделил несколько, на мой взгляд, хороших правил при проведении собеседования. Думаю, с ними будет полезно ознакомиться всем.
Cтоит заметить, что данный материал не претендует на истину в последней инстанции. На хабре время от времени появляются статьи на данную тематику. Я решил описать поиск работы с позиции junior developer’а, в поисках определенной вакансии, которая соответствовала определенным требованиям (кто сейчас подумал про деньги – у вас плохой подход к набору персонала:)). Для обобщения названия компаний опущены.

Сразу оговорюсь, что я рассматриваю именно собеседования на вакансию junior разработчика, и заранее соглашусь, что многое сказанное здесь может быть не применимо или не так актуально к позиции middle/senior. Все положительные или отрицательные моменты, которые мне запомнились, я решил сгруппировать и дать им название. Получилось нечто похожее на паттерны и антипатерны, с ними я и предлагаю ознакомиться.

Антипатерны собеседования


1) Шаблонные вопросы

Вот скажите на милость, зачем senior программисту а тем более тимлиду утруждать себя выдумывая новые коварные вопросы если можно зайти и просто вбить в поиск что то наподобие ”вопросы на позицию C# junior developer”. Это же так чудесно, когда через секунду ты можешь распечатать эти стандартные вопросы, которые в полной мере отображают требуемые знания. Все мы можем представить идеальный вариант, когда собеседующий программист спрашивает с листа список вопросов с сайта, который кандидат читал 15 минут назад. Тут уж точно можно надеяться на полное взаимопонимание. Конечно, это случается крайне редко, ведь Google/Yandex/Bing не выдают одинаковые результаты кандидатам на вакансию и людям проводящим собеседование.
Если говорить абсолютно серьезно, я считаю что, единственный человек, который имеет право задавать стандартные вопросы – это HR. Все технические вопросы можно и нужно изменить (именно «изменить» а не «заменить»), чтобы заставлять думать отвечающих а не произносить один и тот же текст по сто раз.
Я свое первое собеседование полностью можно сказать провалил, поскольку не ответил на несколько таких вот вопросов, зато второе напомнило мне проверку таблицы умножение. У меня иногда возникало чувство, что собеседующие меня люди и правда читали ту же статью что и я 15 минут назад. Но самое печальное, что кроме этих шаблонных вопросов мне так ничего и не задали.

2) Зачем спрашивать по вакансии?

Данный антипатерн, как мне подсказывает логика, встречается крайне редко. Но когда он вам попадется, знайте вам попалась большая удача. Когда дорастете до тимлида сможете рассказывать истории в стиле а вот мне как то раз на собеседовании….
Суть его заключается в банальной вещи. Вас просто не спрашивают по вакансии. Вообще:). Все, что Вы готовили, все к чему готовились, оставьте при себе. Бывает такое, когда в компании просто нет специалистов вашего направления, но зато есть другие хорошие специалисты. Скажем в компании нет iPhone программистов, зато есть Android разработчики, которые с удовольствием поспрашивают вас о тонкостях activity lifecycle). Сюда же можно причислить замечательный вопрос собеседующего: “Я не знаю как это реализовано на языке X, но на языке Y это реализовано так и так. Сравните мне, пожалуйста, реализации.”
Учитывая, что вы идете как раз на позицию junior разработчика, возникает резонный вопрос: а у кого собственно вы будете учиться и на чьем примере повышать свой скил? На этот вопрос антипаттерн ответа, к сожалению, не дает.

3) Проведем собеседование всей компанией)

Хорошо когда вас в начале собеседования PM рассказывает о проекте и компании и параллельно исполняет роль HR (за отсутствием такового). Плохо когда потом при техническом интервью, когда тебя должен спрашивать тех. специалист, PM сидит рядом и внимательно смотрит то на тебя то на тех. специалиста. Опять же из собственного опыта, мне кажется, что на таком собеседовании технарь переживает даже больше нежели тот кого собеседуют. По сути, он же проводит собеседование на глазах у начальника). К тому же в данном случае тот кого собеседуют толком не знает кому лучше отвечать. Если вообще игнорировать PM, то получается что то вроде допроса под. наблюдением за стеклом, только без стекла.
Этот антипатерн скорее мое личное убеждение как должно протекать собеседование, но все же, может, кто то найдет его резонным.

4) Повторенье мать ученья.

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

5) Никогда не давайте тестовые задания домой. Никогда!

Думаю, тут пояснять ничего не нужно. Опять же зачем тратить драгоценно время работающих людей для разбора чьего-то тестового задания. Ведь на собеседовании все уже выяснили, и главное, что человек согласился работать за еду). Подумаешь, сущий пустяк, что у него все переменные называются не длиннее 5 символов (3 из которых обычно одинаковые).
Да и вообще опять же это тестовое задание нужно еще придумывать, и кто этим должен заниматься? А что, тимлиду больше всех надо? У него и так работы хватает. Кандидат же ответил правильно на все вопросы на собеседовании (опять вспоминаем первый антипатерн). Подумаешь, большое дело, что человек не понимает почему нужно писать
List values = new ArrayList(); вместо ArrayList values = ….;
Ну и кому же не хочеться увидеть названия в стиле ArrayList arrayList = new ArrayList(); и улыбнуться. Жаль только, что с применением данного антипатерна, все эти, вызывающие улыбку, вещи обычно обнаруживаются после приблизительно месяца работы.
Существует также частный случай. Когда предлагают выполнить какое нибудь “легкое” задание тут же. Конечно, при этом кандидат должен за секунду привыкнуть к новой раскладке (идеально если это еще и нетбук, чтобы кандидат смог показать весь свой solve problem скил), и если этого окажется недостаточно, можно еще дать другую среду разработки (да для .Net не много вариантов:), но есть же блокнот. Ведь я надеюсь все знают как компилировать С# программу через консоль?)

6) Та это вообще не проблема.

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

BestPractices собеседования


Не секрет, что подход к разработке ПО меняется со временем. Так же меняется и подход к найму сотрудников. И если HR’ы, хоть как то стараются улучшить свои навыки собеседования (я в это искренне верю, все таки им за это деньги платят), то с технической стороны вопросы «Чем отличается ArrayList и LinkedList?” еще долго не уйдут со сцены. Сейчас я хотел бы привести несколько пунктов, из которых, по моему мнению, должно состоять хорошее собеседование.

1) Распараллеливание задач.

Сразу оговорюсь, что это довольно специфический пункт. Особенно для вакансии типа junior. Но так как я искал работу мобильного разработчика, то он подошел идеально, когда на технической части меня собеседовали двое специалистов. Один спрашивал стандартные вопросы по языку, коллекциям и паттернам. Короче стандартное junior stuff интерв’ю. А второй специалист спрашивал именно по тонкостях мобильной платформы.
Сразу виден минус для компании в виде потери работоспособности сразу двумя сотрудниками, но с другой стороны исключается субъективное мнение и интервьюеры имеют больше возможностей лучше подготовить свою часть.

2) Про все что вы не спросили – должен рассказать вам HR.

В описании одного антипатерна я оговаривал, что единственным человеком со стандартным набором вопросов должен быть HR. Причем он должен сказать вам ответы на эти вопросы, даже если вы их (вопросы) не задали. Почему-то никто не забывает оговорить размер ЗП, но не все вспоминают спросить про рабочий график, дрескод, возможность командировок, оплаты за переработки и т.д. Собственно тут вина частично ложится и на плечи того кто ищет работу. Ведь компания не может знать, что вас устроит, а что нет, поэтому лучше всего, если вы это будете выяснять заранее и сами. Думаю, само собой понятно, что обязанность HR’а также рассказать и про все плюсы, которые присутствуют в компании.

3) Все плюшки компании сразу.

Я думаю HR’ам не нужно рассказывать как хантить людей. Но штука в том, что хантить на позиции junior никто обычно и не спешит. И, обычно, кандидат узнает о компании максимум информации именно при собеседовании с HR’ом (исключая конечно крупные компании и всевозможные порталы с отзывами). Когда-то слышал в одном интервью, что компания предоставляла место в детском саду и это было неслабым бонусом для «семейных» программистов. Если вы даете MacBook и Android девайс в личное пользование, не забудьте сказать об том. 2 монитора на рабочем месте тоже преимущество. Поверьте, так и есть. На хабре была одна статься про стулья. Так вот там были ссылки на стулья вплоть до 1000$. Не каждый программист позволит себе такой даже домой. Бывал я в компаниях, где такие стулья у каждого и никто не сказал об этом как о плюсе компании(!!).

4) Четко определенные цели и задачи.

Здесь хорошо если обе стороны понимают что они хотят от кандидата/позиции.
Компания, которая берет себе junior программиста должна четко понимать, кого она хочет из него сделать через лет 3-4. Приблизительно это понимание и должен рассказывать кандидату HR или PM. Хорошо если кандидату объяснять чем он будет заниматься на ближайшем проекте, но еще лучше если ему расскажут что из него выйдет через год – полтора работы на данной должности (опять же, если все, что вы можете сказать это «зарплаты будут выше средних по рынку», то я бы к вам в компанию не пошел).
Кандидату важно понимать, что он хочет от этой работы. Я понимаю, что многие устраиваются работать на позицию junior фактически на первую работу, набраться опыта в ООП, в работе в команде, поучаствовать в реальном проекте в конце концов. Но почему то мало кто осознает, что эта первая работа определяет все дальнейшее карьерное развитие (в большинстве случаев) и ваш профессиональный язык в программировании. Сейчас поясню на примере. Скажем вы любите программировать на java и довольно неплохо знаете этот язык, но на 3 курсе находите работу (читаем: вас готовы взять) только junior C# програмиста. Ну и что вы пойдете или нет? Я бы пошел, и приблизительно 2 года познавал тонкости .Net программирования. И вот вы заканчиваете этот осточертевший за 5 лет универ и у вас в запасе 2 года .Net программирования, вполне возможно что вы уже и не junior вовсе. И захотите вы менять работу чтобы снова стать junior программистом но уже java junior? Конечно нет. Если вы четко уверены, что хотите быть, скажем, iPhone разработчиком, то очевидно вам нужно искать вакансию не “Android/iPhone/WinPhone developer” а четко “iPhone developer”. Надеюсь, мне удалось донести мысль.

5) Вопросы по вакансии, а не по резюме.

Этот пункт напрямую касается предыдущего пункта с точки зрения компании. Конечно каждый несет ответственность за то, что у него написано в CV. И я понимаю, что если у меня указаны C++ или JavaScript меня могут спросить по любому из этих языков, даже если они не есть моими профильными.
С другой стороны компания должна понимать кто именно ей нужен. И если в случае с маленькими компаниями человека могут брать как универсального разработчика (соответственно чем больше у него всего указано в резюме, тем лучше), то большие компании должны быть заинтересованы в найме высококвалифицированных узкопрофильных специалистов. Мы все знаем, как выглядит типичная вакансия, скажем, на middle позицию. Но я ни разу не был на собеседовании, на котором спрашивали все, то что указано в вакансии, зато меня не раз спрашивали по всему поему CV, где половина всего вообще никак не связана с желаемой должностью. К сожалению, так бывает в большинстве случаев. Здесь возможны 2 варианта, либо компания не понимает кто ей нужен, либо ей подходят абсолютно все и вакансию HR набросал копи пастом за 10 минут.

6) Не надо ждать фидбэк. Никогда.

Я долго думал написать по этому пункту тут, или в антипатернах.
Думаю ни для кого не секрет, что письмо по результатам собеседования в компании дает очень много опыта (особенно если это письмо с отказом, особенно если там указываются причины отказа). Особенно много опыта дает наличие ответного письма как такового). Поверьте, компания, которая проводит грамотную переписку, заметно выделяется на фоне остальных.
Может возникнуть резонный вопрос, чем это письмо так важно? Для ответа на этот вопрос стоит немного отойти от основной темы. Я позволю себе процитировать Якова Файна: “Поиск работы состоит из 4 ступеней. Составление резюме. Поиск вакансии. Прохождения собеседования. Рассмотрения предложения”.
Вы же не будете соглашаться на первый попавшийся вариант (или будете?). Поэтому нужно всегда держать в уме в желательно еще на собеседовании согласовать с HR’ом, когда стоит ждать фидбэка. Каждый кто хочет найти работу (не просто работу, с которой он уйдет через пол года, а правда хорошее место), должен приблизительно представлять когда у него будет основная часть результатов собеседований. Другими словами, если я за две недели был на 20 собеседованиях (пусть некоторые дают ответ через неделю, некоторые через 2), то я понимаю что в конце месяца уже можно и нужно выбирать job offer. И идти в конце третьей недели на собеседовании глупо (если это конечно не гугл:)), или хотя бы нужно сразу договариваться, а сроках фидбэка, поскольку, пока вы будете ждать результата собеседования с этой компании, все другие предложения о работе могут стать неактуальными.
Был случай, когда после двух недель я решил поинтересоваться результатами моего собеседования (в большей степени меня тогда интересовало, где именно у меня были пробелы и что мне следовало подтянуть для последующих собеседований). После переговоров с PM’ом в скайпе он пообещал выяснить, почему ответное письмо не было отправлено и пообещал, что я получу фидбэк в скором времени. Сейчас, по прошествии почти трех месяцев, письма я так и не получил).

7) Определение размера ЗП и сроков ее пересмотра.

Да я полностью согласен, что junior не должен гнаться за зарплатой. Но компания работодатель должна понимать реальную ситуацию. Скажем одно дело, если предложить ЗП на процентов 10-20% ниже среднерыночного и совсем другое, если Вам предлагают работать за все лишь эти 10-20% от средней зарплаты. В больших компаниях все проще. Все знают, что там пересмотр зарплаты 2 раза в год. К тому же, крупные компании, как правило, готовы сразу платить неплохие деньги на junior позиции. По крайней мере туже средне рыночную ЗП там можно просить без зазрения совести. Просто поскольку крупная компания может себе позволить вложить в вас деньги авансом.
Маленькая же компания обычно не готова покупать кота в мешке. Довольно часто приходиться слышать слова «у нас гибкая политика пересмотра зарплат», «когда я вижу результат, так сразу зарплата и повышается» и т.д. Можно конечно войти в положение маленьких компаний, к тому же junior’ы, по моему убеждению, должны работать на набор опыта, а не зарплаты. Но все же, совсем по-другому воспринимаются, например такие слова «сейчас твоя зарплата будет такая, но после 3 месяцев мы ее пересмотрим, основываясь на твоей работе». Неплохо также, когда при собеседовании обговариваются две сумы, одна на испытательный срок и основная ЗП.

8) Идеальные вопросы.

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

Пример кода;

Например, спросить, что выведет код, объяснить почему. Взять хотя бы такой вот:
public class Main {
    String variable;
    public static void main(String[] args) {
        System.out.println("Hello World!");
        B b = new B();
    }

    public Main(){
     printVariable();
    }

    protected void printVariable(){
        variable = "variable is initialized in Main Class";
    }
}

public class B extends Main {
    String variable = null;

    public B(){
        System.out.println("variable value = " + variable);
    }

    protected void printVariable(){
        variable = "variable is initialized in B Class";
    }
}

А что будет если вместо String variable = null; написать просто String variable; ??
Такой код, заставляет думать, и он явно показывает как тот кто отвечает ориентируется, в данном случае, в полиморфизме и выделении памяти в JVM.

Cтатьи на хабр;

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

Есть ли акаунт на github;

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

Последняя прочитанная техническая книга;

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

5 любимых рефакторингов;

Чаще всего используемые комбинации в IDE;

Эти два вопроса я оставил напоследок, так как они, наверное самые нестандартные из всех приведенных выше. Хотелось бы мне увидеть лицо человека, которого спросили эти два вопроса, особенно если он абсолютно не знает на них ответа, зато знает, чем отличается ArrayList от LinledList’а :). Я убежден, что они всего лишь действительно позволяют находить программистов из всей той массы людей которые приходят к вам на собеседования. Ведь есть люди, которые занимаются этим, потому что это им интересно, а есть люди, которых просто привлекают перспективы IT сферы и существующие здесь зарплаты. Просто ответив на эти два вопроса, человек может показать программирует он что либо для себя или просто сидит и ждет, когда попадет на работу (иногда правда почитываю для разнообразия «Основные вопросы на junior собеседовании»).

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

Сразу отвечу на возможный вопрос в комментариях, что да – работу я нашел. И даже не одну)). Если у кого то есть свои примеры хороших паттернов/антипатернов – прошу в комментарии.
Share post

Similar posts

Comments 293

    +7
    Солидное полотно однако:)

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

    Стандартные вопросы тоже не стоит оставлять без внимания. Вот например типичный диалог
    — Что такое интерфейс в php (java, etc..) и зачем он нужен?
    — Для реализации множественного наследования
    — Так какой в этом смысл? Интерфейс содержит только сигнатуры методов, в итоге в классе все равно нужно будет заново объясвить эти методы и написать их код. Зачем такое наследование вообще нужно?
    — …
    Посему даже со стандартными вопросами можно понять, разобрался человек или просто забил свою голову различными комбинациями слов
      +4
      на самом деле, пример который вы описали как раз и не входит в «шаблонные» вопросы. шабонным и бородатым будет вопрос «чем отичается абстрактный клас и интерфейс?»
      А вот четко сказать «зачем нужны интерфейсы?» не так уж и просто. Когда я отвечал на подобный вопрос меня прервали на полуслове со словами «ну juniorу это знать не обязательно»))
        0
        В плане примеров из жизни можно проще — объяснить своими словами, а не фразами из книги. Сразу увидите как человек излагает мысли.
          +31
          Я вот статье просто поражаюсь. Человек даже еще не начал работать джуниором (о руководстве и речи не идет), а уже выкатывает простыню с заключениями о том, как нужно правильно нанимать. Без тени сомнения, главное. Это что, тенденция такая?
            +2
            Моя статья не свод правил, как Вам могло показаться, а просто замечания с которыми думаю многие из нас сталкивались.
              +14
              Хуже. Это правда жизни. Все он верно описывает.
              При прочтении антипаттернов я сразу же узнал все приемы своего руководства. Причем сам никогда не понимал почему именно так нанимают.
                0
                Они возникают на плохом рынке, когда оптимальная стратегия лежит в оппортунистическом поведении, причем для обоих сторон при отсутствии регулятора. Гуглите lemon law и откуда он взялся.
                  0
                  Может всё же не все антипаттерны из статьи — в действительности антипаттерны?
                    0
                    IMHO зависит от интенсивности применения.
                    Меня вот собеседовали суммарно 5 человек на трех собеседованиях + был неоплачиваемый тестовый день. Нагоняет стресса, честно сказать… создает впечатление о компании как о весьма серьезной. До того работал в мелкой частной фирмочке с 4мя прогерами на 30 сотрудников… там как-то проще было… хотя туда меня и брали студентом на задачи, от которых 10 человек уже отказались, а те кто не отказался — хотели нормальных денег… чего от меня хотеть то было…

                    На словах — «все решаемо!». На практике у меня убогий стол, за которым устает спина, три переезда между комнатами за год работы со сменой столов — начал работу за тем же столом, за которым сейчас работаю. Тихий ужас. Руководству похрен. Отмазка «ну так мы ж работаем над заменой мебели!!!». Ага… 150-160 сотрудников, год не могут столы заменить… ага… работают…

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

                    По вакансии спросили следующее:
                    1. Работал ли с Qt? Как долго?
                    2. Знаю ли я что такое матрица трансформации?
                    3. COM?
                    4. Паттерны?
                    5. Знаком ли с Linux?

                    Все. Ни задач, ничего.

                    Зато один (по моему опыту работы здесь — самый толковый из руководителей проектов) долго и упорно обсуждал со мной мои предыдущие проекты, как и что и почему я делал. Видимо, это и было важно для него. Вот с ним было да, интересно. Да и вообще дядька клевый. И по делу, и не пытался доминировать или показать какой он умный и т.п. При общении и так было понятно все.

                    Но он не мой руководитель…

                    Вот как-то так… 1 этап толковый, остальные все попали в описанные антипаттерны. И попали из-за своей неуместности в тех случаях, когда они применяются.
                • UFO just landed and posted this here
                    0
                    Между тем человек дело говорит. Поверьте моему немалому опыту найма программистов.

                    Да, когнитивный диссонанс между «джуниор» и этой статьёй возникает.

                    Я бы этого кандидата, пожалуй, взял :)
                    +1
                    На вопрос по интерфейсам бывает даже миддл программисты затрудняются корректно ответить. Интерфейсы хитрый способ решить проблему множественного наследования. В Ruby этот вопрос решается через модули и такой способ гораздо понятнее, чем интерфейсы.
                      +2
                      Повторяя свой комментарий, на вопрос Вы ответили так же, как джуниор.Только модули руби какие-то приплели
                      Посему следующий ход
                      — Так какой в этом смысл? Интерфейс содержит только сигнатуры методов, в итоге в классе все равно нужно будет заново объясвить эти методы и написать их код. Зачем такое наследование вообще нужно?
                        0
                        У Вас вопрос сформулирован как то нечетко что ли. Какой смысл в наследовании от интерфейсов? или какой смысл в наследовании вообще? или есть наследование классов, какая роль у интерфейсов в этом? Согласитесь корректно и хорошо сформулированный вопрос повышает вероятность получить корректный ответ ). Что касается руби, так если джуниор знает о модулях в руби, а вы нет, разве это плохо? мне кажется наоборот плюс, он может сравнить два подхода, а вы нет.
                          +2
                          Примеси в руби и интерфейсы в языках со статической типизацией — это абсолютно разные вещи и нужны для решения разных проблем.

                          Корректное сравнение подходов — подход с интерфейсами и подход с «утиной» типизацией.
                            0
                            Для меня концепция примесей или модулей абсолютно понятная и простая, а вот с интерфейсами до сих пор какие то проблемы. Буду признателен, если скините ссылочку на материал где эта концепция четко ясно и просто сформулирована или объяснена.
                              +1
                              Немного не в тему, но определение интерфейса из википедии — это отличный пример того, как писать не надо…
                                +5
                                Интерфейсы нужны для двух вещей:
                                1. Наследуя от интерфейса вы гарантируете, что у экземпляра класса есть некий определенный набор методов.
                                2. Так как наличие метода гарантировано, вы можете дернуть за него не зная класс, а зная только интерфейс.

                                Это очень похоже на то, зачем в ruby есть «утиная» типизация (если у объекта есть метод, вы можете его вызвать не зная к какому конкретному классу относится объект), только с той разницей, что если у объекта нет метода в ruby у вас будет эксепшн в рантайме, а, например, c# выдаст ошибку еще на этапе компиляции.

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

                                Посмотрите «принцип разделения интерфейсов» из SOLID, он проясняет смысл хорошо ;)
                                  –3
                                  Мне кажется ни пункт 1 ни пункт 2 не отвечают на вопрос зачем нужен интерфейс, а рассказывают больше как интерфейс работает. Какой все же ответ на вопрос, зачем/для чего нужен интерфейс?
                                    +8
                                    Для того, чтобы гарантировать, что класс соблюдает контракт (содержит определенный набор методов).
                                      0
                                      а абстрактный класс делает тоже самое? значит он тоже интерфейс?
                                      а базовый класс?
                                      погодите, я запутался :)
                                        0
                                        Абстрактный класс нужен для того, что бы человек, который реализовывал, соблюдал заложенные в него соглашения.
                                        Другими словами.
                                        Абстрактный класс — декларация соглашений на расширение системы.
                                        Интерфейс — это соглашение по использованию системы.
                                          0
                                          Абстрактный класс — декларация соглашений на расширение системы.
                                          Через абстрактные классы можно тоже использовать систему без проблем.

                                          Интерфейс — это соглашение по использованию системы.
                                          Интерфейс вполне может быть соглашением на расширение системы.

                                          Абстрактный класс нужен для того, что бы человек, который реализовывал, соблюдал заложенные в него соглашения.
                                          Реализовывают интерфейсы, а не абстрактные классы. И они оба нужны, чтобы соблюдали соглашения, которые они декларируют.

                                          Я надеюсь вы понимаете, что Ваше высказывание не выдерживает критики.
                                            0
                                            Через абстрактные классы можно тоже использовать систему без проблем.
                                            Интерфейс вполне может быть соглашением на расширение системы.

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

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

                                            Да, наверное ранее я слишком скомкано объяснил. Но понимание к вам придет со временем — это нормально.

                                              0
                                              Да, наверное ранее я слишком скомкано объяснил. Но понимание к вам придет со временем — это нормально.
                                              Ко мне то придет конечно, меня беспокоит, что к Вам оно может не прийти.

                                              Интерфейс указывает как использовать данный класс.
                                              Интерфейс не принадлежит классу и ничего не знает о классе. Значит он не может указывать как использовать данный класс.

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

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

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

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

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

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

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

                                                  Я именно поэтому и говорил, что использовать интерфейс для упрощения работы с классом — это не совсем правильное его использование. Эту проблема обычно видна как набор классов с одноименными интерфейсами, которые они поддерживают. Или даже просто классы и их интерфейсы рядом в одной библиотеке. Для упрощения интерфейса доступа есть механизмы фасадов и т.д.
                                                  Фактически класс тоже имеет интерфейс — это набор его публичных полей. Чем он плох?

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

                                                  Под разработчиком я понимаю конечность какой то код — который использует интерфейс.

                                                  Тяжело мне понять вашу линию мысли, как вы пришли к этому от typehint'инга.
                                                  Видимо я просто неправильно понял что такое тайпхинтинг. Никогда не слышал про такой термин.
                                                  Не могли бы Вы пояснить что это?

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

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

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

                                                    Видимо я просто неправильно понял что такое тайпхинтинг. Никогда не слышал про такой термин.
                                                    Не могли бы Вы пояснить что это?
                                                    Контракт аргумента метода/конструктора.
                                                    class MyClass {
                                                        constructor(service: IHintingClass) {
                                                          // ...
                                                        }
                                                    }
                                                    


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

                                                    Абстрактный класс уже заключает в себе логику, а абстрактные методы показывают пути изменения/установки поведения наследников. Например, абстрактный класс может потребовать реализовать protected метод.
                                                    interface IStackSorter {
                                                       setStack(stack: IStack);
                                                       getSortedStack(): IStack;
                                                    }
                                                    
                                                    abstract class AStackSorter implements IStackSorter
                                                    {
                                                    //...
                                                       abstract private sort(a: IItem, b: IItem): Boolean
                                                    }
                                                    

                                                    Теперь, предположим что интерфейсы могут объявлять private методы:
                                                    interface IStackSorter {
                                                       setStack(stack: IStack);
                                                       getSortedStack(): IStack;
                                                    }
                                                    
                                                    interface AStackSorter {
                                                       private sort(a: IItem, b: IItem): Boolean
                                                    }
                                                    

                                                    Каким образом вы можете логически связать два этих кусочка кода?

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

                                                    Итак, вывод:
                                                    И табуреткой можно убить, но является ли оно холодным оружием?
                                                      0
                                                      хм. У меня тут складывается ощущение, что спорит дельфист с сишником, оба в своих терминах. В Си интерфейсы изначально (а то и по сей день) реализуются объявлением абстрактного класса и множественным наследованием. В Дельфи интерфейс — отдельная синтаксическая единица, и множественно унаследовать класс может только эти интерфейсы.

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

                                    Собственно интерфейсы не наследуют, а реализуют.

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

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

                                    И для того, чтобы это понимать никакие Солиды вам знать не надо. Элементарные вещи.
                                      0
                                      Знать не надо, но это знание сильно помогает составить общую картину.
                                      0
                                      Я бы добавил сюда ещё то что интерфейс нужен для того, что бы можно было показать принцип работы системы заложенный разработчиком.
                                      +2
                                      Интерфейс — контракт. Абстрактный класс — прототип. =) Собственно с этой точки зрения можно и смотреть.
                                        0
                                        То есть они оба могут быть контрактами. Вопрос в том, кто диктует контракт — сам класс или тот, кто его использует.
                                          +1
                                          Согласен. Просто надо чуть шире и абстрактнее смотреть на вещи и код засияет новыми красками =)) Ну или потечет… как знать… ;)
                                    +1
                                    Кстати, вопрос специально всё же сформулирован «нечётко что ли». Я сам поступаю так на собеседованиях. Да, на хорошо сформулировав вопрос я с большей вероятностью получу верный ответ. Но моя цель — не получить верный ответ, а проверить пригодность конкретного человека на конкретную позицию. Мне не нужны шаблонные ответы на шаблонные вопросы. Хочется понять, сможет ли кандидат в условиях невозможности постоянной коммуникации с коллегами, нехватки точности и непротиворечивости в требованиях и целях задачи сопоставить в голове все варианты, их плюсы-минусы и осознанно найти компромисс. И можно ли будет доверять выбранному решению, т.к. не всегда есть время отмести его в зачатке.
                                  0
                                  Я не Java разработчик, но даже я знаю, что Java не поддерживает множественное наследование.
                                  А интерфейсы, конечно же, нужны для унификации вызовов к объектам базового класа в тех случаях, когда мы не хотим даже знать, с каким именно дочернего класса объектом мы работаем. Т.е. цель — обращение к любому наследнику интерфейса как к объекту класса интерфейса без необходимости знать точную его реализацию.
                                    +1
                                    Да-да, типичное заблуждение ;)
                                      0
                                        +1
                                        Нет, я о том, что интерфейсы нужны НЕ для множественного наследования.
                                          0
                                          аааа, ну так это конечно же :)
                                            0
                                            Для чего же они тогда нужны? В двух словах поясните )
                                              0
                                              Я вот нашел по этой ссылочке. «Вместо множественного наследования классов в Java введено множественное наследование интерфейсов, при котором, как утверждается, никаких проблем не возникает.» Разве не об этом я сказал? что интерфейсы решают проблему множественного наследования? или они не решают ее )?
                                                +4
                                                Так я выше написал, что это «типичное заблуждение». Интерфейсы проблему множественного наследования не решают никак.
                                                  +2
                                                  Интерфейсы не решают проблему множественного наследования, но множественное наследование иногда используется для решения проблемы отсутствия интерфейсов (например в C++).
                                                    0
                                                    Откуда вы взяли «например в С++»?
                                                    В С++ очень даже есть интерфейсы.
                                                      +3
                                                      О_о
                                                        0
                                                        Что, прямо-таки на уровне языка, отдельной конструкцией? Давно не касался C++, возможно что-то поменялось в последних стандартах. Сколько помню, в плюсах интерфейсы всегда реализовывались абстрактными классами с чисто виртуальными методами.
                                                          0
                                                          А в случае C вы можете то же самое утверждение привести со спуском до ассемблера.

                                                          Википедия вам в пруф того, что вы надумали лишнего.

                                                          Мы возвращаемся к вопросу и сразу ответу так чем же отличается абстрактный класс от интерфейса?

                                                          И вы как раз не провели черту между абстрактным классом и интерфейсом. Потому что чисто виртуальных методов не достаточно для того чтобы абстрактный класс стал интерфейсом.
                                                            +3
                                                            Классов тоже нет. Есть нули и единицы. Да и их нет.
                                                              +3
                                                              Все фигня, кроме пчел. Да и пчелы тоже фигня.
                                                              0
                                                              Вы правда дали ссылку на статью, в начале которой сказано «опишу эти отличия детально. Все перечисленное касается PHP» ???
                                                              omg
                                                                0
                                                                Нет конечно. Я и не говорил нигде, что это касается PHP. Последние 2 левела разговор за c++.
                                                                0
                                                                Интерфейс как концепция, разумеется, существует везде, где существует ООП. Интерфейс, как отдельная фича языка — существует не во всех языках. Например, в C++ (в общем случае, когда класс поддерживает более одного интерфейса) интерфейсы реализуются обычно на уровне паттерна «открытое наследование от абстрактного класса с чисто виртуальными методами».

                                                                Так что я где напутал?
                                                                  0
                                                                  Интерфейс — открытый чисто абстрактный класс (нет реализации ни одного метода) без полей.
                                                                  Не «содержит абстрактные методы», а «не содержит методов с реализацией».
                                                                  Похоже, в игре слов начинаем путаться и придираться.
                                                                    0
                                                                    Абстрактный класс по умолчанию содержит чисто виртуальные методы, так что явно их упоминая я, конечно, имею в виду что все методы собственно интерфейса (в смысле концепции) чисто виртуальные (pure virtual). Как пишут вот тут: stackoverflow.com/a/318137 деструктор, все-таки, стоит объявлять нечистым. При этом я не считаю конструктор и деструктор частью собственно интерфейса, но это вообще вопрос спорный.
                                                                      0
                                                                      Мне кажется, предмета спора нет, и вся проблема как обычно в формулировках.
                                                                      В с++ АК может содержать реализованные методы. И это удобно. Но это деталь реализации.
                                                                      А интерфейс это всё-таки просто контракт. Никаких деталей реализации.
                                                                      0
                                                                      Значит, в C++ используется более мощная конструция. Не просто перечисление абстрактных методов, но и сразу реализация методов, которые могут быть выведены из базовых. Более надёжный способ, чем заставлять каждый класс, поддерживающий данный интерфейс, реализовывать их заново. Хорошо, что C++ это позволяет. Интересно, как это грамотно сделать в C#.
                                                                        0
                                                                        Если не ошибаюсь, в c# ведь можно объявлять абстрактные методы, это автоматически делает класс абстрактным. Почти никаких отличий от плюсов.
                                                                          +1
                                                                          Такой «интерфейс» (с дополнительными методами) может быть только один — ведь множественного наследования нет.
                                                                            0
                                                                            И это хорошо!
                                                                              +1
                                                                              Так можно дойти до того, что «класс может иметь только один интерфейс» :)
                                                                            –1
                                                                            >в c# ведь можно объявлять абстрактные методы, это автоматически делает класс абстрактным

                                                                            Сам класс абстрактным от этого не становится. Просто данный метод можно вызвать абстрактно.
                                                                              +3
                                                                              Вы решили под вечер сломать мне мозг?
                                                                              Как это — абстрактно вызвать метод?
                                                                              И почему класс с абстрактными методами автоматически не становится абстрактным?
                                                                                0
                                                                                Пардон, это я уже туплю и со статическими методами напутал. Абстрактный метод конечно вызвать нельзя :)
                                                                                  0
                                                                                  Как это его вызвать нельзя? А зачем тогда нужен метод, который нельзя вызвать?
                                                                            0
                                                                            Через extension methods.
                                                                          +1
                                                                          Интерфейс существует задолго до того, как существует ООП. Какая-нибудь табличка функций драйвера, позволяющая другим программам общаться с ним, не зная структуры и реализации — это уже интерфейс. А никаких классов на этом уровне развития и в помине нет, всё программирование процедурное. Может быть, даже на ассемблере. При чём же тут ООП вообще?
                                                                            0
                                                                            Если вы еще раз перечитаете коммент, на который отвечали, то увидите, что я утверждал, что там, где существует ООП, там есть и интерфейсы (явно или неявно), и нигде не утверждал, что интерфейсы существуют лишь там, где существует ООП. Так с чем вы спорите?
                                                                  0
                                                                  Проще пример привести…
                                                                  К примеру… есть графическая сцена.
                                                                  На сцене все элементы (допустим, будут классы Line, Ellipce) должны иметь свой уникальный идентификатор (вот вам один предок SceneItem), должны быть графическими объектами не обязательно одного типа (вот вам второй уже «уникальный» предок GraphicsItem, в " т.к. в целом не обязательно), а еще каждый элемент должен иметь простейший интерфейс (например, fitToPage() и setBackground(...)) — вот вам третий предок PolymorphicItem.

                                                                  Если бы интерфейсы решали проблему отсутствия множественного наследования — программист мог бы хранить указатели на PolymorphicItem там, где ему нужно только это и т.к. Это и есть заблуждающая сторона :)

                                                                  А теперь вспоминаем, что у объектов есть и общий функционал в классах Sceneitem и GraphicsItem.
                                                                  И вот когда нам нужно знать об объектах не более, чем то, что они элементы класса GraphicsItem, нам нужно множественное наследование, а интерфейсы уже ничем не помогут.

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

                                                                      И как предлагаете этот функционал разделять по разным объектам, если объект на сцене должен быть один?
                                                                        0
                                                                        Вы не думали, что ваш пример можно архитектурно построить таким образом, что множественное наследование не понадобится?
                                                                        Вы слышали про GoF, к примеру?
                                                                          0
                                                                          Да. Данные о фоне и данные о положении в сцене — разные ответственности.
                                                                            0
                                                                            Т.е. по вашему графический элемент не должен иметь своего, например, фона одновременно с возможностью быть, например, перемещенным по сцене? Вот это точно странно.

                                                                            А вы посмотрите как сделано в LibCanvas. Там тоже сначала всё было через примеси (множественное наследование). Были примеси для событий, для реализации drag и примесь для отрисовки. В итоге всё это превращается в кашу.

                                                                            Сейчас есть отдельно классы шейпов. Они не имеют ни цвета ни формы. Зато имеют публичный интерфейс, одинаковый между собой.

                                                                            Всё остальное решается через делегацию. Раньше события вешались так:
                                                                            element.addEvent({ click: function () {} });
                                                                            

                                                                            Теперь так:
                                                                            element.events.add({ click: function () {} });
                                                                            


                                                                            Размер кода не поменялся, а множественного наследования больше нету.
                                                                            Какого фига у такого графического примитива, как Line должно быть setBackground?

                                                                            У вас должен быть контейнер, который знает о каждом из подчинённых и их соединяет вместе, при необходимости делегируя эти полномочия классам-хелперам:

                                                                            declare( 'Item', {
                                                                                
                                                                                initialize: function (layer, shape) {
                                                                                    this.layer = layer;
                                                                                    this.shape = shape;
                                                                            
                                                                                    this.events = new Events(this);
                                                                                    this.draggable = new Draggable(this);
                                                                                },
                                                                            
                                                                                isTriggerPoint: function (point) {
                                                                                    if (this.shape instanceof Line) {
                                                                                        this.shape.distanceTo( point ) < 10;
                                                                                    } else {
                                                                                        this.shape.hasPoint(point);
                                                                                    }
                                                                                },
                                                                            
                                                                                renderTo: function (ctx) {
                                                                                    ctx.fill( this.shape, 'red' );
                                                                                }
                                                                            
                                                                            });
                                                                            
                                                              +1
                                                              Что касается странной дискуссии здесь и далее о множественном наследовании, рискну высказать свою точку зрения о том, что ни интерфейсы, ни классы не нужны для множественного наследования. Все втроём нужны, чтобы эффективно решать практические задачи. Которые достаточно часто нормально и без наследования решаются, и проще при этом.
                                                              0
                                                              За 2 года я встретил 1 человека, который смог мне показать свою учетку в SO. Про GitHub и Habr молчу. Уже особо и не спрашиваю =\. В последнее время просто начинаю с Fizz Buzz. Не смог — сразу пока.
                                                                +1
                                                                Я понимаю, что я уже заранее не прошел ваше собеседование. Мне честно интересно, что такое Fizz Buzz и SO? Если первое гуглится, то что такое второе — я вообще не представляю.
                                                                  +3
                                                                  Простите, что влезаю в дискуссию.
                                                                  1. Про FizzBuzz есть статья на Хабре: habrahabr.ru/post/111843/. Думаю, после прочтения статьи вы поймете, что такое собеседование пройти не очень сложно, если есть хоть какие-то способности и желание программировать =).
                                                                  2. SO — StackOverflow.com, сайт вопросов и ответов по программированию. Не совсем точным, но все же примером может быть Q&A Хабра.
                                                                    0
                                                                    Я знаю, что такое stackoverflow (сколько сотен раз он меня выручал). :)
                                                                    А вот о сокращении даже не подумал. За статью — спасибо (хотя у меня она первая в выдаче гугла).
                                                                      +1
                                                                      Прочитал про FizzBuzz. Общее впечатление — что собеседование с таким вопросом пройти очень сложно. Если заранее не предупреждают, какой код они хотят видеть — понятный, эффективный или интересный…
                                                                        +1
                                                                        Дак на джуниора — работающий, любой :) А не джуниор уже должен сам спрашивать, какой код нужен.
                                                                          0
                                                                          Предложите три варианта: понятный, эффективный и интересный. Это точно сработает.
                                                                        +1
                                                                        Есть подозрения, что так он назвал stackoverflow.com. Второе — ни малейших идей, гугл говорит, что так называется задача:
                                                                        Print out the numbers 1 to 100. Where the number is a multiple of 3, print ‘Fizz’, otherwise if it is a multiple of 5 print ‘Buzz’. If the number is a multiple of 3 and 5, print ‘FizzBuzz’.
                                                                          +1
                                                                          Я тоже не понял сути.
                                                                          Это задание невозможно зафейлить ведь о_О Если конечно в условиях нету использования полностью незнакомого языка или что-то в таком роде.
                                                                          • UFO just landed and posted this here
                                                                              0
                                                                              Фейлят, даже те кто на Senior позиции идет=) Причем умудряются написать так, что код просто не рабочий. Пофиг что не оптимально и тд. Плюс на основе этой задачки можно дальше продолжать беседу, обсуждая различные условия и то, как они повлияют на решение. Но это для Junior. Для Senior — поговорить про DHT =))

                                                                            +3
                                                                            Сколько любителей поминусовать и слить карму. Вот и делись опытом.
                                                                            Учетку никто не требует, просто интересно посмотреть что человек спрашивал, чем интересовался, на что отвечал. Так же показывает что человек не сидит в своем коконе. Вы не поверите, я еще спрашиваю про блоги, которые человек регулярно читает. Просто StackOverflow обычно сокращают как SO. А FizzBuzz достаточно известная задачка, как уже ниже отписали. Она не сложная, но сразу помогает отсеять товарищей, которые не могут написать простой цикл. Причем ЯП не важен. Если человек мне на Ruby ее напишет, то ему только плюс за кругозор(мы не разрабатываем на Ruby). Просто когда проводишь по 3-4 собеседования в неделю — нет никакого желания тратить свое время на долгое и мутороное выковыривание знаний из претендента. Причем сразу еще и внимательность проверяется. 70% кандидатов бросаются решать задачу с такой первой строчкой: for(int i=0;i
                                                                              0
                                                                              странная задача, хотя еще блее странно то, что она показательна.

                                                                              Конечно сразу же после прочтения условия я подумал о банальном сравнении остатка от деления на 3, 5 и 15 с нулем.

                                                                              Затем я посмотрел этот вашь коммент и вот это
                                                                              70% кандидатов бросаются решать задачу с такой первой строчкой: for(int i=0;i
                                                                              я не понял. Мне покзаалось, что вам это не нравится. Не понятно — чем?

                                                                              Посмотрел статью на хабре об этой задаче. Увидел решение с темплейтом, с хардкодом и с заменой.
                                                                              Ну, допустим, темплейт это хотя бы элегантно. А вот что хорошего в хардкоде???
                                                                              Не доводилось работать с 384 кб памяти в arm sam 7 a3, когда память уже закончилась, а пользователь ДОЛЖЕН получить два варианта языков вывода оргомного количества длинных строк?
                                                                              Конечно, то embed, а то desktop, но все же для меня такой подход вообще не является логичным и хоть как-нибудь оправданным.

                                                                              Применительно к cpp — а зачем там вообще подход с темплейтом?

                                                                              Ну да, можно было бы использовать не for, а while там какой или do while…

                                                                              А в чем смысл?
                                                                              Я, похоже, именно этого не понимаю…
                                                                                0
                                                                                Есть подозрение, что там не делить проще, а умножать ;)
                                                                                  +1
                                                                                  А, нет, я неправильно прочитал задание, простите…
                                                                                  +3
                                                                                  Единственное разумное объяснение — в задаче надо напечатать цифры от 1, а цикл инициализируется с 0. Как вывод — кандидат или не умеет читать задание (предложением раньше говорилось о внимательности), или не знает, что счетчик можно инициализировать в отличное от нуля значение.

                                                                                  Но как-то странно это.
                                                                                    0
                                                                                    Именно. Причем это частая ошибка в коде, где используется for. Просто по привычке начинают с 0. А потом иди разбирай это счастье.
                                                                                    0
                                                                                    Как раз в базе кандидат обычно предлагает обычное решение. А потом можно обсуждать с ним способы решения при дополнительных граничных условиях.
                                                                                    Но большая часть не может написать просто цикл! Просто обычный цикл. Я видел решение этой задачи в 30 строк кода с кучей if, причем там все равно была ошибка в логике.

                                                                                    Вот вам интересная статейка про задачу FizzBuzz is dead. Long live FizzBuzz! =)
                                                                                      0
                                                                                      не прочитал ветку...
                                                                                      0
                                                                                      Сам не минусовал, но скажу — поделом минусуют. Не будете впредь шифровками изъясняться…
                                                                                        +1
                                                                                        SO это не шифровка для подавляющего большинства разработчиков, особенно на Хабре(очень надеюсь). FizzBuzz — известная задачка, и на Хабре то же обсуждалась. Мы не в изоляции живем и работаем.
                                                                                          0
                                                                                          зря надеетесь, ИМХО… Stack Overflow здесь обсуждается редко, и сокращается до SO ещё реже (я лично впервые тут у Вас увидел), а задачка FuzzBuzz ещё не настолько популярна…
                                                                                            0
                                                                                            Тут в соседнем топике активно обсуждают перевод SO на русский… А так грустно, что мало кто читает блоги и статьи на англоязычных ресурсах. Это очень сужает кругозор и снижает ценность такого сотрудника. Даже из соискателей уровня Senior лишь единицы интересуются чем-то дальше Хабра.
                                                                                    –7
                                                                                    SO? Fizz Buzz? Что это? По-моему надо как раз начинать с гитхаба и хабра =)
                                                                                      0
                                                                                      Stack Overflow очень классный портал. Кстати, на нём же хантят многие агентства и последнюю роль, на которой работаю сейчас, мне предложили именно через него. У него же есть раздел с вакансиями.

                                                                                      Хотя для темы не очень актуально. Вообще не понятно, откуда graduate / junior программисту взять что-то, что можно «показать» на собеседовании.

                                                                                        0
                                                                                        Я обычно захожу туда за ответом на конкретный вопрос, очень-очень редко подходящего ответа нет. Сам я отвечал там 4 раза за 4 года, во двух случаях не было [подходящего] ответа и я решил проблему самостоятельно и поделился кодом.

                                                                                        Чтобы иметь приличную репутацию на SO надо там сидеть и планомерно отвечать на вопросы, я предпочитаю писать код и кодом же делиться, когда я таки-отвечаю на вопросы.
                                                                                          0
                                                                                          Дело не в репутации. Можно посмотреть вопросы, которые задавал человек, и на основе этого получить чуточку большее понимание того, над чем он работал и на каком уровне. Причем иногда интересно посмотреть какой ответ он выбрал, и если аргументировал, то чем.

                                                                                          Кстати для ответов на сложные вопросы помогает bounty :). Это единственный ресурс, где мне смогли ответить на вопрос о том, какие сообщения я могу отправлять клиенту по протоколу WSTrust при возникновении ошибки. Сам просто пропустил это в огромном документе, а информации по этой теме ->0.

                                                                                          Этот вопрос вполне показывает то, над чем приходилось работать :)
                                                                                          0
                                                                                          Интереса ради — не подскажете адрес вашего профиля на SO?
                                                                                      • UFO just landed and posted this here
                                                                                          +9
                                                                                          Ну ГитХаб в статье ведь только пример.
                                                                                          0
                                                                                          «Если честно, то на таком собеседовании» — не дописали. Впрочем, тут вычитывать и вычитывать. Но хотя бы есть что.
                                                                                            0
                                                                                            Спасибо. Исправил.
                                                                                            0
                                                                                            А меня спрашивали про «Есть ли акаунт на github;» и «Чаще всего используемые комбинации в IDE»
                                                                                              +1
                                                                                              росто ответив на эти два вопроса, человек может показать программирует он что либо для себя или просто сидит и ждет, когда попадет на работу

                                                                                              Что-то не совсем понимаю: а что, разве без гитхаба нельзя программировать для себя? гитхаб — это как раз скорее для кого-то, а не для себя.
                                                                                                0
                                                                                                Можно, да неудобно и потеряться может. Если хотите только для себя, можно и приватный репозиторий на битбакете использовать.
                                                                                                  0
                                                                                                  говоря про два вопроса я имел в виду «5 рефакторингов...» и «комбинации в IDE».
                                                                                                  Акаунт на гитхабедает понять, что вы, как минимум, имеете представление а даной системе. Может даже сталкивались с негатиным опытом совсестной разработки.?
                                                                                                  • UFO just landed and posted this here
                                                                                                    0
                                                                                                    У меня за >15 лет программирования ничего не потерялось.
                                                                                                    Есть что-то совсем древнее без контроля версий. Более поздние — с использованием svn/mercurial/git
                                                                                                    Но на гитхабе держу только пару проектов, которые я создал как раз не для себя, а для кого-то.
                                                                                                      0
                                                                                                      У меня тоже не потерялось, на дискете сохранено…
                                                                                                        0
                                                                                                        Значит, потерялось
                                                                                                        • UFO just landed and posted this here
                                                                                                            0
                                                                                                            Обидно, у меня там текстовый редактор — хочу взглянуть на свой ранний код.
                                                                                                        –1
                                                                                                        Для себя есть tfs.visualstudio.com/
                                                                                                        +2
                                                                                                        Почему Вы нигде перед «а» не ставите запятую… (Прошу прощения, нужно было написать в ЛС)
                                                                                                          –3
                                                                                                          нет, все правильно. так мне памятней будет)
                                                                                                          Статья писалась вчера с познего вечера и аж до утра. Под конец, я недеялся только на интелект word'а, именно поэтому было допущеномного ошибок и опечаток.
                                                                                                            +2
                                                                                                            а его ошибки в тся/ться вас не смущают?
                                                                                                            –11
                                                                                                            Шаблонные вопросы
                                                                                                            Мне кажется, что неответ на вопрос «в чем разница интерфейса и абстрактного класса» достаточный повод для прекращения собеседования. Он показывает не только профессионализм юного разработчика, но и его упорство. Два основных качества, и по обоим фейл.
                                                                                                              +6
                                                                                                              В чем разница между абстрактным классом и интерфейсом в C++?
                                                                                                                –13
                                                                                                                Хорошими ответами были бы такие: «Не знаю. Я же junior Java developer» или «В C++ интерфейс является частным случаем абстрактного класса без реализованных методов».
                                                                                                                  +4
                                                                                                                  Ну что же вы так… Интерфейсы и абстрактные классы это идеологически разные вещи :) И Junior'у действительно можно про это и не знать… хотя по-моему мнению, хороший junior должен владеть теорией… Уметь применять её не обязан, но на теоретическом уровне должен отвечать правильно на такие вопросы…
                                                                                                                    –1
                                                                                                                    Хи-хи. Когда здесь не так давно в очередной раз обсуждали это, меня сильно минусовали и ещё сильнее пытались убедить, что «правильный» ответ — это то, что интерфейс — это абстрактный класс без реализованных методов, а не то, что интерфейс — это, прежде всего, контракт. Какое-то безумное количество юниоров на хабре ;).

                                                                                                                    Аргументация, была на уровне — ну, вот я пишу класс без реализаций, и, вот оно — вуаля, интерфейс! По факту. А думать — пусть лошадь думает, у неё голова большая…
                                                                                                                      +1
                                                                                                                      Гыгг… ну бывает, хотя честно говоря удивлён… неужто и впрям засилие джуниоров… киньте ссылочкой почитать…

                                                                                                                      Может кто в книжке какой «умной» такое написал :D?

                                                                                                                      Если мозг mode off, то вполне себе похоже получается :)))
                                                                                                                        –1
                                                                                                                        А какой правильный ответ?
                                                                                                                          0
                                                                                                                          Правильность ответа зависит от того для чего вы используете интерфейсы :).

                                                                                                                          Ведь если вы не используете интерфейсы в качестве описания контрактов, то для вас это будут всего лишь абстрактные классы без реализаций. И тут сразу встаёт более интересный вопрос — а какая вам в этом случае от них польза? :) Ну, а если сущность «абстрактный класс без реализаций» не приносит пользы, значит… :)
                                                                                                                            0
                                                                                                                            Как какая польза? о_0 Да хотя бы тот факт, что реализовать вы можете сколько угодно большое количество интерфейсов… а наследование только от одного абстрактного класса…

                                                                                                                            Все относится к Java конечно
                                                                                                                              0
                                                                                                                              Если рассуждать чисто технически, то у вас полная херь получилась. Ну, можно реализовывать и что? Всё равно же каждый раз надо реализовывать заново.

                                                                                                                              Вопрос в том зачем конкретному классу писать implements SomeInterface. А вот ответив на этот вопрос и придёте к мысли, что затем это всё делается, чтобы данный класс отвечал какому-то контракту. Не?
                                                                                                                                +1
                                                                                                                                О боги!!!
                                                                                                                                В чем разница:

                                                                                                                                BaseClass obj = new ConcreteClass();
                                                                                                                                
                                                                                                                                BaseInterface obj2 = new ConcreteClass();
                                                                                                                                

                                                                                                                                ????????????????????????????

                                                                                                                                И первый и второй вариант «отвечает» какому-то контракту, согласно вашей терминологии.

                                                                                                                                Вот только во втором случае у вас гораздо больше степеней свободы.
                                                                                                                                  0
                                                                                                                                  Народ, хватит спорить об одном и томже :) перечитайте друг друга, вы говорите про одно и тоже…
                                                                                                                                    0
                                                                                                                                    Что, собственно, вас смущает. Да, и там и там — контракты. И какой из них выбрать зависит от того, что вы собираетесь делать с объектом дальше. Во втором случае ваша свобода будет _ограничена_ (а вовсе не расширена) контрактом BaseInterface'а и если вам с объектом нужно что-то делать из того, что есть в BaseClass'е (или вообще в ConcreteClass'е), но отсутствует в интерфейсе, вы пролетаете со всеми вашими степенями свободы.

                                                                                                                                    Я вам даже больше скажу, нередко объекты реализуют более одного контракта (втч непересекающихся) и каким способом вы станете объявлять переменную для ньюканья такого объекта? Не удачный у вас пример. Ограничен единственным способом использования. Но ведь есть и другие.
                                                                                                                            –2
                                                                                                                            Простите, но по вашему у класса, не реализующего никаких интерфейсов, нет «контракта»?
                                                                                                                              +1
                                                                                                                              Нет, конечно, с чего вы взяли, что я это утверждал?
                                                                                                                        0
                                                                                                                        А что такое интерфейс в с++?
                                                                                                                          0
                                                                                                                          Хороший вопрос;) Видимо, люди, которые выше бросились бурно обсуждать, знают ответ.
                                                                                                                            +1
                                                                                                                            Понятие «интерфейс» в общем смысле не относится к какому-либо языку. То есть, если оставить вопрос в такой формулировке, то ответ не изменится — интерфейс это некоторая конструкция в коде программы, которая используется чтобы специфицировать предоставляемые классом/компонентом услуги.

                                                                                                                            Если вы хотите услышать про абстрактные классы, то правильнее будет спросить что-то вроде «как интерфейсы реализуются в языке таком-то».
                                                                                                                              –1
                                                                                                                              Какая еще конструкция? Что будет за «некоторая конструкция» у класса, который ни от кого не наследуется? Или у него нет интерфейса, т.к. нет какой-то там конструкции?
                                                                                                                                0
                                                                                                                                Интерфейс это понятие находящееся вне какого-то языка и его конструкций. Это понятие описывает некий стандарт на общение с объектом. Если в языке присутствует множественное наследование (как например в C++), то да… Интерфейсы реализуются по средствам абстрактных классов… Но есть языки (и их НАМНОГО больше) в которых нет понятия абстрактных классов или множественного наследования. Интерфейсы в таких языках реализуются каким-то иным способом, вплоть до создания специального атрибута типа класса Interface… но это уже технические детали, а интерфейс это более абстрактное понятие…

                                                                                                                                Тобишь абстрактный класс при множественном наследовании это один из способов реализации интерфейса…
                                                                                                                                  0
                                                                                                                                  Как реализуются интерфейсы в Ruby? Или там у классов нет интерфейсов?
                                                                                                                                    0
                                                                                                                                    Причем тут Ruby? Я Rubby не знаю, лезть и смотреть в интернетах тоже никакого желания нет… Вы знаете, вот и расскажите… хотя не понятно опять зачем-же???
                                                                                                                                      0
                                                                                                                                      Ruby притом, что вы упомянули множество других языков. Я привел в пример один из.

                                                                                                                                      В Ruby нет множественного наследования, абстрактных классов и «интерфейсов» («специальных конструкций», атрибутов, абстракций и т.д.). Т.е. там у классов нет интерфейсов?
                                                                                                                                        0
                                                                                                                                        Вы не внимательно читали :)

                                                                                                                                        Или правда в Ruby у классов нет аттрибутов? 8-( ) (сарказм mode on)
                                                                                                                                          0
                                                                                                                                          Нет
                                                                                                                                            0
                                                                                                                                            И методов нет? :)))
                                                                                                                                              0
                                                                                                                                              Методы есть). И атрибуты есть (аналог свойств в C#, методов доступа).

                                                                                                                                              «атрибуты» в скобках, я написал, т.к., видимо, неправильно прочитал «создания специального атрибута типа класса Interface», т.к. вы, скорее всего, забыли запятую. Я это понял как аналог атрибутов в C# или аннотаций в Java.
                                                                                                                                                0
                                                                                                                                                Да, забыл… увидел… но поправить не могу :)
                                                                                                                                                  +1
                                                                                                                                                  Атрибуты класса/объекта — это тоже самое, что поля. В любом языке.
                                                                                                                                                    0
                                                                                                                                                    Не в любом. В C# это называется «свойства», а «атрибуты» там совсем другое.
                                                                                                                                                      0
                                                                                                                                                      Свойства в C# — это свойста.
                                                                                                                                                      Атрибуты — это атрибуты.
                                                                                                                                                      Атрибуты объекта — это атрибуты объекта или поля.

                                                                                                                                                      Вы запутались.
                                                                                                                                                        0
                                                                                                                                                        Да, вы правы. Я тут просто сплю уже. У нас уже 3 часа, как завтра.
                                                                                                                                                +1
                                                                                                                                                [sarcasm mode]
                                                                                                                                                В attr_reader и attr_accessor «attr» — это наверное сокращение от «attraction».
                                                                                                                                                [/sarcasm mode]
                                                                                                                                                  0
                                                                                                                                                  Как эти «аттрибуты» помогают решить проблему отсутствия интерфейсов?
                                                                                                                                                    0
                                                                                                                                                    Нет никакой проблемы… в этом всё дело :)))
                                                                                                                                                  0
                                                                                                                                                  Как так, там же есть для них даже специальные конструкции типа attr_accessor, attr_reader и attr_writer…
                                                                                                                                                0
                                                                                                                                                Как организовать интерфейсы у объектов, программист волен выбирать сам :)

                                                                                                                                                Это полностью всегда остаётся на его совести, вплоть до реализации метода execute_iface в качестве аргумента которой передаётся название функции и её аргументы :)))

                                                                                                                                                Именно про это я и написал :) что интерфейс это абстрактное понятие о том, как взаимодействовать с тем или иным объектом и конечно само описание класса тоже является интерфейсом :)))
                                                                                                                                              0
                                                                                                                                              В Ruby у классов есть интерфейсы, но в самом языке нет такой синтаксической конструкции. Потому что она там не нужна. В отличие от C#, например.
                                                                                                                                                0
                                                                                                                                                Дык мы вроде и говорили о том, что синтаксические конструкции это частности реализации…
                                                                                                                                                  0
                                                                                                                                                  Есть еще идеология. В Ruby интерфейсы как конструкция языка не нужны, так как там по другому устроен полиморфизм.
                                                                                                                                                    0
                                                                                                                                                    Ну это ведь тоже частность реализации :)
                                                                                                                                                  0
                                                                                                                                                  Я про это и говорю. Просто тут началась вакханалия с придумыванием всяких «некоторых конструкций», «абстракций» и прочей ерунды.

                                                                                                                                                  А если вопрос задать, то они еще глубже в свое болото ныряют.
                                                                                                                                                    0
                                                                                                                                                    Кажется вы не про что еще не говорили… только «вопросы задавали» :D
                                                                                                                                              0
                                                                                                                                              На сколько много больше?
                                                                                                                                                0
                                                                                                                                                На порядок :) языки с множественным наследованием можно пересчитать на пальцах…
                                                                                                                                              0
                                                                                                                                              «Некая конструкция» значит, что в разных языках интерфейсы реализованы по-разному. Например в C++ интерфейсы реализуются абстрактными классами, а в каком-нибудь другом языке еще интерфейсы реализуются специальными семантическими единицами, которые не имеют ничего общего с обычными классами.
                                                                                                                                                0
                                                                                                                                                Вы упорно переводите тему. У класса на С++, не наследующего другие классы (как абстрактные, так и нет), нет интерфейса?
                                                                                                                                                  +1
                                                                                                                                                  Я не перевожу тему… Я всего лишь хочу сказать, что само понятие «интерфейс» не имеет отношения к конкретному языку программирования.

                                                                                                                                                  Выше был задан вопрос «А что такое интерфейс в с++? ».
                                                                                                                                                  Я обратил внимание на то, что, поскольку интерфейс — понятие, не имеющее отношения к языку (простите, я повторяюсь), то «интерфейс в С++», «интерфейс в java» и «интерфейс где-угодно-еще» это одно и то же. А если человек, проводящий собеседование (у нас топик про собеседования, кстати) хочет узнать, как интерфейсы реализуются в C++, то и спрашивать надо не «что такое...», а «как реализуются».
                                                                                                                                                    0
                                                                                                                                                    Этот вопрос был задан в ответ на мой компрометирующий вопрос.
                                                                                                                                                  0
                                                                                                                                                  Ну просто зря вы используете термин «некая конструкция» :) Это не конструкция, это абстракция :) которая находится за рамками каких-то конкретных конструкций…
                                                                                                                                                    0
                                                                                                                                                    Он не использует, он в Википедии прочитал.
                                                                                                                                                    0
                                                                                                                                                    Да, вы правы, слово не совсем удачное…
                                                                                                                                                +1
                                                                                                                                                Понятие абстрактного базового класса в общем смысле тоже не относится к какому-либо языку.
                                                                                                                                          +26
                                                                                                                                          Взгляд с другой стороны, несколько циничный (бекграунд: аутсорсинговая компания среднего размера (человек двести примерно), много проектов, много команд. своего опыта — 10+ лет в веб-разработке): кандидатов в джуниоры много, значительная часть непригодна. Стоимость false negative все же невелика (или такой воспринимается). Стоимость false positive, хоть и больше, но тоже не смертельна. Таким образом, задача собеседующего — быстро отсеять непригодных, из оставшихся, тоже не затрачивая лишних усилий (=денег) выбрать лучших. С этой точки зрения, ваши «антипаттерны» как раз становятся чуть ли не best practices эффективного отбора (эффективного по критерию цена/качество). Кроме пункта 4 (повторение — это неэффективно) и, возможно, пункта 6 (который я, честно говоря, вообще не понял).

                                                                                                                                          Пройдусь по пунктам:
                                                                                                                                          1) «Шаблонные вопросы». а) их недолго задать — экономим время. Даже если человек заучил на них ответы, то это, во-первых, показывает, что он не совсем просто так к нам пришел, а во-вторых — будет выявлено на паре дополнительных вопросов. Если кандидат просто растерялся — это обычно видно, и вопросы можно на ходу переформулировать. Если растерялся, но не показал виду — ну что ж, отсеем. Не страшно, поскольку см. пункт про стоимость false negative. б) задавая одинаковые вопросы всем, получаешь возможность сравнить кандидатов. в) кандидат в джуниоры, как правило, уникальным профессиональным опытом не обладает, так что подогнать лично под него вопросы все равно не получится.

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

                                                                                                                                          3) «Проведем собеседование всей компанией». Три человека на собеседовании — вполне обычно. У нас — HR, тим-(тех)-лид, старший разработчик. HR рассказывает о компании, выясняет пожелания кандидата, в процессе технического собеседования — смотрит на реакции кандидата и потом дает рекомендации психологического толка тимлиду. Тимлид, со своей стороны, оценивает пригодность данного кандидата для данного проекта/команды, как с технической, так и с коммуникативной стороны. Старший разработчик присутствует для более объективной оценки кандидата с технической стороны (после собеседования они обсуждают кандидата с тимлидом).

                                                                                                                                          5) «Никогда не давайте тестовые задания домой. Никогда!». Вы совершенно верно отметили, это занимает слишком много времени. Для позиции джуниора домашние задания, по моему мнению, совершенно излишни.

                                                                                                                                          Best practices:
                                                                                                                                          1) «Распараллеливание задач». Так все и есть, все те люди, которых вы упоминали в пункте 3 «антипаттернов» занимаются на собеседовании своими специфическими задачами.

                                                                                                                                          2) «Про все что вы не спросили – должен рассказать вам HR.». Верно. У стандартного эйчара на стандартную вакансию в компании должен быть заготовлен стандартный спич. Оплата, пересмотры, отпуска, бонусы, развлекалово, командировки, время работы офиса, график рабочего дня и т.д. Позиция джуниора вполне стандартна.

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

                                                                                                                                          4) «Четко определенные цели и задачи». Не очень актуально для джуниоров. Большинство не знают, чего хотят, компания не знает, что они могут, и рассчитывает присмотреться позже, во время испытательного срока/первого года работы. «Компания, которая берет себе junior программиста должна четко понимать, кого она хочет из него сделать через лет 3-4.» — редкий джуниор долетит до середины Днепра доживет до этого срока. А уж с неизменными устремлениями — и того меньше. Так что, что получится из этого джуниора, то и получится.

                                                                                                                                          5) «Вопросы по вакансии, а не по резюме». См. аналогичный пункт «антипаттернов».

                                                                                                                                          6) «Не надо ждать фидбэк. Никогда.». Отсутствие фидбека — свинство со стороны работодателя.

                                                                                                                                          7) «Определение размера ЗП и сроков ее пересмотра.». Пересмотр раз в пол-года. Это хорошо и так должно быть.
                                                                                                                                            +1
                                                                                                                                            Я разве что про дз не соглашусь. У нас задание идет до собеседования и на нем отсеивается процентов 90 кандидатов. Задание достаточно простое, но дает возможность посмотреть как кандидат пишет код в тепличных условиях.
                                                                                                                                              +2
                                                                                                                                              Вот с вами согласен.

                                                                                                                                              1. Такое впечатление, что автор статьи не в курсе про ещё один фактор — состояние рынка.
                                                                                                                                              Допустим, у нас в городе толковых спецов нет (свободных). Поэтому или переманиваешь из другой конторы, или берёшь то, что есть (если, конечно, интерес у кандидата обучаться есть), и лепишь из этого то, что надо. Это к слову о «компания не понимает, кто ей нужен или подходят все».

                                                                                                                                              2. Я, если честно, не понял автора: сначала он говорит, что задавать специфические вопросы юниору — это антипаттерн, а потом это же и рекомендует в своих best practiсe.

                                                                                                                                              3. Вывод: автор просто не был по другую сторону баррикад.

                                                                                                                                              p.s. Соглашусь с комментарием 1ex, что современные юниоры — это смех и грех.

                                                                                                                                              p.p.s. И напоследок: то ли у нас регион такой (Татарстан, Казань), то ли действительно новички зажрались.
                                                                                                                                                0
                                                                                                                                                «задавать специфические вопросы юниору — это антипаттерн». Я такого не говорил). Имелось введу заменить (изменить) стандартные вопросы. Скажем, вопросы по спискам, колекциям должны быть. Но, можно придумать что-то кроме стандартного «отличие между двумя реализациями List'а».
                                                                                                                                                Я хотел скачать, что изменяя стандартные вопросы вы заставляете кандидата думать. И слушая ответ, можно понять, действтительно ли человек разбирается в теме, или говорит заученый ответ.
                                                                                                                                                  0
                                                                                                                                                  Беда в том, что кандидатов много (особенно джуниоров) и на каждого нестандартных вопросов не напридумываешь. Хитрые и интересные вопросы занимают много времени на «придумать», а кроме собеседований кандидатов есть и текущая работа, которая иногда должна быть сделана «вчера». Поэтому такие вопросы задаются по фактическому резюме senior девелоперам.
                                                                                                                                                    0
                                                                                                                                                    Измените их 1 раз, и задавайте всем своим соискателям. Но не берите as is с инета, потому что их уже заучили. Думаю, это имелось ввиду…
                                                                                                                                                      +2
                                                                                                                                                      Не сочтите занудством, но если человек выучил ответы на 100 шаблонных вопросов, как уже говорилось выше, это тоже кое-что говорит о кандидате.
                                                                                                                                                    +3
                                                                                                                                                    1. Извиняюсь, если не правильно вас понял, но как новичок может разбираться в теме? Он же начинающий.
                                                                                                                                                    2. Новичку никто не даст сразу сложных задач — как раз, скорее всего, будут шаблонные, на которые «заучены ответы».
                                                                                                                                                    3. Чтобы понять, умеет ли человек думать, лично мне достаточно одного-максимум двух вопросов не по теме.
                                                                                                                                                    4. К слову, забыл в первом комментарии упомянуть относительно чтения книг. Для меня намного важнее читает ли кандидат художественную литературу, а не техническую. Мне не нужен гик, который не может без кода и паттернов объяснить, что он предлагает. Поверьте, это выглядит очень убого, когда на вопрос в духе «Что вы предлагаете в этом случае», начинается мычание, «ээээ», «как бы», «типа», «вроде» в пачке с искажёнными цитатами из технических источников.
                                                                                                                                                    Поэтому я всегда советую по-больше читать художественной литературы — кроме всего прочего, она развивает образ мысли, словарный запас (который влияет, к слову, на сообразительность и эрудицию) и грамотность.

                                                                                                                                                    p.s. Спасибо за статью, но вам, прежде чем критиковать «другую сторону», стоит побывать на ней. Вы удивитесь, как изменится ваше мнение. Я желаю вам бурного развития и замечательных успехов. Статья на хабре в вашей копилке уже есть (: правда, не уверен, что все работодатели её оценят (:
                                                                                                                                                +12
                                                                                                                                                Антипаттерны собеседования джуниора? Это какой то оксюморон. До четвертого пункта читал — улыбался, после читал — хмурился, ну и молодняк пошел — к сожалению или к счастью, кто знает.

                                                                                                                                                «Ах, собеседующие, зачем вы утомляете меня этими скучными вопросами, я на них уже вчера отвечал»

                                                                                                                                                Справедливости ради соглашусь с пунктами про ГитХаб и Хабр, но если яйца есть и есть чем — сам похвастается.

                                                                                                                                                Про 5 любимых рефакторингов спрашивать у джуниора — даже слов нет, одни буквы
                                                                                                                                                  –4
                                                                                                                                                  а почему бы и не спросить? вполне может быть, что человек прочитал Фаулера и знает что такое рефакторинг. Если он програмирует, даже сидя дома (в общаге) то 5 рефакторингов назвать будет не так уж и трудно.
                                                                                                                                                    +5
                                                                                                                                                    Одно дело назвать (че-то читал).
                                                                                                                                                    Другое дело реально применять. Ну где джуниору активно применять рефакторинг? Жизненный цикл 99% его программ — сдал курсовую и уничтожил, чтобы никто не увидел этот позор.
                                                                                                                                                      –3
                                                                                                                                                      Мы с вами говорим о разных уровнях рефакторинга).
                                                                                                                                                      Грамотно назвать переменную тоже рефакторинг, как и, например, выделение метода. Это можно вполне реально проделывать даже на программах вида helloWorld.
                                                                                                                                                        +5
                                                                                                                                                        Рефакторинг — это изменение кода, без изменения его внешнего поведения. «Назвать переменную» — это не рефакторинг. Рефакторингом будет «переименовать переменную».
                                                                                                                                                  +4
                                                                                                                                                  >> 5) Вопросы по вакансии, а не по резюме.
                                                                                                                                                  >> Конечно каждый несет ответственность за то,
                                                                                                                                                  >> что у него написано в CV. И я понимаю, что
                                                                                                                                                  >> если у меня указаны C++ или JavaScript меня могут
                                                                                                                                                  >> спросить по любому из этих языков, даже если они
                                                                                                                                                  >> не есть моими профильными.

                                                                                                                                                  Я считаю, что нужно обязательно спросить обо всем, что есть в резюме в разделе заявленных навыков.
                                                                                                                                                  Если есть Pascal и Assembler – без проблем:
                                                                                                                                                  А можно ли Assembler использовать внутри Pascal?
                                                                                                                                                  А как создать класс на Pascal?

                                                                                                                                                  C++(STL)?
                                                                                                                                                  Я понимаю, что на этом языке была сделана последняя и единственная лаба в институте, но про контейнеры в STL я обязательно спрошу. Просто: перечислите те, которые помните.

                                                                                                                                                  И все равно, что вы тестировщиком к нам устраиваетесь.

                                                                                                                                                  Все, что перечислено в резюме в разделе «навыки» должно быть покрыто вопросами, пусть даже самыми простыми. Иначе, почему оно там?
                                                                                                                                                  Все очень просто. Люди врут. Но, на их языке это «преувеличение»

                                                                                                                                                  А за статью – спасибо. Очень классно написано.
                                                                                                                                                  • UFO just landed and posted this here
                                                                                                                                                      +13
                                                                                                                                                      фишка в том, что если написано — нужно спросить, хотя бы один вопрос, чтобы понять насколько человек врет. Если человек пишет, что у него флюент инглиш, то собеседование начнется на английском. Ибо нефиг
                                                                                                                                                        +3
                                                                                                                                                        Простите, вам хорошего спеца надо нанять, или резюме проверить?

                                                                                                                                                        Да, если человек врёт в резюме — это не хорошо. Но с другой стороны, он мог вписать С++ в резюме, потому что учил его 5 лет назад в универе. И конечно же, уже забыл как пользоваться указателями (а может и не разобрался толком). И если Вы его хотите брать на должность php разработчика — чем Выше указанный факт плох?
                                                                                                                                                          +2
                                                                                                                                                          Учил и забыл, но всё-равно вписал в раздел навыков? Раз вписал именно в этот раздел, значит, пусть и отвечает. Чем плох навык ответственности за свои слова? Это просто проверка такого навыка. :) Вот он вам так же скажет потом, что сделал очередное задание, но не сделает.

                                                                                                                                                          В конце-концов, если человеку так хочется упомянуть факт, что он «проходил» сипипи в институте, надо упоминать этот факт в соостветствующем разделе. Я себе такой отстойник в резюме завёл, куда скидываю ископаемые технологии вроде ассемблера PDP-11, паскаля для БЭСМ-6, Algol-60 и JCL для 1ВМ S/360 :). Так и назвал — ископаемые технологии :). Ни в коем случае не навыки. Ибо алгол я, конечно, разобрать смогу, а вот поругаться на JCL точно не осилю. Тут, впрочем, риск нарваться на кого-то, кто помнит минимален :).
                                                                                                                                                            0
                                                                                                                                                            >>Я себе такой отстойник в резюме завёл
                                                                                                                                                            Но зачем?

                                                                                                                                                            >>Учил и забыл, но всё-равно вписал в раздел навыков? Раз вписал именно в этот раздел, значит, пусть и отвечает

                                                                                                                                                            У нас у всех разные понятия о «знаю». Обычно проблемы начинаются, когда нарываешься на спеца в технологии (скажем на PM который балуется C++). Но опять таки — к твоей текущей вакансии это не относится

                                                                                                                                                            Просто основная идея собеседования — всё таки понять, насколько человек соответствует вакансии, а не своему резюме. Резюме могло вообще взяться прошлогоднее, на требование HR
                                                                                                                                                              +1
                                                                                                                                                              >Но зачем?

                                                                                                                                                              Это мой опыт. Он мне ценен. Интервьюеру он может дать информацию о моём кругозоре. Но отвечть на вопросы по тому же С++ я не готов и на данном интервью не намерен. Так зачем провоцировать интервьюера на эти вопросы, помещаяя С++ в раздел навыков? Опыт использования есть. Эта информация может быть ценной. Навыков на данный момент уже нет (ну, то есть я не готов сразу по выходу на работу писать на нём код). Логично поместить в отдельный раздел.

                                                                                                                                                              >У нас у всех разные понятия о «знаю».

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

                                                                                                                                                              >текущей вакансии это не относится

                                                                                                                                                              Ситуации бывают разные. Вполне возможно у работодателя есть более интересные для меня предложения, чем та конктретная вакансия на которую я пришёл собеседоваться. Зачем же себя заранее загонять в узкие рамки?
                                                                                                                                                            • UFO just landed and posted this here
                                                                                                                                                                0
                                                                                                                                                                Мы знакомы? Imho, тебе нужно поучиться вежливости.

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

                                                                                                                                                                Даже «раздел для специалистов» не спасает если там только актуальные технологии перечислены. Вот какое мне дело, что какой-нибудь конкретный тупень не знает что такое Algol-60? Мне из-за него вычёркивать свой опыт работы? С какого такого хрена? Ясен пень я не расписываю несколько листов прозой про алголы-фортраны — достаточно строчки с перечислением через запятую.

                                                                                                                                                                И, да, я определённо считаю, что БЕЗ этой строчки моё резюме будет хуже, чем с нею.

                                                                                                                                                                И, нет, я не считаю, что резюме не требует «заточки» под позицию. Требует, но куда более грамотной и тонкой, чем просто выбрасывание всего, что не совпало с позицией. Ну, если только вы не стажёрско-юниорскую позицию подаётесь :), там, возможно, лучше всё повыкинуть нафиг. И то спорно.
                                                                                                                                                                • UFO just landed and posted this here
                                                                                                                                                                    0
                                                                                                                                                                    (я давно живу в стране, где слово «Вы» — по вполне разумным причинам — давно изжито),

                                                                                                                                                                    Вообще-то изжито как раз «ты» (thou), а осталось «вы» (you, от арх. ye).
                                                                                                                                                                    • UFO just landed and posted this here
                                                                                                                                                                      0
                                                                                                                                                                      Чувачог немытый. Я тебе по секрету одын умный вещь скажу, только ты не обижайтся. Ты что-то в жизни проспал — это НЕ фидошка. Пора бы уже проснуться. :)

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

                                                                                                                                                                      И, это… устраиваться на позицию, требующую знаний, которых у тебя пока нет, куда интереснее, чем крутиться в одном и том же забеге крысинных бегов. В принципе, я понял «специалистов» — если они хотят заниматься ровно тем же, чем занимались на предыдущем рабочем месте, то действительно, какой смысл писать о параллельных реальностях? Но это очень сильно не моё — я работу-то меняю, в основном, потому, что прежняя настолько хорошо изучена, что превратилась в рутину и набила оскомину. Зачем мне менять шило на мыло и скать точно такую же? Только ради того, чтобы стать специалистом по составлению резьюме? Глупость какая. Я лучше новые области покопаю.
                                                                                                                                                                        0
                                                                                                                                                                        И, это… устраиваться на позицию, требующую знаний, которых у тебя пока нет, куда интереснее, чем крутиться в одном и том же забеге крысинных бегов.


                                                                                                                                                                        Эээ… А возьмут? В наше-то время, когда по любой ИТ специальности есть сколько угодно выпускников с горящими глазами?
                                                                                                                                                                          +1
                                                                                                                                                                          Туда где совсем не в зуб ногой — наверное, нет :). Но так наобум лезть смысла мало во всех смыслах. Хотя… тоже бывает… Как-то подрабатывал для одних, — когда договаривался вообще не знал пхп, который был нужон. Ну, оговорили, что период введения в курс дела (оплачиваемый!) будет несколько больше, чем если бы знал. Разумные люди довольно часто способны договориться :).

                                                                                                                                                                          А так — говоришь, ну вот по этой теме я только читал и писал хелловорды, в смысле не писал ещё в этой теме продакшн-код, но кой чего разумею. Обязуюсь догнать и перегнать :). А свидетельством того, что я на это способен — вот тот самый списочек с чем я уже имел дело. Получить на работу профессионала, добавляющего к списку ещё один пункт часто гораздо безопаснее, чем получить выпускника у которого глаза хоть и горят, но чего от него ожидать не знает ни кто втч он сам. Как-то так.
                                                                                                                                                                        • UFO just landed and posted this here
                                                                                                                                                                            0
                                                                                                                                                                            Во даёт! Пришло, «потыкало», ещё меня же в своём хамстве и обвинило! Круто вышиваешь, специалист по составлению резюме. Кроме резьме-то хоть что-то умеешь?
                                                                                                                                                                    +2
                                                                                                                                                                    Про JCL не знаю, хотя системщики наверняка помнят. Но ассемблер PDP-11 — такая штука, которую забыть невозможно (по крайней мере, основы)… так что здесь можно и нарваться на желающих поговорить :)
                                                                                                                                                                    Что делает команда
                                                                                                                                                                            MOV -(PC),-(PC)
                                                                                                                                                                    

                                                                                                                                                                    ? :D
                                                                                                                                                                      0
                                                                                                                                                                      Ничего святого не осталось в век гугла: сразу же находит, что это PDP-11 Self-Propagating Instruction
                                                                                                                                                                      • UFO just landed and posted this here
                                                                                                                                                                          +1
                                                                                                                                                                          Подозреваю, что если идти в компанию, где есть (или скоро будет) отдел, занимающийся какими-нибудь прошивками на низком уровне, и есть желание со временем там оказаться, то указание любого ассемблера будет в плюс — хоть PDP 11, хоть Эльбрус, хоть Сетунь… чем больше, тем лучше (если действительно приходилось с этим иметь дело). «Потому что опыт есть, а опыт не пропьёшь»…
                                                                                                                                                                          Хотя шансов на то, что за время работы на эту компанию действительно придётся написать хоть что-нибудь на ассемблере, исчезающе мало… Но по крайней мере, такой человек не будет бояться заглянуть в то, что нагенерил компилятор.
                                                                                                                                                                          • UFO just landed and posted this here
                                                                                                                                                                              0
                                                                                                                                                                              Нет, я написал именно компанию. На случай, если работа, для которой предназначена данная позиция, закончится, и как раз к этому времени развернётся проект по микрокодированию. А тут как раз специалист с опытом многочисленных ассмблеров под рукой, к тому же успевший вникнуть в суть проекта.
                                                                                                                                                                              А на позицию фирмварщика сразу могут и не взять — там наверняка будет нужен специалист, уже имеющий опыт работы с ассемблером ARM и соответствующим железом… Тем более, в описанный момент эта позиция ещё не открыта.
                                                                                                                                                                              • UFO just landed and posted this here
                                                                                                                                                                      0
                                                                                                                                                                      Знаете, я лучше ничего не знающего человека научу программингу, чем буду объяснять знающему, почему врать нехорошо, а потом он мне все сроки сорвет и наговорит всякого разного дерьма.
                                                                                                                                                                +2
                                                                                                                                                                Немного скажу прелюдию: я всегда иду на senior разработчика или выше.

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

                                                                                                                                                                Помню в прошлом была такая проблема: я не знал как и что называется, один собеседующий сказал, что без теории они не смогут меня научить c#…
                                                                                                                                                                Тогда я изучил теорию, полез глубже, узнал несколько нового для себя. В итоге термины не заучил, а просто объясняю своими словами — так проще и мне и видно что я понимаю что это.
                                                                                                                                                                В последствии c# я изучил сам, придя в компанию, где мне сказали: ну я думаю тебе будет не сложно…
                                                                                                                                                                Да, оказалось не сложно.

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

                                                                                                                                                                Единственное что не люблю — тестовые задания. Это порой выливается в какой-то бред.
                                                                                                                                                                У меня в одно время скопилось 20 исполненных тестовых заданий. В большинстве случаев отказ шел из-за того, что компании находились в других городах. Все были уверены что я быстро найду работу, а искал я ее пол года, что было печально.
                                                                                                                                                                Причем порой часто наблюдаю компании, которые твои ответы используют в своих целях, а тебе отказывают.

                                                                                                                                                                При это даешь сертификаты, ссылки на проекты, подробное описание исполненных работ и проектов… Это порой бывает грустно.

                                                                                                                                                                Я не люблю собеседования из-за форменного бреда, который часто там происходит. Бывают исключения, но они редки.
                                                                                                                                                                  +1
                                                                                                                                                                  Меня раздражала фамильярность: люди думают будто начальству все можно…

                                                                                                                                                                  Да, такое часто бывает. Собеседуемые, особенно если это их первая работа, тоже часто робеют и дают собеседующим лишний повод вести себя высокомерно =) Просто не все кандидаты понимают, что в момент собеседования кандидат и компания пытаются прийти к взаимовыгодному соглашению, а значит — играют на равных.
                                                                                                                                                                    0
                                                                                                                                                                    Меня больше всего всегда раздражали вопросы, которые полностью и подробно описаны в резюме — будто их не читали

                                                                                                                                                                    Когда проводишь по собеседованию в день (а то и по два), вдумчиво читать резюме просто не хватает сил. И да, иногда полезно спрашивать повторно — у меня был случай, когда пришел претендент на должность Java синьора, с мега-опытом в Spring (судя по резюме), но не смог объяснить, что же такое инъекция.
                                                                                                                                                                    • UFO just landed and posted this here
                                                                                                                                                                        0
                                                                                                                                                                        Я — единственный девелопер в нашем филиале. Хотят нанять еще пару-тройку. На этой неделе собеседования были каждый день. HR не могут оценивать знания и отсеивать тех, кто приврал в резюме, это делаю я по телефону.

                                                                                                                                                                        А как надо?
                                                                                                                                                                        • UFO just landed and posted this here
                                                                                                                                                                            0
                                                                                                                                                                            Объявление дали в начале января, вот к марту нашли 1 человека. Даже и не знаю, в чем дело. Требования не космические
                                                                                                                                                                            • UFO just landed and posted this here
                                                                                                                                                                  +1
                                                                                                                                                                  Хочу прокомментировать пункт с тестовыми заданиями на дом.
                                                                                                                                                                  Я участвовал в приеме на работу стажеров-разработчиков (это чуть ниже уровень, чем junior). Так вот проверяя задание, я обращаю внимание не на качество написания кода, а на «думалку» разработчика. Сколько банальных ошибок о