Пользователь
0,0
рейтинг
20 февраля 2013 в 02:18

Маркетинг → Собеседование на 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 собеседовании»).

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

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

Подробнее
Реклама

Самое читаемое Маркетинг

Комментарии (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 этап толковый, остальные все попали в описанные антипаттерны. И попали из-за своей неуместности в тех случаях, когда они применяются.
      • НЛО прилетело и опубликовало эту надпись здесь
      • 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
          Я тоже не понял сути.
          Это задание невозможно зафейлить ведь о_О Если конечно в условиях нету использования полностью незнакомого языка или что-то в таком роде.
          • НЛО прилетело и опубликовало эту надпись здесь
          • 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?
  • НЛО прилетело и опубликовало эту надпись здесь
    • +9
      Ну ГитХаб в статье ведь только пример.
  • 0
    «Если честно, то на таком собеседовании» — не дописали. Впрочем, тут вычитывать и вычитывать. Но хотя бы есть что.
    • 0
      Спасибо. Исправил.
  • 0
    А меня спрашивали про «Есть ли акаунт на github;» и «Чаще всего используемые комбинации в IDE»
  • +1
    росто ответив на эти два вопроса, человек может показать программирует он что либо для себя или просто сидит и ждет, когда попадет на работу

    Что-то не совсем понимаю: а что, разве без гитхаба нельзя программировать для себя? гитхаб — это как раз скорее для кого-то, а не для себя.
    • 0
      Можно, да неудобно и потеряться может. Если хотите только для себя, можно и приватный репозиторий на битбакете использовать.
    • 0
      говоря про два вопроса я имел в виду «5 рефакторингов...» и «комбинации в IDE».
      Акаунт на гитхабедает понять, что вы, как минимум, имеете представление а даной системе. Может даже сталкивались с негатиным опытом совсестной разработки.?
      • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      У меня за >15 лет программирования ничего не потерялось.
      Есть что-то совсем древнее без контроля версий. Более поздние — с использованием svn/mercurial/git
      Но на гитхабе держу только пару проектов, которые я создал как раз не для себя, а для кого-то.
      • 0
        У меня тоже не потерялось, на дискете сохранено…
        • 0
          Значит, потерялось
          • НЛО прилетело и опубликовало эту надпись здесь
          • 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
                  На порядок :) языки с множественным наследованием можно пересчитать на пальцах…
            • 0
              «Некая конструкция» значит, что в разных языках интерфейсы реализованы по-разному. Например в C++ интерфейсы реализуются абстрактными классами, а в каком-нибудь другом языке еще интерфейсы реализуются специальными семантическими единицами, которые не имеют ничего общего с обычными классами.
              • 0
                Вы упорно переводите тему. У класса на С++, не наследующего другие классы (как абстрактные, так и нет), нет интерфейса?
                • +1
                  Я не перевожу тему… Я всего лишь хочу сказать, что само понятие «интерфейс» не имеет отношения к конкретному языку программирования.

                  Выше был задан вопрос «А что такое интерфейс в с++? ».
                  Я обратил внимание на то, что, поскольку интерфейс — понятие, не имеющее отношения к языку (простите, я повторяюсь), то «интерфейс в С++», «интерфейс в java» и «интерфейс где-угодно-еще» это одно и то же. А если человек, проводящий собеседование (у нас топик про собеседования, кстати) хочет узнать, как интерфейсы реализуются в C++, то и спрашивать надо не «что такое...», а «как реализуются».
                  • 0
                    Этот вопрос был задан в ответ на мой компрометирующий вопрос.
              • 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 я обязательно спрошу. Просто: перечислите те, которые помните.

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

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

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

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

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

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

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

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

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

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

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

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

                Ситуации бывают разные. Вполне возможно у работодателя есть более интересные для меня предложения, чем та конктретная вакансия на которую я пришёл собеседоваться. Зачем же себя заранее загонять в узкие рамки?
            • НЛО прилетело и опубликовало эту надпись здесь
              • 0
                Мы знакомы? Imho, тебе нужно поучиться вежливости.

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

            А как надо?
            • НЛО прилетело и опубликовало эту надпись здесь
              • 0
                Объявление дали в начале января, вот к марту нашли 1 человека. Даже и не знаю, в чем дело. Требования не космические
                • НЛО прилетело и опубликовало эту надпись здесь
  • +1
    Хочу прокомментировать пункт с тестовыми заданиями на дом.
    Я участвовал в приеме на работу стажеров-разработчиков (это чуть ниже уровень, чем junior). Так вот проверяя задание, я обращаю внимание не на качество написания кода, а на «думалку» разработчика. Сколько банальных ошибок он мог предупредить, как хорошо умеет пользоваться гуглом. И очень многие кандидаты показывали умение пользоваться языком программирования, но полнейшее не умение пользоваться логикой.
    А писать код красиво, хорошо и правильно должны уже мы его научить.
  • +3
    В принципе со многим согласен, хочу остановиться буквально на нескольких моментах поподробнее (не по порядку):

    1. Отсутствие фидбека — это просто несерьезно со стороны не то что уважающей компании, но даже лично со стороны уважающего себя HR-а. Это прекрасно показывает, что компании на вас наплевать, но, увы, встречается очень часто. Ну неужели так трудно хотя бы составить шаблонное письмо вроде «Здравствуйте, уважаемый Имярек, к сожалению в данный момент мы не готовы принять вас на работу, блаблабла» и имя подставлять? То ли они боятся отказывать, то ли считают, что это ниже их достоинства — непонятно.

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

    3. Статьи на хабр, github, и т.д. Про хабр и участие в open-source меня не спрашивали никогда. Про последнюю прочитанную книгу — несколько раз было. Вообще это вопрос неплохой, но не стоит переоценивать его значимость. Например на Хабр можно писать статьи про законодательство в области IT, а в open-source заниматься составлением документации (что, не спорю, очень полезно для проекта), а эти вещи вам не очень помогут, например, писать сервер. Про системы контроля версий можно узнать гораздо менее завуалированным путем — тупо спросить, имел ли человек опыт работы с ними, и вкратце рассказать, что это такое.

    4. 5 любимых рефакторингов, любимая комбинация в IDE. Честно говоря, мне кажется, что польза от этих вопросов сомнительная. Если человек никогда не участвовал в серьезных проектах, то далеко не факт, что ему приходилось заниматься рефакторигом, даже если Фаулера он прочитал. Про любимую комбинацию в IDE вообще не понятно зачем спрашивать. Ну вот скажу я вам, что моя любимая комбинация в Qt Creator это alt-enter. Как это поможет вам оценить меня?

    5. Про все что вы не спросили – должен рассказать вам HR, Плюшки. Согласен с вашим мнением, но насчет плюшек вам нужно учитывать, что если человек 15 лет работает на стульях за $1000, то для него их наличие не является каким-то особым преимуществом — он к ним привык. Хотя вообще странно, что часто в описаниях вакансий указывается про печеньки в офисе, и не слова — про оборудование, возможность удаленной работы и т.д.
    • 0
      По поводу пункта 3, про который не спрашивают — дык, вы сами почему-то об этом ни хотите рассказывать. У меня на каждом собеседовании есть пункт — вот в кратце нам нужно это-это-это, я поже расскажу подробее, а пока раскажите о себе и своем опыте работы, то что вы считаете важным". И молчат как партизаны…
      • +2
        Просто люди не любят открытые вопросы. Если не возражаете, я вам отвечу не конкретно про гитхаб и т.д., а более абстрактно. У меня тоже часто спрашивали «расскажите о себе». И вроде понятно, что они хотят услышать что-то об опыте, о каких-то достижениях в работе, и так далее, но вопрос все равно звучит глупо, и так и порывает ответить что-то вроде «Люблю черный кофе, играю на электрогитаре, в свободное время пересматриваю Star Trek TOS».

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

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

    Кажется, я догадываюсь, почему вас никуда не брали…
    • 0
      Речь идёт о «малом промежутке времени».
      Скорее всего, большинство собеседований автор прошёл ещё до того, как получил фидбек по первому из них.
  • +13
    Я бы в джуниоре следующие главные черты выделил:
    — Нормальное отношение к критике (это вообще редкость)
    — Хорошая обучаемость
    — Базовый общепрограммерский бэкграунд
    — Горящие глаза :)

    Смысла спрашивать о чем-то сложнее книг «для чайников» нет.

    А вот знание паттернов на зубок, книг по рефакторингу Фаулера и еще over9000 признанных изданий может быть тревожным звоночком: человек без боевого опыта погрузившись в реальный продакшн средней софтверной компании офигеет насколько там всё «неправильно». Это приведет либо к конфликтам в команде, либо к плохому отношению к собственной работе.
    • +1
      Ага :) насчет офигеет «насколько там всё неправильно» это вы правильно заметили… Жизнь она далека от идеалов, надо конечно стремиться, но иногда «побочные трудозатраты по преведению в правильны вид» перевешивают основные :)

      А тут еще молодой и «умный» лезет со своими советами :D
      • 0
        Надо не к идеалам стремиться а четко понимать каким образом данный рефакторинг поможет достичь тех или иных целей. И исходя из этого принимать решение — делать или не делать.
        • 0
          Не цепляйтесь к словам :) именно это я и написал…
          • +1
            Я просто сформулировал вашу мысль ;)
  • +2
    Про домашнее задание зря. В моей практике домашнее задание отсеивало некоторых кандидатов. Почему. На выполнение задания нужно было потратить время и умственные усилия, причем в объеме несколько больше 15 минут. К тому же обычно результат мы ждали уже на следующий день. Если человек не сильно то хотел к нам попасть, он просто забивал. Другой вариант, человек не нашел времени и сил сделать домашнее задание, а что будет в реальной боевой обстановке тогда. Если результат домашки мы получали в этот же день и правильно сделанное, был высокий шанс, что человек будет с нами работать.
    • –1
      Это несерьезно. По сути вы хотите, чтобы человек бросил всё, и сидел делал для вас задание. Заметьте, он не знает, возьмут его, сделай он задание верно, или не возьмут. Может у него на следующий день 15 дел, которые нужно обязательно сделать, а тут вы со своим заданием.
      • 0
        Задание хорошо показывает целеустремленность кандидата. Если его задача приткнуть задницу в теплое место, куда возьмут, туда и хорошо, то выполнять задание не нужно. Если он хочет устроиться именно к вам, он не просто его выполнит, но и пояснит каждую строчку. Основная проблема джуниора — отсутствие практики. Любые тестовые задания расширяют его кругозор.
        • +2
          Если он хочет устроиться именно к вам

          Согласен. Но с таким подходом можно потерять кучу отличных кандидатов, которые могли бы быть вам очень полезны, но — увы — не хотели устроиться именно к вам.
          • +3
            Значит не судьба нам работать вместе. Тащить за руку к себе я не буду.
            • +1
              А у вас какая-то безумно классная компания, что кандидаты мечтают попасть именно к вам?
              • +1
                У меня задачи просто такие, что можно научиться очень многому. Кто это понимает и не пугается сложности задач, тот и домашнее задание выполняет, и еще и связь держит, если по каким-то причинам не получилось сотрудничать.
                • +1
                  А откуда они знают, какие именно у вас задачи? Или вы это про тестовое задание?
                  • 0
                    И про то, и про другое. Я обычно рассказываю, чем мы занимаемся. Потому что кому-то может быть не интересно развиваться в том направлении, что мы предлагаем.
      • 0
        Сотрудникам компании тоже нужнее работу работать, чем кандидатов собеседовать.
        Для них это отвлечение больше чем на 15 минут, и будет вполне справедливо, если и кандидат потратит свои 15 минут.
    • +1
      Тут вопрос в том, нужны Вам программисты, или программисты сами мечтают попасть в Вашу компанию, т.к. она лидер рынка. Лично я, практически никогда не делаю тестовых заданий (но я и не на джуна на собеседования хожу). Потому что тестовые задания как правило скучны, есть другие предложения, и есть чем ещё заняться.

      Если тестовое задание — интересно, то его можно сделать просто в качестве развлечения.
    • +3
      Мне тоже нравится идея домашнего задания, но имхо лучше его выдавать до реальной встречи и разрешать больше времени на выполнение. Задание на 1 — 2 часа, которое надо выполнить за неделю.

      В нынешней компании задание выдаёт наш агент, а мы видим резюме сразу с написанной программой. Если резюме нравится, а программа компилируется и в ней есть тесты, то просим агента позвать человека. Написанный код очень полезен во время технического собеседования. Можно сесть вдвоём и пройтись по коду, попросить что-то тут же изменить. Идеально показывает, на сколько человек в теме. И не надо мучать теоретическими вопросами, нам же важно, чтобы он писал, а не зазубрил книгу.
    • +2
      Всегда с удовольствием делаю интересные тестовые задания. Помогает расти и расширять кругозор. Однако «в этот же день» — это явно перебор. У меня есть текущие задачи и клиенты, которые мне платят. Я без проблем найду свободное время, чтобы сделать задание, но из-за этого не должна страдать основная на данный момент работа.
    • +1
      На следующий день — это перебор. Не надо обманывать себя и думать что человек хочет именно к вам. Человек ищет куда бы ему получше устроиться. У него сегодня и завтра еще несколько собеседований может быть.
      Я делал так: давал тестовое задание и просил чуть позже по почте прислать срок, когда оно будет выполнено. Таким образом и само задание посмотрим, и срок, и адекватность оценки человеком этого срока.
    • +1
      Можно давать и неделю на тестовое. Главное давать его до собеседования. Пришло резюме — в ответ посылаешь тестовое. Тогда не придётся тратить время на людей, которые заведомо не хотят у тебя работать. Вот автор темы говорит, что на 20 собеседований сходил. Это значит, что в 19 компаниях 1-2 высокооплачиваемых специалиста впустую потратили минимум по часу на разговор с ним — в сумме целая рабочая неделя насмарку, считай.
      • 0
        Не «впустую», конечно, они потратили это время за потенциальную возможность найти/нанять подходящего им кандидата.
    • +1
      Мне тестовые задания нравятся сразу по многим причинам.

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

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

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

      Но времени, конечно, лучше дать больше чем до вечера — мало ли как кандидат успел спланировать свой день. Или (так делал Фейсбук) заранее договориться: «Нульнадцатого мартобря в 13:37 мы вышлем тестовое задание, у вас на его исполнение будет ровно час до 14:37.»
  • НЛО прилетело и опубликовало эту надпись здесь
    • –4
      «Вы называете свои личные мыслишки как «антипаттерны» — это так умилительно наблюдать со стороны.» читая эту фразу у меня возникла мысль, что я задел Вас за живое))
      Выше я писал, что просто высказала в данной статье свои наблюдения.
      К тому же, Вы ошибаетесь, если думаете, что я устраивался на свою первую работу. Мне довелось поработать и в международной компании над крупным проектом, поэтому я представляю как все выглядит на самом деле.
  • +7
    Забавно. Автор ищет работу на позицию джуниора и полагает, что знает лучше PM, техлида и HR специалиста как им делать свою работу.
    • 0
      Автор нашел работу уж пару месяцев назад, если я верно понял.
    • +1
      Да ладно вам, как будто все HR, PM и техлиды — все сплошь признанные гуру собеседований.
  • +3
    А я люблю шаблонные вопросы. Такие знаете, типа: напишите рекурсивную функцию вычисляющую n-ое число фибоначи.
    Или напишите любой алгортим сортировки.
    Но только в интервью на junior'a.
    Мне кажется единственная цель этого интервью — определить какие базовые знания есть у человека. Если этих знаний достаточно — берем, и учим дальше.
    Если не достаточно (не достаточно для обучения) — отправляем читать книжки.
    • 0
      А нешаблонный вида: напишите нерекурсивную функцию для вычисления n-ного числа фибоначчи :)
      • 0
        А потом докажите, что она оптимальна по скорости работы. А если не оптимальна — потрудитесь объяснить, почему вы написали её именно так :) И в любом случае — не забудьте указать, для какого наибольшего N она выдаёт правильный ответ :D
  • 0
    еще лучше если ему расскажут что из него выйдет через год – полтора работы на данной должности


    Откуда hr в принципе это знать? Может человека возьмут, а он даже испытательный срок не пройдет. Вызубрил к собеседованию что-то, прошел, но обучаемость плохая и если не уволят, то через год вполне можно остаться тем же джуниором или схватывать на лету и вести парочку проектов (утрирую конечно, но идея думаю ясна). Или имеется ввиду «у нас есть сотрудники которые пришли джуниорами, а через год у него уже свой кабинет и личная массажистка, давайте ка к нам»? Если в больших компаниях и есть какая-то статистика и можно сказать «в среднем» (хотя что это в среднем может дать такого ценного), то в маленьких вполне возможно, что нанимают первого джуниора и сами не знают, что с ним может быть через год =)
  • 0
    Но я ни разу не был на собеседовании, на котором спрашивали все, то что указано в вакансии, зато меня не раз спрашивали по всему поему CV, где половина всего вообще никак не связана с желаемой должностью. К сожалению, так бывает в большинстве случаев. Здесь возможны 2 варианта, либо компания не понимает кто ей нужен, либо ей подходят абсолютно все и вакансию HR набросал копи пастом за 10 минут.


    Или проверить адекватность кандидата, хотя бы в оценке собственных знаний. А то бывает пишут Javascript средний уровень, а на деле хорошо если простенькую функцию напишут.
    К тому же, как вы сами заметили пунктом ранее, надо четко понимать чего ты хочешь от позиции, зачем акцентировать внимание на знании html если собеседуешься на позицию сурового серверного С++ программиста? Или не зная чего хочешь впихнул в резюме все о чем слышал и разослал его на разные позиции от фронт-енд девелопера до С++ и мобайл?
  • 0
    По поводу аккаунта на гитхабе и опенсурса, когда искала работу на джуниор позицию, везде спрашивали, есть ли какие-нибудь проекты, для себя, по учебе и тд. и могу ли я что-нибудь о них рассказать.
    Вот тут то и самое время рассказывать про опенсурс если таковой есть, про фриланс и про хабр если он повлиял на какой -то из проектов (аля… вот прочитал на хабре про knockaut.js и решил попробовать)
  • 0
    Это вы на junior собеседовались? Сложилось впечатление, что вы сами там всех собеседовали, а дай вам такую возможность — уволили бы добрые две трети встретившихся вам на собеседовании сотрудников, которые вас опрашивали… Респект.
    • НЛО прилетело и опубликовало эту надпись здесь
  • –1
    Google/Yandex/Bing не выдают одинаковые результаты кандидатам на вакансию и людям проводящим собеседование

    Да-да, во всех крупных поисковиках сидят специально обученные люди, которые пишут алгоритмы, определяющие к какой категории относится автор поискового запроса и выдающие в зависимости от этого разные результаты! :-)
  • 0
    Прошу меня извинить, я программирую на Java уже около пяти лет, но «пример кода;» ввел меня в ступор. Может ли кто-нибудь из уважаемой публики, пояснить, как работает приведенный пример и почему. Я знаю, порядок инициализации объектов в Java (статиечсикии поля, статическии блоки, не-статическии поля, не-статическии блоки, конструктор верхнего класса в иерархии наследования), но в данном примере никак не могу разобраться.
    • НЛО прилетело и опубликовало эту надпись здесь
    • +1
      Фишка в том, что при инициализации из супер класа вызывается метод наследника (вспоминаем про полиморфизм:)). Так как в Java не сущесвует перегрузки полей обявление переменной variable в класе B скрывает переменную супер класса. В методу происходит ее инициализация.
      После завершения работы конструктора супер класа и до начала выполнения кода в консрукторе наследуемого класа происходит инициализация всех полей даного класа.
      В этот момент переменной variable снова присваевается null.
      Соответственно, без явного присваивания переменная будет иметь то значени которое ей присвоили в методе.
      __________
      Я с данным примером столкнулся в нашем проекте на прошлой работе и вынес из него для себя один урок. Плохая практика вызывать методы из конструктора класа.
  • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    Что скажете о практике вообще не терять время на собеседование?
    • 0
      Это завуалированное собеседование, не больше. Шаблонный вопрос для отсеивания левых людей (сумма чисел от 1 до 99), тестовое задание (сделай патч), собственно собеседование (пиши нам, поговорим).
      • +1
        Нет никакого собеседования, и нет «пиши нам». Патч делает один из тысячи, и с ним уже нет смысла что-то обсуждать, он уже успешно работает над проектом.
        • 0
          Где же нет, когда «If you pass a trial test, we can further discuss and set up permanent job conditions: legal papers, social benefits, salary, preferred office location, etc.» где discuss — ссылка с mailto:? Вот это и есть собеседование.
          • +1
            can != must

            Там всё написано в FAQ, можно ничего не обсуждать. Например, ожидания человека по деньгам определяются в рамках тестового задания, так как оно оплачивается.

            Грубо говоря, если человек хочет служебный автомобиль, а не бесплатные обеды — на этом этапе такое можно обсуждать. Уже не обсуждается его способность работать.
            • 0
              Со столь малым количеством конкретной информации can превращается в must.

              «Например, ожидания человека по деньгам определяются в рамках тестового задания,» — без обсуждения с человеком? Это как?

              Давайте вспомним типичное собеседование: разговор о компании и проекте, тестовое задание, обсуждение его результатов, разговор о бенефитах. Чего именно у вас нет? На мой взгляд, все пункты присутствуют, просто растянуты по времени.
              • 0
                Разница в том, что вы обсуждаете не абстрактные наследования и сферических коней в вакууме, и практическую задачу и практические деньги.

                Например, чтобы поставить задачу в соответствии с таким подходом требуется много сил и общения. Но практического.
                • 0
                  Уровень практичности тестового задания — это техническая деталь, и варьироваться может в широких пределах. То, что в вашем случае оно предельно практично — это классно, это преимущество открытого кода. Но я бы не сказал, что в результате вы можете утверждать, что не тратите время на собеседование.
  • +3
    Прошу прощения, возможно я чмо не знаю некоторых вещей, но для меня вопрос «5 любимых рефакторингов» прозвучит примерно как «5 любимых замахов веником при подметании полов». То есть, ну они как бы все любимые, рефакторинги-то.

    А так статья офигенская, спасибочки.
  • –1
    Почему в тексте постоянно встречается одиночная закрывающаяся скобка? Обычно в конце предложения. Это какая-то новая фишка русского языка?
    • 0
      Русский язык эволюционирует конечно не так быстро как английский — но каждое поколение он сильно меняется. Ничего плохого в этом нет :)
      • +2
        Я действительно не понял, что это за скобочки. Даже возвращался глазами по тексту в поисках открывающей — чтобы правильно понять, где основная мысль, а где — пояснение :( Видимо это таки новый вид смайлов! И, судя по моей карме, все уже давно в теме :))

        Но всё же считаю, что если это действительно они, то автор всё-таки с этим переборщил.
        • 0
          Это всё тот же вид. Сначала было :-), потом :), теперь )… что будет дальше, и подумать страшно. Наверное, пробелы или #%^@&…
  • 0
    Сначала по прочтении статьи начал хмуриться и злиться, но потом вспомнил как 6 лет назад проходил свое первое собеседование и даже улыбнулся. Думал что-нибудь посоветовать, но всему научитесь сами с опытом, юношеский максимализм немного пройдет (насколько я могу судить в свои четверть века), а всеобщая злоба на плохие компании, злой мир и бестолковых собеседующих уйдет.

    Чему я истинно завидую — вашей энергии. 3.5 года работы на жестком аутсорсе у дяди почти убили мою внутреннюю мотивацию и энергию, теперь пестую ее по крупинкам в гораздо более солидном месте :) В целом, успехов!
  • 0
    А это нормально, что человек, собеседующийся на джуниора, рассказывает, как правильно его надо собеседовать? Не то чтобы я с чем-то в статье был несогласен, просто выглядит немного странно.
    • +2
      А это нормально, что человек, пользующийся какой-нибудь программой, рассказывает как этой программе следовало бы работать правильнее с его точки зрения? А ведь рассказывают, и разработчики их даже иногда слушают.
    • +1
      Скорее я хотел рассказать, как мне хотелось бы, чтобы меня собеседовали. Я написал свои мысли и хотел услышать мысли других в комментариях.
      Примечательно, что все кто реpко отозвался о статье ничего более существенного и конструктивного чем «вы не были по другую сторону баррикад» сказать не смогли.
      Никто не назвал хотя бы одну причину, что лично ему мешает придумать интересные вопросы для собеседования или предложить HR'ам давать кандидатам тестовое задание.
  • 0
    В больших компаниях все проще. Все знают, что там пересмотр зарплаты 2 раза в год. К тому же, крупные компании, как правило, готовы сразу платить неплохие деньги на junior позиции. По крайней мере туже средне рыночную ЗП там можно просить без зазрения совести. Просто поскольку крупная компания может себе позволить вложить в вас деньги авансом.


    Что это за компании такие? Сколько знаю крупных компаний (что профильные софтверные, что непрофильные типа банков с крупными айти-отделами), там лишние 5к рублей надбавки получить практически не возможно. Ну, по кр мере честным путём, без вылизывания руководства и подсиживания. Формально да, пересмотр зарплаты есть. Для этого нужно заполнить унизительную форму самооценки. Типа что вы сделали полезного для компании за прошедший год. А по итогам тебе говорят, что либо то, что ты сделал, не полезно, либо ты ничего полезного не сделал. И не волнует никого, что полезного ты не делал потому, что на каждый чих нужно десяток подписей собрать.

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

    Но это так, пример из жизни. Я к тому, что не верю я в крупные компании с регулярным пересмотром зарплаты.
    • 0
      Сколько знаю крупных компаний (что профильные софтверные, что непрофильные типа банков с крупными айти-отделами), там лишние 5к рублей надбавки получить практически не возможно.

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

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

      Что унизительного в том, чтобы ответить на вопрос, почему ваша работа теперь стоит дороже, нежели полгода тому?
      • +2
        Что унизительного в том, чтобы ответить на вопрос, почему ваша работа теперь стоит дороже, нежели полгода тому?


        Наёмный работник в большой компании не делает ничего по своей воле, он часть бизнес-процессов. Поэтому его «хорошесть» для компании есть результат не столько его деятельности, сколько движения, в которое он вовлечён. Всё равно что бросить камень а потом спрашивать у него, зачем он полетел.
      • 0
        Не надо забывать о рынке труда. Если рынок переживает дефицит кадров, то цена разработчику выростает, даже если он делает то же самое, что и полгода назад.
  • 0
    -промахнулся-
  • +1
    Очень понравилось видение автора процесса собеседования, доводы и прочие мысли из статьи.

    Вот чего я ещё не понимаю, так это когда на собеседованиях дают тест с вопросами например по Java,
    где приведены ситуации, тонкостей языка, таких тонкостей, которых никогда в разработке и не встретишь, даже сложно написать такое, и вот тебе нужно сказать что же будет, например если писать
    System.out.print(«This is» + 5 + 7 + "??? = " + 12);. Нет я понимаю это интересные тонкости языков, да, и для интереса нужно знать, но даже если ты такое напишешь у себя при разработке, ты сможешь увидеть за секунду что будет, и поправить как нужно, зачем мне знать на собеседовании что будет? Нет ну ладно, но когда ещё и судят по этому о знании языка, мне становится не понятна такая точка зрения. Такого рода задания можно встретить на тестах Oracle да, где ты именно хочешь получить сертификат что ты супер прошаренный в языке, но у нас тут собеседование и получение того что может кандидат, а не знает ли он странные тонкости языка.

    По моему мнению, нужно спрашивать чем человек занимался, примеры проектов может, как он их реализовывал, что интересного и проблемного было, отсюда сразу видно что усвоил из этих проектов кандидат. Так же некоторые вопросы по резюме, о языках которые были написаны, знание ООП например, что очень полезно, возможно некоторые известные полезные паттерны, отсюда видно что человек сможет написать довольно гибкий код в будущем и понимает весь процесс разработки, и в каких ситуациях вообще это нужно. Так же неплохо поинтересоваться университетской если таково имеется подготовкой, имеется ввиду что проходил, отсюда видно что человек изучал, и например в дополнении спросить пару логических заданий, что бы увидеть и не требовать очень правильного ответа, увидеть как человек мыслит, как он приходит к решению, неплохо конечно и алгоритмическая небольшая подготовка, что бы понимать как работаю структуры данных как хеши, деревья, мэпы и когда что лучше применять. Так же можно привести пример ситуации из продакшина, и спросить как бы эту ситуацию попытался разрулить кандидат, тоже полезно и видно сразу как человек сможет при условиях реальной разработки мыслить.
  • 0
    Мы пришли к простой схеме:

    1) Стандартное для всех собеседование по телефону длительностью час, из них первые полчаса — написание кода в расшаренном веб-блокноте. Тестовые задания простые, типа FizzBuzz или даже проще. Удивительно, но 50% претендентов на должность синьора отсеиваются на этом этапе. Вторые полчаса — теория (ООП, дизайн, алгоритмы). Индусы на этом этапе ведут себя очень смешно — ответы тарабанят без запинки, но попытка уточнить, почему именно так вызывает зависание. Также прошу обычно набросать простенький дизайн для некой стандартной задачи — ну, например, набросать дизайн очень простого GUI фреймворка.

    2) Следующий этап — тестовое задание. По времени — часа на 2-4.

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

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