Собеседование на 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 собеседовании»).

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

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

Подробнее
Реклама
Комментарии 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
                                    Да-да, типичное заблуждение ;)
                                      • +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
                                                                                          А меня спрашивали про «Есть ли акаунт на github;» и «Чаще всего используемые комбинации в IDE»
                                                                                          • +1
                                                                                            росто ответив на эти два вопроса, человек может показать программирует он что либо для себя или просто сидит и ждет, когда попадет на работу

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