Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 293
Солидное полотно однако:)
От себя добавлю, что бывает неплохо на какую-нибудь концептуальную вещь попросить привести жизненный пример. Вот приведет человек для полиморфизма аналогию из жизни — сразу понятно, что он понимает, что это такое, а не просто прочитал «100 вопросов на собеседовании»
Стандартные вопросы тоже не стоит оставлять без внимания. Вот например типичный диалог
— Что такое интерфейс в php (java, etc..) и зачем он нужен?
— Для реализации множественного наследования
— Так какой в этом смысл? Интерфейс содержит только сигнатуры методов, в итоге в классе все равно нужно будет заново объясвить эти методы и написать их код. Зачем такое наследование вообще нужно?
— …
Посему даже со стандартными вопросами можно понять, разобрался человек или просто забил свою голову различными комбинациями слов
От себя добавлю, что бывает неплохо на какую-нибудь концептуальную вещь попросить привести жизненный пример. Вот приведет человек для полиморфизма аналогию из жизни — сразу понятно, что он понимает, что это такое, а не просто прочитал «100 вопросов на собеседовании»
Стандартные вопросы тоже не стоит оставлять без внимания. Вот например типичный диалог
— Что такое интерфейс в php (java, etc..) и зачем он нужен?
— Для реализации множественного наследования
— Так какой в этом смысл? Интерфейс содержит только сигнатуры методов, в итоге в классе все равно нужно будет заново объясвить эти методы и написать их код. Зачем такое наследование вообще нужно?
— …
Посему даже со стандартными вопросами можно понять, разобрался человек или просто забил свою голову различными комбинациями слов
на самом деле, пример который вы описали как раз и не входит в «шаблонные» вопросы. шабонным и бородатым будет вопрос «чем отичается абстрактный клас и интерфейс?»
А вот четко сказать «зачем нужны интерфейсы?» не так уж и просто. Когда я отвечал на подобный вопрос меня прервали на полуслове со словами «ну juniorу это знать не обязательно»))
А вот четко сказать «зачем нужны интерфейсы?» не так уж и просто. Когда я отвечал на подобный вопрос меня прервали на полуслове со словами «ну juniorу это знать не обязательно»))
В плане примеров из жизни можно проще — объяснить своими словами, а не фразами из книги. Сразу увидите как человек излагает мысли.
Я вот статье просто поражаюсь. Человек даже еще не начал работать джуниором (о руководстве и речи не идет), а уже выкатывает простыню с заключениями о том, как нужно правильно нанимать. Без тени сомнения, главное. Это что, тенденция такая?
Моя статья не свод правил, как Вам могло показаться, а просто замечания с которыми думаю многие из нас сталкивались.
Хуже. Это правда жизни. Все он верно описывает.
При прочтении антипаттернов я сразу же узнал все приемы своего руководства. Причем сам никогда не понимал почему именно так нанимают.
При прочтении антипаттернов я сразу же узнал все приемы своего руководства. Причем сам никогда не понимал почему именно так нанимают.
Они возникают на плохом рынке, когда оптимальная стратегия лежит в оппортунистическом поведении, причем для обоих сторон при отсутствии регулятора. Гуглите lemon law и откуда он взялся.
Может всё же не все антипаттерны из статьи — в действительности антипаттерны?
IMHO зависит от интенсивности применения.
Меня вот собеседовали суммарно 5 человек на трех собеседованиях + был неоплачиваемый тестовый день. Нагоняет стресса, честно сказать… создает впечатление о компании как о весьма серьезной. До того работал в мелкой частной фирмочке с 4мя прогерами на 30 сотрудников… там как-то проще было… хотя туда меня и брали студентом на задачи, от которых 10 человек уже отказались, а те кто не отказался — хотели нормальных денег… чего от меня хотеть то было…
На словах — «все решаемо!». На практике у меня убогий стол, за которым устает спина, три переезда между комнатами за год работы со сменой столов — начал работу за тем же столом, за которым сейчас работаю. Тихий ужас. Руководству похрен. Отмазка «ну так мы ж работаем над заменой мебели!!!». Ага… 150-160 сотрудников, год не могут столы заменить… ага… работают…
Сейчас ищут еще 1 человека, тоже собеседуют толпой, дают задания домой, долгое время переписываются по почте чтобы что-то было доделано. А потом не берут на работу т.к. не уверены а надо ли вообще человек.
По вакансии спросили следующее:
1. Работал ли с Qt? Как долго?
2. Знаю ли я что такое матрица трансформации?
3. COM?
4. Паттерны?
5. Знаком ли с Linux?
Все. Ни задач, ничего.
Зато один (по моему опыту работы здесь — самый толковый из руководителей проектов) долго и упорно обсуждал со мной мои предыдущие проекты, как и что и почему я делал. Видимо, это и было важно для него. Вот с ним было да, интересно. Да и вообще дядька клевый. И по делу, и не пытался доминировать или показать какой он умный и т.п. При общении и так было понятно все.
Но он не мой руководитель…
Вот как-то так… 1 этап толковый, остальные все попали в описанные антипаттерны. И попали из-за своей неуместности в тех случаях, когда они применяются.
Меня вот собеседовали суммарно 5 человек на трех собеседованиях + был неоплачиваемый тестовый день. Нагоняет стресса, честно сказать… создает впечатление о компании как о весьма серьезной. До того работал в мелкой частной фирмочке с 4мя прогерами на 30 сотрудников… там как-то проще было… хотя туда меня и брали студентом на задачи, от которых 10 человек уже отказались, а те кто не отказался — хотели нормальных денег… чего от меня хотеть то было…
На словах — «все решаемо!». На практике у меня убогий стол, за которым устает спина, три переезда между комнатами за год работы со сменой столов — начал работу за тем же столом, за которым сейчас работаю. Тихий ужас. Руководству похрен. Отмазка «ну так мы ж работаем над заменой мебели!!!». Ага… 150-160 сотрудников, год не могут столы заменить… ага… работают…
Сейчас ищут еще 1 человека, тоже собеседуют толпой, дают задания домой, долгое время переписываются по почте чтобы что-то было доделано. А потом не берут на работу т.к. не уверены а надо ли вообще человек.
По вакансии спросили следующее:
1. Работал ли с Qt? Как долго?
2. Знаю ли я что такое матрица трансформации?
3. COM?
4. Паттерны?
5. Знаком ли с Linux?
Все. Ни задач, ничего.
Зато один (по моему опыту работы здесь — самый толковый из руководителей проектов) долго и упорно обсуждал со мной мои предыдущие проекты, как и что и почему я делал. Видимо, это и было важно для него. Вот с ним было да, интересно. Да и вообще дядька клевый. И по делу, и не пытался доминировать или показать какой он умный и т.п. При общении и так было понятно все.
Но он не мой руководитель…
Вот как-то так… 1 этап толковый, остальные все попали в описанные антипаттерны. И попали из-за своей неуместности в тех случаях, когда они применяются.
Между тем человек дело говорит. Поверьте моему немалому опыту найма программистов.
Да, когнитивный диссонанс между «джуниор» и этой статьёй возникает.
Я бы этого кандидата, пожалуй, взял :)
Да, когнитивный диссонанс между «джуниор» и этой статьёй возникает.
Я бы этого кандидата, пожалуй, взял :)
На вопрос по интерфейсам бывает даже миддл программисты затрудняются корректно ответить. Интерфейсы хитрый способ решить проблему множественного наследования. В Ruby этот вопрос решается через модули и такой способ гораздо понятнее, чем интерфейсы.
Повторяя свой комментарий, на вопрос Вы ответили так же, как джуниор.Только модули руби какие-то приплели
Посему следующий ход
Посему следующий ход
— Так какой в этом смысл? Интерфейс содержит только сигнатуры методов, в итоге в классе все равно нужно будет заново объясвить эти методы и написать их код. Зачем такое наследование вообще нужно?
У Вас вопрос сформулирован как то нечетко что ли. Какой смысл в наследовании от интерфейсов? или какой смысл в наследовании вообще? или есть наследование классов, какая роль у интерфейсов в этом? Согласитесь корректно и хорошо сформулированный вопрос повышает вероятность получить корректный ответ ). Что касается руби, так если джуниор знает о модулях в руби, а вы нет, разве это плохо? мне кажется наоборот плюс, он может сравнить два подхода, а вы нет.
Примеси в руби и интерфейсы в языках со статической типизацией — это абсолютно разные вещи и нужны для решения разных проблем.
Корректное сравнение подходов — подход с интерфейсами и подход с «утиной» типизацией.
Корректное сравнение подходов — подход с интерфейсами и подход с «утиной» типизацией.
Для меня концепция примесей или модулей абсолютно понятная и простая, а вот с интерфейсами до сих пор какие то проблемы. Буду признателен, если скините ссылочку на материал где эта концепция четко ясно и просто сформулирована или объяснена.
Немного не в тему, но определение интерфейса из википедии — это отличный пример того, как писать не надо…
Интерфейсы нужны для двух вещей:
1. Наследуя от интерфейса вы гарантируете, что у экземпляра класса есть некий определенный набор методов.
2. Так как наличие метода гарантировано, вы можете дернуть за него не зная класс, а зная только интерфейс.
Это очень похоже на то, зачем в ruby есть «утиная» типизация (если у объекта есть метод, вы можете его вызвать не зная к какому конкретному классу относится объект), только с той разницей, что если у объекта нет метода в ruby у вас будет эксепшн в рантайме, а, например, c# выдаст ошибку еще на этапе компиляции.
Возможность иметь общие интерфейсы у разных классов даже из разных иерархий позволяет реализовывать всякие интересные штуки — например в C# все коллекции имеют разные реализации одного и того же интерфейса, что позволяет иметь их эффективную реализацию одновременно с единообразными методами использования.
Посмотрите «принцип разделения интерфейсов» из SOLID, он проясняет смысл хорошо ;)
1. Наследуя от интерфейса вы гарантируете, что у экземпляра класса есть некий определенный набор методов.
2. Так как наличие метода гарантировано, вы можете дернуть за него не зная класс, а зная только интерфейс.
Это очень похоже на то, зачем в ruby есть «утиная» типизация (если у объекта есть метод, вы можете его вызвать не зная к какому конкретному классу относится объект), только с той разницей, что если у объекта нет метода в ruby у вас будет эксепшн в рантайме, а, например, c# выдаст ошибку еще на этапе компиляции.
Возможность иметь общие интерфейсы у разных классов даже из разных иерархий позволяет реализовывать всякие интересные штуки — например в C# все коллекции имеют разные реализации одного и того же интерфейса, что позволяет иметь их эффективную реализацию одновременно с единообразными методами использования.
Посмотрите «принцип разделения интерфейсов» из SOLID, он проясняет смысл хорошо ;)
Мне кажется ни пункт 1 ни пункт 2 не отвечают на вопрос зачем нужен интерфейс, а рассказывают больше как интерфейс работает. Какой все же ответ на вопрос, зачем/для чего нужен интерфейс?
Для того, чтобы гарантировать, что класс соблюдает контракт (содержит определенный набор методов).
а абстрактный класс делает тоже самое? значит он тоже интерфейс?
а базовый класс?
погодите, я запутался :)
а базовый класс?
погодите, я запутался :)
Абстрактный класс нужен для того, что бы человек, который реализовывал, соблюдал заложенные в него соглашения.
Другими словами.
Абстрактный класс — декларация соглашений на расширение системы.
Интерфейс — это соглашение по использованию системы.
Другими словами.
Абстрактный класс — декларация соглашений на расширение системы.
Интерфейс — это соглашение по использованию системы.
Абстрактный класс — декларация соглашений на расширение системы.
Через абстрактные классы можно тоже использовать систему без проблем.
Интерфейс — это соглашение по использованию системы.
Интерфейс вполне может быть соглашением на расширение системы.
Абстрактный класс нужен для того, что бы человек, который реализовывал, соблюдал заложенные в него соглашения.
Реализовывают интерфейсы, а не абстрактные классы. И они оба нужны, чтобы соблюдали соглашения, которые они декларируют.
Я надеюсь вы понимаете, что Ваше высказывание не выдерживает критики.
Через абстрактные классы можно тоже использовать систему без проблем.
Интерфейс — это соглашение по использованию системы.
Интерфейс вполне может быть соглашением на расширение системы.
Абстрактный класс нужен для того, что бы человек, который реализовывал, соблюдал заложенные в него соглашения.
Реализовывают интерфейсы, а не абстрактные классы. И они оба нужны, чтобы соблюдали соглашения, которые они декларируют.
Я надеюсь вы понимаете, что Ваше высказывание не выдерживает критики.
Через абстрактные классы можно тоже использовать систему без проблем.
Интерфейс вполне может быть соглашением на расширение системы.
Интерфейс указывает как использовать данный класс. Или же, если интерфейс в роли typehint методов некоторого класса, говорит как использовать данный класс, в бизнес-логики приложения.
Абстрактный класс сам по себе является указанием, как расширять систему с помощью его наследников.
Да, наверное ранее я слишком скомкано объяснил. Но понимание к вам придет со временем — это нормально.
Да, наверное ранее я слишком скомкано объяснил. Но понимание к вам придет со временем — это нормально.
Ко мне то придет конечно, меня беспокоит, что к Вам оно может не прийти.
Интерфейс указывает как использовать данный класс.
Интерфейс не принадлежит классу и ничего не знает о классе. Значит он не может указывать как использовать данный класс.
Или же, если интерфейс в роли typehint методов некоторого класса, говорит как использовать данный класс, в бизнес-логики приложения.
Создание интерфейсов, цель которых упросить работу со сложным внешним интерфейсом класса — вероятно не верное использование интерфейсов.
Абстрактный класс сам по себе является указанием, как расширять систему с помощью его наследников.
И интерфейс тоже является указанием, как расширять с помощью его наследников.
Возможно Вам лишь кажется, что Вы понимаете что к чему.
Ко мне то придет конечно, меня беспокоит, что к Вам оно может не прийти.
Интерфейс указывает как использовать данный класс.
Интерфейс не принадлежит классу и ничего не знает о классе. Значит он не может указывать как использовать данный класс.
Или же, если интерфейс в роли typehint методов некоторого класса, говорит как использовать данный класс, в бизнес-логики приложения.
Создание интерфейсов, цель которых упросить работу со сложным внешним интерфейсом класса — вероятно не верное использование интерфейсов.
Абстрактный класс сам по себе является указанием, как расширять систему с помощью его наследников.
И интерфейс тоже является указанием, как расширять с помощью его наследников.
Возможно Вам лишь кажется, что Вы понимаете что к чему.
Интерфейс не принадлежит классу и ничего не знает о классе. Значит он не может указывать как использовать данный класс.
Интерфейс указывает как использовать класс разработчику, когда мы говорим про реализацию классом интерфейса.
Создание интерфейсов, цель которых упросить работу со сложным внешним интерфейсом класса — вероятно не верное использование интерфейсов.
Тяжело мне понять вашу линию мысли, как вы пришли к этому от typehint'инга.
В любом случае, ООП предназначено для снижение сложности понимания, расширения и изменения системы. И интерфейсы как инструмент ООП предназначены для этих же целей.
И интерфейс тоже является указанием, как расширять с помощью его наследников.В интерфейсе нет указания того как расширять класс. В абстрактном классе есть — это абстрактные методы.
Естественно я говорю про все указания лишь на уровне описаний, ведь если нужно исследовать весь класс, для понимания, того как его расширить — то это не верная архитектура.
Интерфейс указывает как использовать класс разработчику, когда мы говорим про реализацию классом интерфейса.
Но ведь разработчик пользуется вовсе не классом, а просто объектом, который поддерживает данный интерфейс. Более того класс там может быть любой и даже может поменяться. Как же можно при этом говорить, что интерфейс указывает разработчику как использовать класс, если он (разработчик) может даже не догадываться о его (классе) существовании.
Я именно поэтому и говорил, что использовать интерфейс для упрощения работы с классом — это не совсем правильное его использование. Эту проблема обычно видна как набор классов с одноименными интерфейсами, которые они поддерживают. Или даже просто классы и их интерфейсы рядом в одной библиотеке. Для упрощения интерфейса доступа есть механизмы фасадов и т.д.
Фактически класс тоже имеет интерфейс — это набор его публичных полей. Чем он плох?
То есть интерфейс указывает не как использовать класс разработчику, а какой функционал должен поддерживать класс, чтобы его мог использовать разработик. То есть именно от потребностей разработчика и идут требования к составу интерфейса, а не от того, что может предоставить класс.
Под разработчиком я понимаю конечность какой то код — который использует интерфейс.
Тяжело мне понять вашу линию мысли, как вы пришли к этому от typehint'инга.
Видимо я просто неправильно понял что такое тайпхинтинг. Никогда не слышал про такой термин.
Не могли бы Вы пояснить что это?
В интерфейсе нет указания того как расширять класс. В абстрактном классе есть — это абстрактные методы.
Ну скажите какая принципиальная разница для класса что именно реализовывать — абстрактный метод или метод интерфейса? Между ними вообще хоть какая то разница есть?
Но ведь разработчик пользуется вовсе не классом, а просто объектом, который поддерживает данный интерфейс. Более того класс там может быть любой и даже может поменяться. Как же можно при этом говорить, что интерфейс указывает разработчику как использовать класс, если он (разработчик) может даже не догадываться о его (классе) существовании.
Я именно поэтому и говорил, что использовать интерфейс для упрощения работы с классом — это не совсем правильное его использование. Эту проблема обычно видна как набор классов с одноименными интерфейсами, которые они поддерживают. Или даже просто классы и их интерфейсы рядом в одной библиотеке. Для упрощения интерфейса доступа есть механизмы фасадов и т.д.
Фактически класс тоже имеет интерфейс — это набор его публичных полей. Чем он плох?
То есть интерфейс указывает не как использовать класс разработчику, а какой функционал должен поддерживать класс, чтобы его мог использовать разработик. То есть именно от потребностей разработчика и идут требования к составу интерфейса, а не от того, что может предоставить класс.
Под разработчиком я понимаю конечность какой то код — который использует интерфейс.
Тяжело мне понять вашу линию мысли, как вы пришли к этому от typehint'инга.
Видимо я просто неправильно понял что такое тайпхинтинг. Никогда не слышал про такой термин.
Не могли бы Вы пояснить что это?
В интерфейсе нет указания того как расширять класс. В абстрактном классе есть — это абстрактные методы.
Ну скажите какая принципиальная разница для класса что именно реализовывать — абстрактный метод или метод интерфейса? Между ними вообще хоть какая то разница есть?
Но ведь разработчик пользуется вовсе не классом, а просто объектом, который поддерживает данный интерфейс. Более того класс там может быть любой и даже может поменяться. Как же можно при этом говорить, что интерфейс указывает разработчику как использовать класс, если он (разработчик) может даже не догадываться о его (классе) существовании.
Разработчик не работает с экземплярами, он работает с классами. Вы когда смотрите на код, вы видите класс, его интерфейс и т.д. Когда вы берете код, который разрабатывал другой человек, то первое, на что вы смотрите — это его интерфейс.
Под разработчиком я понимаю конечность какой то код — который использует интерфейс.Код ради кода? Я говорю про людей, которые работают с кодом.
Видимо я просто неправильно понял что такое тайпхинтинг. Никогда не слышал про такой термин.Контракт аргумента метода/конструктора.
Не могли бы Вы пояснить что это?
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
}
Каким образом вы можете логически связать два этих кусочка кода?
Теперь рассмотрим обратную ситуацию, можем ли мы интерфейс заменить абстрактным классом?
— Если нет множественного наследования, то сразу можем ответить нет.
— Если вы используете стороннюю библиотеку, то при использовании их абстрактного класса, вы получаете не контролируемый код с вашей стороны. Да и вообще получается ахинея, смешение вашего и их кода.
— Если есть множественное наследование и мы не хотим что бы были проблемы с работой сторонними модулями, то создаем абстрактные классы без каких либо методов и ограничиваем их соглашением, что бы они были без реализации. В итоге приходим к тому, что бы полностью эмулируем итерфейсы.
Итак, вывод:
И табуреткой можно убить, но является ли оно холодным оружием?
хм. У меня тут складывается ощущение, что спорит дельфист с сишником, оба в своих терминах. В Си интерфейсы изначально (а то и по сей день) реализуются объявлением абстрактного класса и множественным наследованием. В Дельфи интерфейс — отдельная синтаксическая единица, и множественно унаследовать класс может только эти интерфейсы.
Но это же частности реализации, и к сути понятия интерфейс они не относятся! Сам интерфейс — это описание конкретной совокупности возможностей взаимодействия с объектом для его пользователя. И как именно он реализован — абсолютно не важно для понимания его назначения и описания общей пользы от выделения такого понятия…
Но это же частности реализации, и к сути понятия интерфейс они не относятся! Сам интерфейс — это описание конкретной совокупности возможностей взаимодействия с объектом для его пользователя. И как именно он реализован — абсолютно не важно для понимания его назначения и описания общей пользы от выделения такого понятия…
Насколько я понимаю, то, что вы описываете — это просто концепция полиморфизма.
И первый и второй пункт можно реализовать только наследованием безо всяких интерфейсов.
Собственно интерфейсы не наследуют, а реализуют.
И дело просто в том, что есть подход, при котором тот, кто использует некий класс фиксирует интерфейс взаимодействия с ним, а класс реализует данный интерфейс.
То есть интерфейс принадлежит тому, кто его использует. А тот или иной класс может его или поддерживать или нет.
В отличие от простого полиморфизма с помощью наследования, в котором просто используемый класс может вести себя по разному, но именно он диктует протокол взаимодействия с тем, кто его использует.
Собственно абстрактный класс — всего лишь обычный класс, экземпляры которого не имеют смысла сами по себе. И ничего больше.
И для того, чтобы это понимать никакие Солиды вам знать не надо. Элементарные вещи.
И первый и второй пункт можно реализовать только наследованием безо всяких интерфейсов.
Собственно интерфейсы не наследуют, а реализуют.
И дело просто в том, что есть подход, при котором тот, кто использует некий класс фиксирует интерфейс взаимодействия с ним, а класс реализует данный интерфейс.
То есть интерфейс принадлежит тому, кто его использует. А тот или иной класс может его или поддерживать или нет.
В отличие от простого полиморфизма с помощью наследования, в котором просто используемый класс может вести себя по разному, но именно он диктует протокол взаимодействия с тем, кто его использует.
Собственно абстрактный класс — всего лишь обычный класс, экземпляры которого не имеют смысла сами по себе. И ничего больше.
И для того, чтобы это понимать никакие Солиды вам знать не надо. Элементарные вещи.
Я бы добавил сюда ещё то что интерфейс нужен для того, что бы можно было показать принцип работы системы заложенный разработчиком.
Интерфейс — контракт. Абстрактный класс — прототип. =) Собственно с этой точки зрения можно и смотреть.
Кстати, вопрос специально всё же сформулирован «нечётко что ли». Я сам поступаю так на собеседованиях. Да, на хорошо сформулировав вопрос я с большей вероятностью получу верный ответ. Но моя цель — не получить верный ответ, а проверить пригодность конкретного человека на конкретную позицию. Мне не нужны шаблонные ответы на шаблонные вопросы. Хочется понять, сможет ли кандидат в условиях невозможности постоянной коммуникации с коллегами, нехватки точности и непротиворечивости в требованиях и целях задачи сопоставить в голове все варианты, их плюсы-минусы и осознанно найти компромисс. И можно ли будет доверять выбранному решению, т.к. не всегда есть время отмести его в зачатке.
Я не Java разработчик, но даже я знаю, что Java не поддерживает множественное наследование.
А интерфейсы, конечно же, нужны для унификации вызовов к объектам базового класа в тех случаях, когда мы не хотим даже знать, с каким именно дочернего класса объектом мы работаем. Т.е. цель — обращение к любому наследнику интерфейса как к объекту класса интерфейса без необходимости знать точную его реализацию.
А интерфейсы, конечно же, нужны для унификации вызовов к объектам базового класа в тех случаях, когда мы не хотим даже знать, с каким именно дочернего класса объектом мы работаем. Т.е. цель — обращение к любому наследнику интерфейса как к объекту класса интерфейса без необходимости знать точную его реализацию.
Да-да, типичное заблуждение ;)
Вы об этом?
www.javaportal.ru/java/articles/mnj.html
www.javaportal.ru/java/articles/mnj.html
Нет, я о том, что интерфейсы нужны НЕ для множественного наследования.
аааа, ну так это конечно же :)
Для чего же они тогда нужны? В двух словах поясните )
Я вот нашел по этой ссылочке. «Вместо множественного наследования классов в Java введено множественное наследование интерфейсов, при котором, как утверждается, никаких проблем не возникает.» Разве не об этом я сказал? что интерфейсы решают проблему множественного наследования? или они не решают ее )?
Так я выше написал, что это «типичное заблуждение». Интерфейсы проблему множественного наследования не решают никак.
Интерфейсы не решают проблему множественного наследования, но множественное наследование иногда используется для решения проблемы отсутствия интерфейсов (например в C++).
Откуда вы взяли «например в С++»?
В С++ очень даже есть интерфейсы.
В С++ очень даже есть интерфейсы.
О_о
Что, прямо-таки на уровне языка, отдельной конструкцией? Давно не касался C++, возможно что-то поменялось в последних стандартах. Сколько помню, в плюсах интерфейсы всегда реализовывались абстрактными классами с чисто виртуальными методами.
А в случае C вы можете то же самое утверждение привести со спуском до ассемблера.
Википедия вам в пруф того, что вы надумали лишнего.
Мы возвращаемся к вопросу и сразу ответу так чем же отличается абстрактный класс от интерфейса?
И вы как раз не провели черту между абстрактным классом и интерфейсом. Потому что чисто виртуальных методов не достаточно для того чтобы абстрактный класс стал интерфейсом.
Википедия вам в пруф того, что вы надумали лишнего.
Мы возвращаемся к вопросу и сразу ответу так чем же отличается абстрактный класс от интерфейса?
И вы как раз не провели черту между абстрактным классом и интерфейсом. Потому что чисто виртуальных методов не достаточно для того чтобы абстрактный класс стал интерфейсом.
Классов тоже нет. Есть нули и единицы. Да и их нет.
Вы правда дали ссылку на статью, в начале которой сказано «опишу эти отличия детально. Все перечисленное касается PHP» ???
omg
omg
Интерфейс как концепция, разумеется, существует везде, где существует ООП. Интерфейс, как отдельная фича языка — существует не во всех языках. Например, в C++ (в общем случае, когда класс поддерживает более одного интерфейса) интерфейсы реализуются обычно на уровне паттерна «открытое наследование от абстрактного класса с чисто виртуальными методами».
Так что я где напутал?
Так что я где напутал?
Интерфейс — открытый чисто абстрактный класс (нет реализации ни одного метода) без полей.
Не «содержит абстрактные методы», а «не содержит методов с реализацией».
Похоже, в игре слов начинаем путаться и придираться.
Не «содержит абстрактные методы», а «не содержит методов с реализацией».
Похоже, в игре слов начинаем путаться и придираться.
Абстрактный класс по умолчанию содержит чисто виртуальные методы, так что явно их упоминая я, конечно, имею в виду что все методы собственно интерфейса (в смысле концепции) чисто виртуальные (pure virtual). Как пишут вот тут: stackoverflow.com/a/318137 деструктор, все-таки, стоит объявлять нечистым. При этом я не считаю конструктор и деструктор частью собственно интерфейса, но это вообще вопрос спорный.
Значит, в C++ используется более мощная конструция. Не просто перечисление абстрактных методов, но и сразу реализация методов, которые могут быть выведены из базовых. Более надёжный способ, чем заставлять каждый класс, поддерживающий данный интерфейс, реализовывать их заново. Хорошо, что C++ это позволяет. Интересно, как это грамотно сделать в C#.
Если не ошибаюсь, в c# ведь можно объявлять абстрактные методы, это автоматически делает класс абстрактным. Почти никаких отличий от плюсов.
Такой «интерфейс» (с дополнительными методами) может быть только один — ведь множественного наследования нет.
>в c# ведь можно объявлять абстрактные методы, это автоматически делает класс абстрактным
Сам класс абстрактным от этого не становится. Просто данный метод можно вызвать абстрактно.
Сам класс абстрактным от этого не становится. Просто данный метод можно вызвать абстрактно.
Через extension methods.
Интерфейс существует задолго до того, как существует ООП. Какая-нибудь табличка функций драйвера, позволяющая другим программам общаться с ним, не зная структуры и реализации — это уже интерфейс. А никаких классов на этом уровне развития и в помине нет, всё программирование процедурное. Может быть, даже на ассемблере. При чём же тут ООП вообще?
Проще пример привести…
К примеру… есть графическая сцена.
На сцене все элементы (допустим, будут классы Line, Ellipce) должны иметь свой уникальный идентификатор (вот вам один предок SceneItem), должны быть графическими объектами не обязательно одного типа (вот вам второй уже «уникальный» предок GraphicsItem, в " т.к. в целом не обязательно), а еще каждый элемент должен иметь простейший интерфейс (например, fitToPage() и setBackground(...)) — вот вам третий предок PolymorphicItem.
Если бы интерфейсы решали проблему отсутствия множественного наследования — программист мог бы хранить указатели на PolymorphicItem там, где ему нужно только это и т.к. Это и есть заблуждающая сторона :)
А теперь вспоминаем, что у объектов есть и общий функционал в классах Sceneitem и GraphicsItem.
И вот когда нам нужно знать об объектах не более, чем то, что они элементы класса GraphicsItem, нам нужно множественное наследование, а интерфейсы уже ничем не помогут.
Или еще — вы расширяете архитектуру и вам нужно унаследоваться он существующего класса, но и некий интерфейс все равно нужен. И ОПА, а вы уже не можете т.к. не можете переписать тучу классов в интерфейсы.
К примеру… есть графическая сцена.
На сцене все элементы (допустим, будут классы Line, Ellipce) должны иметь свой уникальный идентификатор (вот вам один предок SceneItem), должны быть графическими объектами не обязательно одного типа (вот вам второй уже «уникальный» предок GraphicsItem, в " т.к. в целом не обязательно), а еще каждый элемент должен иметь простейший интерфейс (например, fitToPage() и setBackground(...)) — вот вам третий предок PolymorphicItem.
Если бы интерфейсы решали проблему отсутствия множественного наследования — программист мог бы хранить указатели на PolymorphicItem там, где ему нужно только это и т.к. Это и есть заблуждающая сторона :)
А теперь вспоминаем, что у объектов есть и общий функционал в классах Sceneitem и GraphicsItem.
И вот когда нам нужно знать об объектах не более, чем то, что они элементы класса GraphicsItem, нам нужно множественное наследование, а интерфейсы уже ничем не помогут.
Или еще — вы расширяете архитектуру и вам нужно унаследоваться он существующего класса, но и некий интерфейс все равно нужен. И ОПА, а вы уже не можете т.к. не можете переписать тучу классов в интерфейсы.
Ваш пример нарушает SRP, отчего вам и понадобилось множественное наследование.
Т.е. по вашему графический элемент не должен иметь своего, например, фона одновременно с возможностью быть, например, перемещенным по сцене? Вот это точно странно.
И как предлагаете этот функционал разделять по разным объектам, если объект на сцене должен быть один?
И как предлагаете этот функционал разделять по разным объектам, если объект на сцене должен быть один?
Вы не думали, что ваш пример можно архитектурно построить таким образом, что множественное наследование не понадобится?
Вы слышали про GoF, к примеру?
Вы слышали про GoF, к примеру?
Да. Данные о фоне и данные о положении в сцене — разные ответственности.
Т.е. по вашему графический элемент не должен иметь своего, например, фона одновременно с возможностью быть, например, перемещенным по сцене? Вот это точно странно.
А вы посмотрите как сделано в 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' );
}
});
Что касается странной дискуссии здесь и далее о множественном наследовании, рискну высказать свою точку зрения о том, что ни интерфейсы, ни классы не нужны для множественного наследования. Все втроём нужны, чтобы эффективно решать практические задачи. Которые достаточно часто нормально и без наследования решаются, и проще при этом.
За 2 года я встретил 1 человека, который смог мне показать свою учетку в SO. Про GitHub и Habr молчу. Уже особо и не спрашиваю =\. В последнее время просто начинаю с Fizz Buzz. Не смог — сразу пока.
Я понимаю, что я уже заранее не прошел ваше собеседование. Мне честно интересно, что такое Fizz Buzz и SO? Если первое гуглится, то что такое второе — я вообще не представляю.
Простите, что влезаю в дискуссию.
1. Про FizzBuzz есть статья на Хабре: habrahabr.ru/post/111843/. Думаю, после прочтения статьи вы поймете, что такое собеседование пройти не очень сложно, если есть хоть какие-то способности и желание программировать =).
2. SO — StackOverflow.com, сайт вопросов и ответов по программированию. Не совсем точным, но все же примером может быть Q&A Хабра.
1. Про FizzBuzz есть статья на Хабре: habrahabr.ru/post/111843/. Думаю, после прочтения статьи вы поймете, что такое собеседование пройти не очень сложно, если есть хоть какие-то способности и желание программировать =).
2. SO — StackOverflow.com, сайт вопросов и ответов по программированию. Не совсем точным, но все же примером может быть Q&A Хабра.
Я знаю, что такое stackoverflow (сколько сотен раз он меня выручал). :)
А вот о сокращении даже не подумал. За статью — спасибо (хотя у меня она первая в выдаче гугла).
А вот о сокращении даже не подумал. За статью — спасибо (хотя у меня она первая в выдаче гугла).
Прочитал про FizzBuzz. Общее впечатление — что собеседование с таким вопросом пройти очень сложно. Если заранее не предупреждают, какой код они хотят видеть — понятный, эффективный или интересный…
Есть подозрения, что так он назвал 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’.
Я тоже не понял сути.
Это задание невозможно зафейлить ведь о_О Если конечно в условиях нету использования полностью незнакомого языка или что-то в таком роде.
Это задание невозможно зафейлить ведь о_О Если конечно в условиях нету использования полностью незнакомого языка или что-то в таком роде.
Фейлят, даже те кто на Senior позиции идет=) Причем умудряются написать так, что код просто не рабочий. Пофиг что не оптимально и тд. Плюс на основе этой задачки можно дальше продолжать беседу, обсуждая различные условия и то, как они повлияют на решение. Но это для Junior. Для Senior — поговорить про DHT =))
Сколько любителей поминусовать и слить карму. Вот и делись опытом.
Учетку никто не требует, просто интересно посмотреть что человек спрашивал, чем интересовался, на что отвечал. Так же показывает что человек не сидит в своем коконе. Вы не поверите, я еще спрашиваю про блоги, которые человек регулярно читает. Просто StackOverflow обычно сокращают как SO. А FizzBuzz достаточно известная задачка, как уже ниже отписали. Она не сложная, но сразу помогает отсеять товарищей, которые не могут написать простой цикл. Причем ЯП не важен. Если человек мне на Ruby ее напишет, то ему только плюс за кругозор(мы не разрабатываем на Ruby). Просто когда проводишь по 3-4 собеседования в неделю — нет никакого желания тратить свое время на долгое и мутороное выковыривание знаний из претендента. Причем сразу еще и внимательность проверяется. 70% кандидатов бросаются решать задачу с такой первой строчкой: for(int i=0;i
Учетку никто не требует, просто интересно посмотреть что человек спрашивал, чем интересовался, на что отвечал. Так же показывает что человек не сидит в своем коконе. Вы не поверите, я еще спрашиваю про блоги, которые человек регулярно читает. Просто StackOverflow обычно сокращают как SO. А FizzBuzz достаточно известная задачка, как уже ниже отписали. Она не сложная, но сразу помогает отсеять товарищей, которые не могут написать простой цикл. Причем ЯП не важен. Если человек мне на Ruby ее напишет, то ему только плюс за кругозор(мы не разрабатываем на Ruby). Просто когда проводишь по 3-4 собеседования в неделю — нет никакого желания тратить свое время на долгое и мутороное выковыривание знаний из претендента. Причем сразу еще и внимательность проверяется. 70% кандидатов бросаются решать задачу с такой первой строчкой: for(int i=0;i
странная задача, хотя еще блее странно то, что она показательна.
Конечно сразу же после прочтения условия я подумал о банальном сравнении остатка от деления на 3, 5 и 15 с нулем.
Затем я посмотрел этот вашь коммент и вот это
Посмотрел статью на хабре об этой задаче. Увидел решение с темплейтом, с хардкодом и с заменой.
Ну, допустим, темплейт это хотя бы элегантно. А вот что хорошего в хардкоде???
Не доводилось работать с 384 кб памяти в arm sam 7 a3, когда память уже закончилась, а пользователь ДОЛЖЕН получить два варианта языков вывода оргомного количества длинных строк?
Конечно, то embed, а то desktop, но все же для меня такой подход вообще не является логичным и хоть как-нибудь оправданным.
Применительно к cpp — а зачем там вообще подход с темплейтом?
Ну да, можно было бы использовать не for, а while там какой или do while…
А в чем смысл?
Я, похоже, именно этого не понимаю…
Конечно сразу же после прочтения условия я подумал о банальном сравнении остатка от деления на 3, 5 и 15 с нулем.
Затем я посмотрел этот вашь коммент и вот это
70% кандидатов бросаются решать задачу с такой первой строчкой: for(int i=0;iя не понял. Мне покзаалось, что вам это не нравится. Не понятно — чем?
Посмотрел статью на хабре об этой задаче. Увидел решение с темплейтом, с хардкодом и с заменой.
Ну, допустим, темплейт это хотя бы элегантно. А вот что хорошего в хардкоде???
Не доводилось работать с 384 кб памяти в arm sam 7 a3, когда память уже закончилась, а пользователь ДОЛЖЕН получить два варианта языков вывода оргомного количества длинных строк?
Конечно, то embed, а то desktop, но все же для меня такой подход вообще не является логичным и хоть как-нибудь оправданным.
Применительно к cpp — а зачем там вообще подход с темплейтом?
Ну да, можно было бы использовать не for, а while там какой или do while…
А в чем смысл?
Я, похоже, именно этого не понимаю…
Есть подозрение, что там не делить проще, а умножать ;)
Единственное разумное объяснение — в задаче надо напечатать цифры от 1, а цикл инициализируется с 0. Как вывод — кандидат или не умеет читать задание (предложением раньше говорилось о внимательности), или не знает, что счетчик можно инициализировать в отличное от нуля значение.
Но как-то странно это.
Но как-то странно это.
Как раз в базе кандидат обычно предлагает обычное решение. А потом можно обсуждать с ним способы решения при дополнительных граничных условиях.
Но большая часть не может написать просто цикл! Просто обычный цикл. Я видел решение этой задачи в 30 строк кода с кучей if, причем там все равно была ошибка в логике.
Вот вам интересная статейка про задачу FizzBuzz is dead. Long live FizzBuzz! =)
Но большая часть не может написать просто цикл! Просто обычный цикл. Я видел решение этой задачи в 30 строк кода с кучей if, причем там все равно была ошибка в логике.
Вот вам интересная статейка про задачу FizzBuzz is dead. Long live FizzBuzz! =)
Сам не минусовал, но скажу — поделом минусуют. Не будете впредь шифровками изъясняться…
SO это не шифровка для подавляющего большинства разработчиков, особенно на Хабре(очень надеюсь). FizzBuzz — известная задачка, и на Хабре то же обсуждалась. Мы не в изоляции живем и работаем.
SO? Fizz Buzz? Что это? По-моему надо как раз начинать с гитхаба и хабра =)
Stack Overflow очень классный портал. Кстати, на нём же хантят многие агентства и последнюю роль, на которой работаю сейчас, мне предложили именно через него. У него же есть раздел с вакансиями.
Хотя для темы не очень актуально. Вообще не понятно, откуда graduate / junior программисту взять что-то, что можно «показать» на собеседовании.
Хотя для темы не очень актуально. Вообще не понятно, откуда graduate / junior программисту взять что-то, что можно «показать» на собеседовании.
Я обычно захожу туда за ответом на конкретный вопрос, очень-очень редко подходящего ответа нет. Сам я отвечал там 4 раза за 4 года, во двух случаях не было [подходящего] ответа и я решил проблему самостоятельно и поделился кодом.
Чтобы иметь приличную репутацию на SO надо там сидеть и планомерно отвечать на вопросы, я предпочитаю писать код и кодом же делиться, когда я таки-отвечаю на вопросы.
Чтобы иметь приличную репутацию на SO надо там сидеть и планомерно отвечать на вопросы, я предпочитаю писать код и кодом же делиться, когда я таки-отвечаю на вопросы.
Дело не в репутации. Можно посмотреть вопросы, которые задавал человек, и на основе этого получить чуточку большее понимание того, над чем он работал и на каком уровне. Причем иногда интересно посмотреть какой ответ он выбрал, и если аргументировал, то чем.
Кстати для ответов на сложные вопросы помогает bounty :). Это единственный ресурс, где мне смогли ответить на вопрос о том, какие сообщения я могу отправлять клиенту по протоколу WSTrust при возникновении ошибки. Сам просто пропустил это в огромном документе, а информации по этой теме ->0.
Этот вопрос вполне показывает то, над чем приходилось работать :)
Кстати для ответов на сложные вопросы помогает bounty :). Это единственный ресурс, где мне смогли ответить на вопрос о том, какие сообщения я могу отправлять клиенту по протоколу WSTrust при возникновении ошибки. Сам просто пропустил это в огромном документе, а информации по этой теме ->0.
Этот вопрос вполне показывает то, над чем приходилось работать :)
Интереса ради — не подскажете адрес вашего профиля на SO?
«Если честно, то на таком собеседовании» — не дописали. Впрочем, тут вычитывать и вычитывать. Но хотя бы есть что.
А меня спрашивали про «Есть ли акаунт на github;» и «Чаще всего используемые комбинации в IDE»
росто ответив на эти два вопроса, человек может показать программирует он что либо для себя или просто сидит и ждет, когда попадет на работу
Что-то не совсем понимаю: а что, разве без гитхаба нельзя программировать для себя? гитхаб — это как раз скорее для кого-то, а не для себя.
Можно, да неудобно и потеряться может. Если хотите только для себя, можно и приватный репозиторий на битбакете использовать.
говоря про два вопроса я имел в виду «5 рефакторингов...» и «комбинации в IDE».
Акаунт на гитхабедает понять, что вы, как минимум, имеете представление а даной системе. Может даже сталкивались с негатиным опытом совсестной разработки.?
Акаунт на гитхабедает понять, что вы, как минимум, имеете представление а даной системе. Может даже сталкивались с негатиным опытом совсестной разработки.?
У меня за >15 лет программирования ничего не потерялось.
Есть что-то совсем древнее без контроля версий. Более поздние — с использованием svn/mercurial/git
Но на гитхабе держу только пару проектов, которые я создал как раз не для себя, а для кого-то.
Есть что-то совсем древнее без контроля версий. Более поздние — с использованием svn/mercurial/git
Но на гитхабе держу только пару проектов, которые я создал как раз не для себя, а для кого-то.
Для себя есть tfs.visualstudio.com/
Почему Вы нигде перед «а» не ставите запятую… (Прошу прощения, нужно было написать в ЛС)
В чем разница между абстрактным классом и интерфейсом в C++?
Ну что же вы так… Интерфейсы и абстрактные классы это идеологически разные вещи :) И Junior'у действительно можно про это и не знать… хотя по-моему мнению, хороший junior должен владеть теорией… Уметь применять её не обязан, но на теоретическом уровне должен отвечать правильно на такие вопросы…
Хи-хи. Когда здесь не так давно в очередной раз обсуждали это, меня сильно минусовали и ещё сильнее пытались убедить, что «правильный» ответ — это то, что интерфейс — это абстрактный класс без реализованных методов, а не то, что интерфейс — это, прежде всего, контракт. Какое-то безумное количество юниоров на хабре ;).
Аргументация, была на уровне — ну, вот я пишу класс без реализаций, и, вот оно — вуаля, интерфейс! По факту. А думать — пусть лошадь думает, у неё голова большая…
Аргументация, была на уровне — ну, вот я пишу класс без реализаций, и, вот оно — вуаля, интерфейс! По факту. А думать — пусть лошадь думает, у неё голова большая…
Гыгг… ну бывает, хотя честно говоря удивлён… неужто и впрям засилие джуниоров… киньте ссылочкой почитать…
Может кто в книжке какой «умной» такое написал :D?
Если мозг mode off, то вполне себе похоже получается :)))
Может кто в книжке какой «умной» такое написал :D?
Если мозг mode off, то вполне себе похоже получается :)))
А какой правильный ответ?
Правильность ответа зависит от того для чего вы используете интерфейсы :).
Ведь если вы не используете интерфейсы в качестве описания контрактов, то для вас это будут всего лишь абстрактные классы без реализаций. И тут сразу встаёт более интересный вопрос — а какая вам в этом случае от них польза? :) Ну, а если сущность «абстрактный класс без реализаций» не приносит пользы, значит… :)
Ведь если вы не используете интерфейсы в качестве описания контрактов, то для вас это будут всего лишь абстрактные классы без реализаций. И тут сразу встаёт более интересный вопрос — а какая вам в этом случае от них польза? :) Ну, а если сущность «абстрактный класс без реализаций» не приносит пользы, значит… :)
Как какая польза? о_0 Да хотя бы тот факт, что реализовать вы можете сколько угодно большое количество интерфейсов… а наследование только от одного абстрактного класса…
Все относится к Java конечно
Все относится к Java конечно
Если рассуждать чисто технически, то у вас полная херь получилась. Ну, можно реализовывать и что? Всё равно же каждый раз надо реализовывать заново.
Вопрос в том зачем конкретному классу писать implements SomeInterface. А вот ответив на этот вопрос и придёте к мысли, что затем это всё делается, чтобы данный класс отвечал какому-то контракту. Не?
Вопрос в том зачем конкретному классу писать implements SomeInterface. А вот ответив на этот вопрос и придёте к мысли, что затем это всё делается, чтобы данный класс отвечал какому-то контракту. Не?
О боги!!!
В чем разница:
????????????????????????????
И первый и второй вариант «отвечает» какому-то контракту, согласно вашей терминологии.
Вот только во втором случае у вас гораздо больше степеней свободы.
В чем разница:
BaseClass obj = new ConcreteClass();
BaseInterface obj2 = new ConcreteClass();
????????????????????????????
И первый и второй вариант «отвечает» какому-то контракту, согласно вашей терминологии.
Вот только во втором случае у вас гораздо больше степеней свободы.
Народ, хватит спорить об одном и томже :) перечитайте друг друга, вы говорите про одно и тоже…
Что, собственно, вас смущает. Да, и там и там — контракты. И какой из них выбрать зависит от того, что вы собираетесь делать с объектом дальше. Во втором случае ваша свобода будет _ограничена_ (а вовсе не расширена) контрактом BaseInterface'а и если вам с объектом нужно что-то делать из того, что есть в BaseClass'е (или вообще в ConcreteClass'е), но отсутствует в интерфейсе, вы пролетаете со всеми вашими степенями свободы.
Я вам даже больше скажу, нередко объекты реализуют более одного контракта (втч непересекающихся) и каким способом вы станете объявлять переменную для ньюканья такого объекта? Не удачный у вас пример. Ограничен единственным способом использования. Но ведь есть и другие.
Я вам даже больше скажу, нередко объекты реализуют более одного контракта (втч непересекающихся) и каким способом вы станете объявлять переменную для ньюканья такого объекта? Не удачный у вас пример. Ограничен единственным способом использования. Но ведь есть и другие.
Простите, но по вашему у класса, не реализующего никаких интерфейсов, нет «контракта»?
А что такое интерфейс в с++?
Хороший вопрос;) Видимо, люди, которые выше бросились бурно обсуждать, знают ответ.
Понятие «интерфейс» в общем смысле не относится к какому-либо языку. То есть, если оставить вопрос в такой формулировке, то ответ не изменится — интерфейс это некоторая конструкция в коде программы, которая используется чтобы специфицировать предоставляемые классом/компонентом услуги.
Если вы хотите услышать про абстрактные классы, то правильнее будет спросить что-то вроде «как интерфейсы реализуются в языке таком-то».
Если вы хотите услышать про абстрактные классы, то правильнее будет спросить что-то вроде «как интерфейсы реализуются в языке таком-то».
Какая еще конструкция? Что будет за «некоторая конструкция» у класса, который ни от кого не наследуется? Или у него нет интерфейса, т.к. нет какой-то там конструкции?
Интерфейс это понятие находящееся вне какого-то языка и его конструкций. Это понятие описывает некий стандарт на общение с объектом. Если в языке присутствует множественное наследование (как например в C++), то да… Интерфейсы реализуются по средствам абстрактных классов… Но есть языки (и их НАМНОГО больше) в которых нет понятия абстрактных классов или множественного наследования. Интерфейсы в таких языках реализуются каким-то иным способом, вплоть до создания специального атрибута типа класса Interface… но это уже технические детали, а интерфейс это более абстрактное понятие…
Тобишь абстрактный класс при множественном наследовании это один из способов реализации интерфейса…
Тобишь абстрактный класс при множественном наследовании это один из способов реализации интерфейса…
Как реализуются интерфейсы в Ruby? Или там у классов нет интерфейсов?
Причем тут Ruby? Я Rubby не знаю, лезть и смотреть в интернетах тоже никакого желания нет… Вы знаете, вот и расскажите… хотя не понятно опять зачем-же???
Ruby притом, что вы упомянули множество других языков. Я привел в пример один из.
В Ruby нет множественного наследования, абстрактных классов и «интерфейсов» («специальных конструкций», атрибутов, абстракций и т.д.). Т.е. там у классов нет интерфейсов?
В Ruby нет множественного наследования, абстрактных классов и «интерфейсов» («специальных конструкций», атрибутов, абстракций и т.д.). Т.е. там у классов нет интерфейсов?
Вы не внимательно читали :)
Или правда в Ruby у классов нет аттрибутов? 8-( ) (сарказм mode on)
Или правда в Ruby у классов нет аттрибутов? 8-( ) (сарказм mode on)
Нет
И методов нет? :)))
Методы есть). И атрибуты есть (аналог свойств в C#, методов доступа).
«атрибуты» в скобках, я написал, т.к., видимо, неправильно прочитал «создания специального атрибута типа класса Interface», т.к. вы, скорее всего, забыли запятую. Я это понял как аналог атрибутов в C# или аннотаций в Java.
«атрибуты» в скобках, я написал, т.к., видимо, неправильно прочитал «создания специального атрибута типа класса Interface», т.к. вы, скорее всего, забыли запятую. Я это понял как аналог атрибутов в C# или аннотаций в Java.
[sarcasm mode]
В attr_reader и attr_accessor «attr» — это наверное сокращение от «attraction».
[/sarcasm mode]
В attr_reader и attr_accessor «attr» — это наверное сокращение от «attraction».
[/sarcasm mode]
Как так, там же есть для них даже специальные конструкции типа attr_accessor, attr_reader и attr_writer…
Как организовать интерфейсы у объектов, программист волен выбирать сам :)
Это полностью всегда остаётся на его совести, вплоть до реализации метода execute_iface в качестве аргумента которой передаётся название функции и её аргументы :)))
Именно про это я и написал :) что интерфейс это абстрактное понятие о том, как взаимодействовать с тем или иным объектом и конечно само описание класса тоже является интерфейсом :)))
Это полностью всегда остаётся на его совести, вплоть до реализации метода execute_iface в качестве аргумента которой передаётся название функции и её аргументы :)))
Именно про это я и написал :) что интерфейс это абстрактное понятие о том, как взаимодействовать с тем или иным объектом и конечно само описание класса тоже является интерфейсом :)))
В Ruby у классов есть интерфейсы, но в самом языке нет такой синтаксической конструкции. Потому что она там не нужна. В отличие от C#, например.
На сколько много больше?
«Некая конструкция» значит, что в разных языках интерфейсы реализованы по-разному. Например в C++ интерфейсы реализуются абстрактными классами, а в каком-нибудь другом языке еще интерфейсы реализуются специальными семантическими единицами, которые не имеют ничего общего с обычными классами.
Вы упорно переводите тему. У класса на С++, не наследующего другие классы (как абстрактные, так и нет), нет интерфейса?
Я не перевожу тему… Я всего лишь хочу сказать, что само понятие «интерфейс» не имеет отношения к конкретному языку программирования.
Выше был задан вопрос «А что такое интерфейс в с++? ».
Я обратил внимание на то, что, поскольку интерфейс — понятие, не имеющее отношения к языку (простите, я повторяюсь), то «интерфейс в С++», «интерфейс в java» и «интерфейс где-угодно-еще» это одно и то же. А если человек, проводящий собеседование (у нас топик про собеседования, кстати) хочет узнать, как интерфейсы реализуются в C++, то и спрашивать надо не «что такое...», а «как реализуются».
Выше был задан вопрос «А что такое интерфейс в с++? ».
Я обратил внимание на то, что, поскольку интерфейс — понятие, не имеющее отношения к языку (простите, я повторяюсь), то «интерфейс в С++», «интерфейс в java» и «интерфейс где-угодно-еще» это одно и то же. А если человек, проводящий собеседование (у нас топик про собеседования, кстати) хочет узнать, как интерфейсы реализуются в C++, то и спрашивать надо не «что такое...», а «как реализуются».
Ну просто зря вы используете термин «некая конструкция» :) Это не конструкция, это абстракция :) которая находится за рамками каких-то конкретных конструкций…
Понятие абстрактного базового класса в общем смысле тоже не относится к какому-либо языку.
Взгляд с другой стороны, несколько циничный (бекграунд: аутсорсинговая компания среднего размера (человек двести примерно), много проектов, много команд. своего опыта — 10+ лет в веб-разработке): кандидатов в джуниоры много, значительная часть непригодна. Стоимость false negative все же невелика (или такой воспринимается). Стоимость false positive, хоть и больше, но тоже не смертельна. Таким образом, задача собеседующего — быстро отсеять непригодных, из оставшихся, тоже не затрачивая лишних усилий (=денег) выбрать лучших. С этой точки зрения, ваши «антипаттерны» как раз становятся чуть ли не best practices эффективного отбора (эффективного по критерию цена/качество). Кроме пункта 4 (повторение — это неэффективно) и, возможно, пункта 6 (который я, честно говоря, вообще не понял).
Пройдусь по пунктам:
1) «Шаблонные вопросы». а) их недолго задать — экономим время. Даже если человек заучил на них ответы, то это, во-первых, показывает, что он не совсем просто так к нам пришел, а во-вторых — будет выявлено на паре дополнительных вопросов. Если кандидат просто растерялся — это обычно видно, и вопросы можно на ходу переформулировать. Если растерялся, но не показал виду — ну что ж, отсеем. Не страшно, поскольку см. пункт про стоимость false negative. б) задавая одинаковые вопросы всем, получаешь возможность сравнить кандидатов. в) кандидат в джуниоры, как правило, уникальным профессиональным опытом не обладает, так что подогнать лично под него вопросы все равно не получится.
2) «Зачем спрашивать по вакансии?». Кандидат в джуниоры, в общем случае, оформившимся программистом еще не является. Возможно, он подойдет в другой отдел, в котором в данный временной отрезок есть большая нужда в работниках (возможно, даже для галочки, так тоже бывает), или требования к скиллам меньше. По вакансии-то спросим, но и по резюме поспрашиваем.
3) «Проведем собеседование всей компанией». Три человека на собеседовании — вполне обычно. У нас — HR, тим-(тех)-лид, старший разработчик. HR рассказывает о компании, выясняет пожелания кандидата, в процессе технического собеседования — смотрит на реакции кандидата и потом дает рекомендации психологического толка тимлиду. Тимлид, со своей стороны, оценивает пригодность данного кандидата для данного проекта/команды, как с технической, так и с коммуникативной стороны. Старший разработчик присутствует для более объективной оценки кандидата с технической стороны (после собеседования они обсуждают кандидата с тимлидом).
5) «Никогда не давайте тестовые задания домой. Никогда!». Вы совершенно верно отметили, это занимает слишком много времени. Для позиции джуниора домашние задания, по моему мнению, совершенно излишни.
Best practices:
1) «Распараллеливание задач». Так все и есть, все те люди, которых вы упоминали в пункте 3 «антипаттернов» занимаются на собеседовании своими специфическими задачами.
2) «Про все что вы не спросили – должен рассказать вам HR.». Верно. У стандартного эйчара на стандартную вакансию в компании должен быть заготовлен стандартный спич. Оплата, пересмотры, отпуска, бонусы, развлекалово, командировки, время работы офиса, график рабочего дня и т.д. Позиция джуниора вполне стандартна.
3) «Все плюшки компании сразу». Те плюшки, которые доступны всем сотрудникам должны быть включены в стандартный спич эйчара. Индивидуальные плюшки могут не упоминаться, поскольку индивидуальны и получаются обычно за какие-либо заслуги.
4) «Четко определенные цели и задачи». Не очень актуально для джуниоров. Большинство не знают, чего хотят, компания не знает, что они могут, и рассчитывает присмотреться позже, во время испытательного срока/первого года работы. «Компания, которая берет себе junior программиста должна четко понимать, кого она хочет из него сделать через лет 3-4.» — редкий джуниордолетит до середины Днепра доживет до этого срока. А уж с неизменными устремлениями — и того меньше. Так что, что получится из этого джуниора, то и получится.
5) «Вопросы по вакансии, а не по резюме». См. аналогичный пункт «антипаттернов».
6) «Не надо ждать фидбэк. Никогда.». Отсутствие фидбека — свинство со стороны работодателя.
7) «Определение размера ЗП и сроков ее пересмотра.». Пересмотр раз в пол-года. Это хорошо и так должно быть.
Пройдусь по пунктам:
1) «Шаблонные вопросы». а) их недолго задать — экономим время. Даже если человек заучил на них ответы, то это, во-первых, показывает, что он не совсем просто так к нам пришел, а во-вторых — будет выявлено на паре дополнительных вопросов. Если кандидат просто растерялся — это обычно видно, и вопросы можно на ходу переформулировать. Если растерялся, но не показал виду — ну что ж, отсеем. Не страшно, поскольку см. пункт про стоимость false negative. б) задавая одинаковые вопросы всем, получаешь возможность сравнить кандидатов. в) кандидат в джуниоры, как правило, уникальным профессиональным опытом не обладает, так что подогнать лично под него вопросы все равно не получится.
2) «Зачем спрашивать по вакансии?». Кандидат в джуниоры, в общем случае, оформившимся программистом еще не является. Возможно, он подойдет в другой отдел, в котором в данный временной отрезок есть большая нужда в работниках (возможно, даже для галочки, так тоже бывает), или требования к скиллам меньше. По вакансии-то спросим, но и по резюме поспрашиваем.
3) «Проведем собеседование всей компанией». Три человека на собеседовании — вполне обычно. У нас — HR, тим-(тех)-лид, старший разработчик. HR рассказывает о компании, выясняет пожелания кандидата, в процессе технического собеседования — смотрит на реакции кандидата и потом дает рекомендации психологического толка тимлиду. Тимлид, со своей стороны, оценивает пригодность данного кандидата для данного проекта/команды, как с технической, так и с коммуникативной стороны. Старший разработчик присутствует для более объективной оценки кандидата с технической стороны (после собеседования они обсуждают кандидата с тимлидом).
5) «Никогда не давайте тестовые задания домой. Никогда!». Вы совершенно верно отметили, это занимает слишком много времени. Для позиции джуниора домашние задания, по моему мнению, совершенно излишни.
Best practices:
1) «Распараллеливание задач». Так все и есть, все те люди, которых вы упоминали в пункте 3 «антипаттернов» занимаются на собеседовании своими специфическими задачами.
2) «Про все что вы не спросили – должен рассказать вам HR.». Верно. У стандартного эйчара на стандартную вакансию в компании должен быть заготовлен стандартный спич. Оплата, пересмотры, отпуска, бонусы, развлекалово, командировки, время работы офиса, график рабочего дня и т.д. Позиция джуниора вполне стандартна.
3) «Все плюшки компании сразу». Те плюшки, которые доступны всем сотрудникам должны быть включены в стандартный спич эйчара. Индивидуальные плюшки могут не упоминаться, поскольку индивидуальны и получаются обычно за какие-либо заслуги.
4) «Четко определенные цели и задачи». Не очень актуально для джуниоров. Большинство не знают, чего хотят, компания не знает, что они могут, и рассчитывает присмотреться позже, во время испытательного срока/первого года работы. «Компания, которая берет себе junior программиста должна четко понимать, кого она хочет из него сделать через лет 3-4.» — редкий джуниор
5) «Вопросы по вакансии, а не по резюме». См. аналогичный пункт «антипаттернов».
6) «Не надо ждать фидбэк. Никогда.». Отсутствие фидбека — свинство со стороны работодателя.
7) «Определение размера ЗП и сроков ее пересмотра.». Пересмотр раз в пол-года. Это хорошо и так должно быть.
Я разве что про дз не соглашусь. У нас задание идет до собеседования и на нем отсеивается процентов 90 кандидатов. Задание достаточно простое, но дает возможность посмотреть как кандидат пишет код в тепличных условиях.
Вот с вами согласен.
1. Такое впечатление, что автор статьи не в курсе про ещё один фактор — состояние рынка.
Допустим, у нас в городе толковых спецов нет (свободных). Поэтому или переманиваешь из другой конторы, или берёшь то, что есть (если, конечно, интерес у кандидата обучаться есть), и лепишь из этого то, что надо. Это к слову о «компания не понимает, кто ей нужен или подходят все».
2. Я, если честно, не понял автора: сначала он говорит, что задавать специфические вопросы юниору — это антипаттерн, а потом это же и рекомендует в своих best practiсe.
3. Вывод: автор просто не был по другую сторону баррикад.
p.s. Соглашусь с комментарием 1ex, что современные юниоры — это смех и грех.
p.p.s. И напоследок: то ли у нас регион такой (Татарстан, Казань), то ли действительно новички зажрались.
1. Такое впечатление, что автор статьи не в курсе про ещё один фактор — состояние рынка.
Допустим, у нас в городе толковых спецов нет (свободных). Поэтому или переманиваешь из другой конторы, или берёшь то, что есть (если, конечно, интерес у кандидата обучаться есть), и лепишь из этого то, что надо. Это к слову о «компания не понимает, кто ей нужен или подходят все».
2. Я, если честно, не понял автора: сначала он говорит, что задавать специфические вопросы юниору — это антипаттерн, а потом это же и рекомендует в своих best practiсe.
3. Вывод: автор просто не был по другую сторону баррикад.
p.s. Соглашусь с комментарием 1ex, что современные юниоры — это смех и грех.
p.p.s. И напоследок: то ли у нас регион такой (Татарстан, Казань), то ли действительно новички зажрались.
«задавать специфические вопросы юниору — это антипаттерн». Я такого не говорил). Имелось введу заменить (изменить) стандартные вопросы. Скажем, вопросы по спискам, колекциям должны быть. Но, можно придумать что-то кроме стандартного «отличие между двумя реализациями List'а».
Я хотел скачать, что изменяя стандартные вопросы вы заставляете кандидата думать. И слушая ответ, можно понять, действтительно ли человек разбирается в теме, или говорит заученый ответ.
Я хотел скачать, что изменяя стандартные вопросы вы заставляете кандидата думать. И слушая ответ, можно понять, действтительно ли человек разбирается в теме, или говорит заученый ответ.
Беда в том, что кандидатов много (особенно джуниоров) и на каждого нестандартных вопросов не напридумываешь. Хитрые и интересные вопросы занимают много времени на «придумать», а кроме собеседований кандидатов есть и текущая работа, которая иногда должна быть сделана «вчера». Поэтому такие вопросы задаются по фактическому резюме senior девелоперам.
1. Извиняюсь, если не правильно вас понял, но как новичок может разбираться в теме? Он же начинающий.
2. Новичку никто не даст сразу сложных задач — как раз, скорее всего, будут шаблонные, на которые «заучены ответы».
3. Чтобы понять, умеет ли человек думать, лично мне достаточно одного-максимум двух вопросов не по теме.
4. К слову, забыл в первом комментарии упомянуть относительно чтения книг. Для меня намного важнее читает ли кандидат художественную литературу, а не техническую. Мне не нужен гик, который не может без кода и паттернов объяснить, что он предлагает. Поверьте, это выглядит очень убого, когда на вопрос в духе «Что вы предлагаете в этом случае», начинается мычание, «ээээ», «как бы», «типа», «вроде» в пачке с искажёнными цитатами из технических источников.
Поэтому я всегда советую по-больше читать художественной литературы — кроме всего прочего, она развивает образ мысли, словарный запас (который влияет, к слову, на сообразительность и эрудицию) и грамотность.
p.s. Спасибо за статью, но вам, прежде чем критиковать «другую сторону», стоит побывать на ней. Вы удивитесь, как изменится ваше мнение. Я желаю вам бурного развития и замечательных успехов. Статья на хабре в вашей копилке уже есть (: правда, не уверен, что все работодатели её оценят (:
2. Новичку никто не даст сразу сложных задач — как раз, скорее всего, будут шаблонные, на которые «заучены ответы».
3. Чтобы понять, умеет ли человек думать, лично мне достаточно одного-максимум двух вопросов не по теме.
4. К слову, забыл в первом комментарии упомянуть относительно чтения книг. Для меня намного важнее читает ли кандидат художественную литературу, а не техническую. Мне не нужен гик, который не может без кода и паттернов объяснить, что он предлагает. Поверьте, это выглядит очень убого, когда на вопрос в духе «Что вы предлагаете в этом случае», начинается мычание, «ээээ», «как бы», «типа», «вроде» в пачке с искажёнными цитатами из технических источников.
Поэтому я всегда советую по-больше читать художественной литературы — кроме всего прочего, она развивает образ мысли, словарный запас (который влияет, к слову, на сообразительность и эрудицию) и грамотность.
p.s. Спасибо за статью, но вам, прежде чем критиковать «другую сторону», стоит побывать на ней. Вы удивитесь, как изменится ваше мнение. Я желаю вам бурного развития и замечательных успехов. Статья на хабре в вашей копилке уже есть (: правда, не уверен, что все работодатели её оценят (:
Антипаттерны собеседования джуниора? Это какой то оксюморон. До четвертого пункта читал — улыбался, после читал — хмурился, ну и молодняк пошел — к сожалению или к счастью, кто знает.
«Ах, собеседующие, зачем вы утомляете меня этими скучными вопросами, я на них уже вчера отвечал»
Справедливости ради соглашусь с пунктами про ГитХаб и Хабр, но если яйца есть и есть чем — сам похвастается.
Про 5 любимых рефакторингов спрашивать у джуниора — даже слов нет, одни буквы
«Ах, собеседующие, зачем вы утомляете меня этими скучными вопросами, я на них уже вчера отвечал»
Справедливости ради соглашусь с пунктами про ГитХаб и Хабр, но если яйца есть и есть чем — сам похвастается.
Про 5 любимых рефакторингов спрашивать у джуниора — даже слов нет, одни буквы
а почему бы и не спросить? вполне может быть, что человек прочитал Фаулера и знает что такое рефакторинг. Если он програмирует, даже сидя дома (в общаге) то 5 рефакторингов назвать будет не так уж и трудно.
Одно дело назвать (че-то читал).
Другое дело реально применять. Ну где джуниору активно применять рефакторинг? Жизненный цикл 99% его программ — сдал курсовую и уничтожил, чтобы никто не увидел этот позор.
Другое дело реально применять. Ну где джуниору активно применять рефакторинг? Жизненный цикл 99% его программ — сдал курсовую и уничтожил, чтобы никто не увидел этот позор.
>> 5) Вопросы по вакансии, а не по резюме.
>> Конечно каждый несет ответственность за то,
>> что у него написано в CV. И я понимаю, что
>> если у меня указаны C++ или JavaScript меня могут
>> спросить по любому из этих языков, даже если они
>> не есть моими профильными.
Я считаю, что нужно обязательно спросить обо всем, что есть в резюме в разделе заявленных навыков.
Если есть Pascal и Assembler – без проблем:
А можно ли Assembler использовать внутри Pascal?
А как создать класс на Pascal?
C++(STL)?
Я понимаю, что на этом языке была сделана последняя и единственная лаба в институте, но про контейнеры в STL я обязательно спрошу. Просто: перечислите те, которые помните.
И все равно, что вы тестировщиком к нам устраиваетесь.
Все, что перечислено в резюме в разделе «навыки» должно быть покрыто вопросами, пусть даже самыми простыми. Иначе, почему оно там?
Все очень просто. Люди врут. Но, на их языке это «преувеличение»
А за статью – спасибо. Очень классно написано.
>> Конечно каждый несет ответственность за то,
>> что у него написано в CV. И я понимаю, что
>> если у меня указаны C++ или JavaScript меня могут
>> спросить по любому из этих языков, даже если они
>> не есть моими профильными.
Я считаю, что нужно обязательно спросить обо всем, что есть в резюме в разделе заявленных навыков.
Если есть Pascal и Assembler – без проблем:
А можно ли Assembler использовать внутри Pascal?
А как создать класс на Pascal?
C++(STL)?
Я понимаю, что на этом языке была сделана последняя и единственная лаба в институте, но про контейнеры в STL я обязательно спрошу. Просто: перечислите те, которые помните.
И все равно, что вы тестировщиком к нам устраиваетесь.
Все, что перечислено в резюме в разделе «навыки» должно быть покрыто вопросами, пусть даже самыми простыми. Иначе, почему оно там?
Все очень просто. Люди врут. Но, на их языке это «преувеличение»
А за статью – спасибо. Очень классно написано.
фишка в том, что если написано — нужно спросить, хотя бы один вопрос, чтобы понять насколько человек врет. Если человек пишет, что у него флюент инглиш, то собеседование начнется на английском. Ибо нефиг
Простите, вам хорошего спеца надо нанять, или резюме проверить?
Да, если человек врёт в резюме — это не хорошо. Но с другой стороны, он мог вписать С++ в резюме, потому что учил его 5 лет назад в универе. И конечно же, уже забыл как пользоваться указателями (а может и не разобрался толком). И если Вы его хотите брать на должность php разработчика — чем Выше указанный факт плох?
Да, если человек врёт в резюме — это не хорошо. Но с другой стороны, он мог вписать С++ в резюме, потому что учил его 5 лет назад в универе. И конечно же, уже забыл как пользоваться указателями (а может и не разобрался толком). И если Вы его хотите брать на должность php разработчика — чем Выше указанный факт плох?
Учил и забыл, но всё-равно вписал в раздел навыков? Раз вписал именно в этот раздел, значит, пусть и отвечает. Чем плох навык ответственности за свои слова? Это просто проверка такого навыка. :) Вот он вам так же скажет потом, что сделал очередное задание, но не сделает.
В конце-концов, если человеку так хочется упомянуть факт, что он «проходил» сипипи в институте, надо упоминать этот факт в соостветствующем разделе. Я себе такой отстойник в резюме завёл, куда скидываю ископаемые технологии вроде ассемблера PDP-11, паскаля для БЭСМ-6, Algol-60 и JCL для 1ВМ S/360 :). Так и назвал — ископаемые технологии :). Ни в коем случае не навыки. Ибо алгол я, конечно, разобрать смогу, а вот поругаться на JCL точно не осилю. Тут, впрочем, риск нарваться на кого-то, кто помнит минимален :).
В конце-концов, если человеку так хочется упомянуть факт, что он «проходил» сипипи в институте, надо упоминать этот факт в соостветствующем разделе. Я себе такой отстойник в резюме завёл, куда скидываю ископаемые технологии вроде ассемблера PDP-11, паскаля для БЭСМ-6, Algol-60 и JCL для 1ВМ S/360 :). Так и назвал — ископаемые технологии :). Ни в коем случае не навыки. Ибо алгол я, конечно, разобрать смогу, а вот поругаться на JCL точно не осилю. Тут, впрочем, риск нарваться на кого-то, кто помнит минимален :).
>>Я себе такой отстойник в резюме завёл
Но зачем?
>>Учил и забыл, но всё-равно вписал в раздел навыков? Раз вписал именно в этот раздел, значит, пусть и отвечает
У нас у всех разные понятия о «знаю». Обычно проблемы начинаются, когда нарываешься на спеца в технологии (скажем на PM который балуется C++). Но опять таки — к твоей текущей вакансии это не относится
Просто основная идея собеседования — всё таки понять, насколько человек соответствует вакансии, а не своему резюме. Резюме могло вообще взяться прошлогоднее, на требование HR
Но зачем?
>>Учил и забыл, но всё-равно вписал в раздел навыков? Раз вписал именно в этот раздел, значит, пусть и отвечает
У нас у всех разные понятия о «знаю». Обычно проблемы начинаются, когда нарываешься на спеца в технологии (скажем на PM который балуется C++). Но опять таки — к твоей текущей вакансии это не относится
Просто основная идея собеседования — всё таки понять, насколько человек соответствует вакансии, а не своему резюме. Резюме могло вообще взяться прошлогоднее, на требование HR
>Но зачем?
Это мой опыт. Он мне ценен. Интервьюеру он может дать информацию о моём кругозоре. Но отвечть на вопросы по тому же С++ я не готов и на данном интервью не намерен. Так зачем провоцировать интервьюера на эти вопросы, помещаяя С++ в раздел навыков? Опыт использования есть. Эта информация может быть ценной. Навыков на данный момент уже нет (ну, то есть я не готов сразу по выходу на работу писать на нём код). Логично поместить в отдельный раздел.
>У нас у всех разные понятия о «знаю».
Вот поэтому, в раздел навыков и не стоит помещать то, о чём не готов вести предметную беседу. Но оставить шанс для непредметной :).
>текущей вакансии это не относится
Ситуации бывают разные. Вполне возможно у работодателя есть более интересные для меня предложения, чем та конктретная вакансия на которую я пришёл собеседоваться. Зачем же себя заранее загонять в узкие рамки?
Это мой опыт. Он мне ценен. Интервьюеру он может дать информацию о моём кругозоре. Но отвечть на вопросы по тому же С++ я не готов и на данном интервью не намерен. Так зачем провоцировать интервьюера на эти вопросы, помещаяя С++ в раздел навыков? Опыт использования есть. Эта информация может быть ценной. Навыков на данный момент уже нет (ну, то есть я не готов сразу по выходу на работу писать на нём код). Логично поместить в отдельный раздел.
>У нас у всех разные понятия о «знаю».
Вот поэтому, в раздел навыков и не стоит помещать то, о чём не готов вести предметную беседу. Но оставить шанс для непредметной :).
>текущей вакансии это не относится
Ситуации бывают разные. Вполне возможно у работодателя есть более интересные для меня предложения, чем та конктретная вакансия на которую я пришёл собеседоваться. Зачем же себя заранее загонять в узкие рамки?
Мы знакомы? Imho, тебе нужно поучиться вежливости.
Ваш же вариант «заточки» смешон. Я что, должен оставлять в резюме ровно одну строку — только с теми самыми баззвордами, которые совпадают с требованиями вакансии? чушь какая — узкий специалист подобен флюсу, и если такое странное резюме и пройдёт совсем уж бестолкового кадровика, то первый технарь выбросит его в корзину со словами, — прикинь, чуваг 20 лет в отрасли, а осилил только гибернейт.
Даже «раздел для специалистов» не спасает если там только актуальные технологии перечислены. Вот какое мне дело, что какой-нибудь конкретный тупень не знает что такое Algol-60? Мне из-за него вычёркивать свой опыт работы? С какого такого хрена? Ясен пень я не расписываю несколько листов прозой про алголы-фортраны — достаточно строчки с перечислением через запятую.
И, да, я определённо считаю, что БЕЗ этой строчки моё резюме будет хуже, чем с нею.
И, нет, я не считаю, что резюме не требует «заточки» под позицию. Требует, но куда более грамотной и тонкой, чем просто выбрасывание всего, что не совпало с позицией. Ну, если только вы не стажёрско-юниорскую позицию подаётесь :), там, возможно, лучше всё повыкинуть нафиг. И то спорно.
Ваш же вариант «заточки» смешон. Я что, должен оставлять в резюме ровно одну строку — только с теми самыми баззвордами, которые совпадают с требованиями вакансии? чушь какая — узкий специалист подобен флюсу, и если такое странное резюме и пройдёт совсем уж бестолкового кадровика, то первый технарь выбросит его в корзину со словами, — прикинь, чуваг 20 лет в отрасли, а осилил только гибернейт.
Даже «раздел для специалистов» не спасает если там только актуальные технологии перечислены. Вот какое мне дело, что какой-нибудь конкретный тупень не знает что такое Algol-60? Мне из-за него вычёркивать свой опыт работы? С какого такого хрена? Ясен пень я не расписываю несколько листов прозой про алголы-фортраны — достаточно строчки с перечислением через запятую.
И, да, я определённо считаю, что БЕЗ этой строчки моё резюме будет хуже, чем с нею.
И, нет, я не считаю, что резюме не требует «заточки» под позицию. Требует, но куда более грамотной и тонкой, чем просто выбрасывание всего, что не совпало с позицией. Ну, если только вы не стажёрско-юниорскую позицию подаётесь :), там, возможно, лучше всё повыкинуть нафиг. И то спорно.
(я давно живу в стране, где слово «Вы» — по вполне разумным причинам — давно изжито),
Вообще-то изжито как раз «ты» (thou), а осталось «вы» (you, от арх. ye).
Чувачог немытый. Я тебе по секрету одын умный вещь скажу, только ты не обижайтся. Ты что-то в жизни проспал — это НЕ фидошка. Пора бы уже проснуться. :)
Что касается того, что там считают специалисты-теоретеги по составлению резюме (ахтоета? определённо люди невменяемые, ибо человеку вменяемому становиться специалистом по составлению резюме глупо — написал, нашёл работу, работаешь), мне до их мнения мало дела. Исключительно по той простой причине, что моё «неправильное» резюме попадает к нужным людям, а специалисты… ну пусть совершенствуют свой навык составления правильных резюме и дальше, если более ничего не умеют.
И, это… устраиваться на позицию, требующую знаний, которых у тебя пока нет, куда интереснее, чем крутиться в одном и том же забеге крысинных бегов. В принципе, я понял «специалистов» — если они хотят заниматься ровно тем же, чем занимались на предыдущем рабочем месте, то действительно, какой смысл писать о параллельных реальностях? Но это очень сильно не моё — я работу-то меняю, в основном, потому, что прежняя настолько хорошо изучена, что превратилась в рутину и набила оскомину. Зачем мне менять шило на мыло и скать точно такую же? Только ради того, чтобы стать специалистом по составлению резьюме? Глупость какая. Я лучше новые области покопаю.
Что касается того, что там считают специалисты-теоретеги по составлению резюме (ахтоета? определённо люди невменяемые, ибо человеку вменяемому становиться специалистом по составлению резюме глупо — написал, нашёл работу, работаешь), мне до их мнения мало дела. Исключительно по той простой причине, что моё «неправильное» резюме попадает к нужным людям, а специалисты… ну пусть совершенствуют свой навык составления правильных резюме и дальше, если более ничего не умеют.
И, это… устраиваться на позицию, требующую знаний, которых у тебя пока нет, куда интереснее, чем крутиться в одном и том же забеге крысинных бегов. В принципе, я понял «специалистов» — если они хотят заниматься ровно тем же, чем занимались на предыдущем рабочем месте, то действительно, какой смысл писать о параллельных реальностях? Но это очень сильно не моё — я работу-то меняю, в основном, потому, что прежняя настолько хорошо изучена, что превратилась в рутину и набила оскомину. Зачем мне менять шило на мыло и скать точно такую же? Только ради того, чтобы стать специалистом по составлению резьюме? Глупость какая. Я лучше новые области покопаю.
И, это… устраиваться на позицию, требующую знаний, которых у тебя пока нет, куда интереснее, чем крутиться в одном и том же забеге крысинных бегов.
Эээ… А возьмут? В наше-то время, когда по любой ИТ специальности есть сколько угодно выпускников с горящими глазами?
Туда где совсем не в зуб ногой — наверное, нет :). Но так наобум лезть смысла мало во всех смыслах. Хотя… тоже бывает… Как-то подрабатывал для одних, — когда договаривался вообще не знал пхп, который был нужон. Ну, оговорили, что период введения в курс дела (оплачиваемый!) будет несколько больше, чем если бы знал. Разумные люди довольно часто способны договориться :).
А так — говоришь, ну вот по этой теме я только читал и писал хелловорды, в смысле не писал ещё в этой теме продакшн-код, но кой чего разумею. Обязуюсь догнать и перегнать :). А свидетельством того, что я на это способен — вот тот самый списочек с чем я уже имел дело. Получить на работу профессионала, добавляющего к списку ещё один пункт часто гораздо безопаснее, чем получить выпускника у которого глаза хоть и горят, но чего от него ожидать не знает ни кто втч он сам. Как-то так.
А так — говоришь, ну вот по этой теме я только читал и писал хелловорды, в смысле не писал ещё в этой теме продакшн-код, но кой чего разумею. Обязуюсь догнать и перегнать :). А свидетельством того, что я на это способен — вот тот самый списочек с чем я уже имел дело. Получить на работу профессионала, добавляющего к списку ещё один пункт часто гораздо безопаснее, чем получить выпускника у которого глаза хоть и горят, но чего от него ожидать не знает ни кто втч он сам. Как-то так.
Про JCL не знаю, хотя системщики наверняка помнят. Но ассемблер PDP-11 — такая штука, которую забыть невозможно (по крайней мере, основы)… так что здесь можно и нарваться на желающих поговорить :)
Что делает команда
? :D
Что делает команда
MOV -(PC),-(PC)
? :D
Ничего святого не осталось в век гугла: сразу же находит, что это PDP-11 Self-Propagating Instruction
Подозреваю, что если идти в компанию, где есть (или скоро будет) отдел, занимающийся какими-нибудь прошивками на низком уровне, и есть желание со временем там оказаться, то указание любого ассемблера будет в плюс — хоть PDP 11, хоть Эльбрус, хоть Сетунь… чем больше, тем лучше (если действительно приходилось с этим иметь дело). «Потому что опыт есть, а опыт не пропьёшь»…
Хотя шансов на то, что за время работы на эту компанию действительно придётся написать хоть что-нибудь на ассемблере, исчезающе мало… Но по крайней мере, такой человек не будет бояться заглянуть в то, что нагенерил компилятор.
Хотя шансов на то, что за время работы на эту компанию действительно придётся написать хоть что-нибудь на ассемблере, исчезающе мало… Но по крайней мере, такой человек не будет бояться заглянуть в то, что нагенерил компилятор.
Нет, я написал именно компанию. На случай, если работа, для которой предназначена данная позиция, закончится, и как раз к этому времени развернётся проект по микрокодированию. А тут как раз специалист с опытом многочисленных ассмблеров под рукой, к тому же успевший вникнуть в суть проекта.
А на позицию фирмварщика сразу могут и не взять — там наверняка будет нужен специалист, уже имеющий опыт работы с ассемблером ARM и соответствующим железом… Тем более, в описанный момент эта позиция ещё не открыта.
А на позицию фирмварщика сразу могут и не взять — там наверняка будет нужен специалист, уже имеющий опыт работы с ассемблером ARM и соответствующим железом… Тем более, в описанный момент эта позиция ещё не открыта.
Знаете, я лучше ничего не знающего человека научу программингу, чем буду объяснять знающему, почему врать нехорошо, а потом он мне все сроки сорвет и наговорит всякого разного дерьма.
Немного скажу прелюдию: я всегда иду на senior разработчика или выше.
Последняя компания, куда я ходил на собеседование была очень приятной (привет собеседующим =) ).
Поспрашивали, поинтересовались.
Все понравилось, кроме одного: зп соразмерно потраченному времени (+2 часа потерянного времени на дорогу, а зп такая же).
Помню в прошлом была такая проблема: я не знал как и что называется, один собеседующий сказал, что без теории они не смогут меня научить c#…
Тогда я изучил теорию, полез глубже, узнал несколько нового для себя. В итоге термины не заучил, а просто объясняю своими словами — так проще и мне и видно что я понимаю что это.
В последствии c# я изучил сам, придя в компанию, где мне сказали: ну я думаю тебе будет не сложно…
Да, оказалось не сложно.
Меня больше всего всегда раздражали вопросы, которые полностью и подробно описаны в резюме — будто их не читали. Меня раздражала фамильярность: люди думают будто начальству все можно…
Сейчас получаю приглашения на работу в компании, где мне в прошлом отказывали.
Да, есть интересные предложения, но их меньшинство, т.к. от многих языков я уже ушел и возвращаться к ним буду только тогда, когда мне это понадобится.
Стандартные ответы никогда не читал: я их уже и так помню.
Единственное что не люблю — тестовые задания. Это порой выливается в какой-то бред.
У меня в одно время скопилось 20 исполненных тестовых заданий. В большинстве случаев отказ шел из-за того, что компании находились в других городах. Все были уверены что я быстро найду работу, а искал я ее пол года, что было печально.
Причем порой часто наблюдаю компании, которые твои ответы используют в своих целях, а тебе отказывают.
При это даешь сертификаты, ссылки на проекты, подробное описание исполненных работ и проектов… Это порой бывает грустно.
Я не люблю собеседования из-за форменного бреда, который часто там происходит. Бывают исключения, но они редки.
Последняя компания, куда я ходил на собеседование была очень приятной (привет собеседующим =) ).
Поспрашивали, поинтересовались.
Все понравилось, кроме одного: зп соразмерно потраченному времени (+2 часа потерянного времени на дорогу, а зп такая же).
Помню в прошлом была такая проблема: я не знал как и что называется, один собеседующий сказал, что без теории они не смогут меня научить c#…
Тогда я изучил теорию, полез глубже, узнал несколько нового для себя. В итоге термины не заучил, а просто объясняю своими словами — так проще и мне и видно что я понимаю что это.
В последствии c# я изучил сам, придя в компанию, где мне сказали: ну я думаю тебе будет не сложно…
Да, оказалось не сложно.
Меня больше всего всегда раздражали вопросы, которые полностью и подробно описаны в резюме — будто их не читали. Меня раздражала фамильярность: люди думают будто начальству все можно…
Сейчас получаю приглашения на работу в компании, где мне в прошлом отказывали.
Да, есть интересные предложения, но их меньшинство, т.к. от многих языков я уже ушел и возвращаться к ним буду только тогда, когда мне это понадобится.
Стандартные ответы никогда не читал: я их уже и так помню.
Единственное что не люблю — тестовые задания. Это порой выливается в какой-то бред.
У меня в одно время скопилось 20 исполненных тестовых заданий. В большинстве случаев отказ шел из-за того, что компании находились в других городах. Все были уверены что я быстро найду работу, а искал я ее пол года, что было печально.
Причем порой часто наблюдаю компании, которые твои ответы используют в своих целях, а тебе отказывают.
При это даешь сертификаты, ссылки на проекты, подробное описание исполненных работ и проектов… Это порой бывает грустно.
Я не люблю собеседования из-за форменного бреда, который часто там происходит. Бывают исключения, но они редки.
Меня раздражала фамильярность: люди думают будто начальству все можно…
Да, такое часто бывает. Собеседуемые, особенно если это их первая работа, тоже часто робеют и дают собеседующим лишний повод вести себя высокомерно =) Просто не все кандидаты понимают, что в момент собеседования кандидат и компания пытаются прийти к взаимовыгодному соглашению, а значит — играют на равных.
Меня больше всего всегда раздражали вопросы, которые полностью и подробно описаны в резюме — будто их не читали
Когда проводишь по собеседованию в день (а то и по два), вдумчиво читать резюме просто не хватает сил. И да, иногда полезно спрашивать повторно — у меня был случай, когда пришел претендент на должность Java синьора, с мега-опытом в Spring (судя по резюме), но не смог объяснить, что же такое инъекция.
Я — единственный девелопер в нашем филиале. Хотят нанять еще пару-тройку. На этой неделе собеседования были каждый день. HR не могут оценивать знания и отсеивать тех, кто приврал в резюме, это делаю я по телефону.
А как надо?
А как надо?
Объявление дали в начале января, вот к марту нашли 1 человека. Даже и не знаю, в чем дело. Требования не космические
Хочу прокомментировать пункт с тестовыми заданиями на дом.
Я участвовал в приеме на работу стажеров-разработчиков (это чуть ниже уровень, чем junior). Так вот проверяя задание, я обращаю внимание не на качество написания кода, а на «думалку» разработчика. Сколько банальных ошибок он мог предупредить, как хорошо умеет пользоваться гуглом. И очень многие кандидаты показывали умение пользоваться языком программирования, но полнейшее не умение пользоваться логикой.
А писать код красиво, хорошо и правильно должны уже мы его научить.
Я участвовал в приеме на работу стажеров-разработчиков (это чуть ниже уровень, чем junior). Так вот проверяя задание, я обращаю внимание не на качество написания кода, а на «думалку» разработчика. Сколько банальных ошибок он мог предупредить, как хорошо умеет пользоваться гуглом. И очень многие кандидаты показывали умение пользоваться языком программирования, но полнейшее не умение пользоваться логикой.
А писать код красиво, хорошо и правильно должны уже мы его научить.
В принципе со многим согласен, хочу остановиться буквально на нескольких моментах поподробнее (не по порядку):
1. Отсутствие фидбека — это просто несерьезно со стороны не то что уважающей компании, но даже лично со стороны уважающего себя HR-а. Это прекрасно показывает, что компании на вас наплевать, но, увы, встречается очень часто. Ну неужели так трудно хотя бы составить шаблонное письмо вроде «Здравствуйте, уважаемый Имярек, к сожалению в данный момент мы не готовы принять вас на работу, блаблабла» и имя подставлять? То ли они боятся отказывать, то ли считают, что это ниже их достоинства — непонятно.
2. Вопросы по резюме задавать нужно, ибо, как уже писали выше, люди часто пишут в резюме все подряд. Если не спрашивать — то определить, действительно ли он знает что-то, или написал это потому, что 3 года назад видел книжку в магазине, не получится.
3. Статьи на хабр, github, и т.д. Про хабр и участие в open-source меня не спрашивали никогда. Про последнюю прочитанную книгу — несколько раз было. Вообще это вопрос неплохой, но не стоит переоценивать его значимость. Например на Хабр можно писать статьи про законодательство в области IT, а в open-source заниматься составлением документации (что, не спорю, очень полезно для проекта), а эти вещи вам не очень помогут, например, писать сервер. Про системы контроля версий можно узнать гораздо менее завуалированным путем — тупо спросить, имел ли человек опыт работы с ними, и вкратце рассказать, что это такое.
4. 5 любимых рефакторингов, любимая комбинация в IDE. Честно говоря, мне кажется, что польза от этих вопросов сомнительная. Если человек никогда не участвовал в серьезных проектах, то далеко не факт, что ему приходилось заниматься рефакторигом, даже если Фаулера он прочитал. Про любимую комбинацию в IDE вообще не понятно зачем спрашивать. Ну вот скажу я вам, что моя любимая комбинация в Qt Creator это alt-enter. Как это поможет вам оценить меня?
5. Про все что вы не спросили – должен рассказать вам HR, Плюшки. Согласен с вашим мнением, но насчет плюшек вам нужно учитывать, что если человек 15 лет работает на стульях за $1000, то для него их наличие не является каким-то особым преимуществом — он к ним привык. Хотя вообще странно, что часто в описаниях вакансий указывается про печеньки в офисе, и не слова — про оборудование, возможность удаленной работы и т.д.
1. Отсутствие фидбека — это просто несерьезно со стороны не то что уважающей компании, но даже лично со стороны уважающего себя HR-а. Это прекрасно показывает, что компании на вас наплевать, но, увы, встречается очень часто. Ну неужели так трудно хотя бы составить шаблонное письмо вроде «Здравствуйте, уважаемый Имярек, к сожалению в данный момент мы не готовы принять вас на работу, блаблабла» и имя подставлять? То ли они боятся отказывать, то ли считают, что это ниже их достоинства — непонятно.
2. Вопросы по резюме задавать нужно, ибо, как уже писали выше, люди часто пишут в резюме все подряд. Если не спрашивать — то определить, действительно ли он знает что-то, или написал это потому, что 3 года назад видел книжку в магазине, не получится.
3. Статьи на хабр, github, и т.д. Про хабр и участие в open-source меня не спрашивали никогда. Про последнюю прочитанную книгу — несколько раз было. Вообще это вопрос неплохой, но не стоит переоценивать его значимость. Например на Хабр можно писать статьи про законодательство в области IT, а в open-source заниматься составлением документации (что, не спорю, очень полезно для проекта), а эти вещи вам не очень помогут, например, писать сервер. Про системы контроля версий можно узнать гораздо менее завуалированным путем — тупо спросить, имел ли человек опыт работы с ними, и вкратце рассказать, что это такое.
4. 5 любимых рефакторингов, любимая комбинация в IDE. Честно говоря, мне кажется, что польза от этих вопросов сомнительная. Если человек никогда не участвовал в серьезных проектах, то далеко не факт, что ему приходилось заниматься рефакторигом, даже если Фаулера он прочитал. Про любимую комбинацию в IDE вообще не понятно зачем спрашивать. Ну вот скажу я вам, что моя любимая комбинация в Qt Creator это alt-enter. Как это поможет вам оценить меня?
5. Про все что вы не спросили – должен рассказать вам HR, Плюшки. Согласен с вашим мнением, но насчет плюшек вам нужно учитывать, что если человек 15 лет работает на стульях за $1000, то для него их наличие не является каким-то особым преимуществом — он к ним привык. Хотя вообще странно, что часто в описаниях вакансий указывается про печеньки в офисе, и не слова — про оборудование, возможность удаленной работы и т.д.
По поводу пункта 3, про который не спрашивают — дык, вы сами почему-то об этом ни хотите рассказывать. У меня на каждом собеседовании есть пункт — вот в кратце нам нужно это-это-это, я поже расскажу подробее, а пока раскажите о себе и своем опыте работы, то что вы считаете важным". И молчат как партизаны…
Просто люди не любят открытые вопросы. Если не возражаете, я вам отвечу не конкретно про гитхаб и т.д., а более абстрактно. У меня тоже часто спрашивали «расскажите о себе». И вроде понятно, что они хотят услышать что-то об опыте, о каких-то достижениях в работе, и так далее, но вопрос все равно звучит глупо, и так и порывает ответить что-то вроде «Люблю черный кофе, играю на электрогитаре, в свободное время пересматриваю Star Trek TOS».
Точно такая же ситуация с другими открытыми вопросами «о себе», из серии «назовите ваши самые сильные и слабые стороны», «назовите ваше самое большое достижение в жизни», и так далее. Вроде шел устраиваться на программиста, а тут хотят чтобы ты сел, порефлексировал немножко, а потом изложил это им письменно. Плюс к тому, ведь человек, который будет это читать, ожидает ответы во вполне определенном духе. Вот представьте, что самым большим своим достижением я считаю то, что могу играть Iorn Maiden на арфе. Если вдуматься, то это большое дело, требующее усидчивости и целеустремленности. Но согласитесь, если я это напишу, мои шансы получить работу вряд ли повысятся, а скорее всего обо мне подумают «ну и идиот», и шансы эти понизятся.
Так же и с гитхабом, и с хабром, и со всем остальным. Некоторые люди будут хвастаться, а некоторые — стесняться, сидеть и молчать.
Точно такая же ситуация с другими открытыми вопросами «о себе», из серии «назовите ваши самые сильные и слабые стороны», «назовите ваше самое большое достижение в жизни», и так далее. Вроде шел устраиваться на программиста, а тут хотят чтобы ты сел, порефлексировал немножко, а потом изложил это им письменно. Плюс к тому, ведь человек, который будет это читать, ожидает ответы во вполне определенном духе. Вот представьте, что самым большим своим достижением я считаю то, что могу играть Iorn Maiden на арфе. Если вдуматься, то это большое дело, требующее усидчивости и целеустремленности. Но согласитесь, если я это напишу, мои шансы получить работу вряд ли повысятся, а скорее всего обо мне подумают «ну и идиот», и шансы эти понизятся.
Так же и с гитхабом, и с хабром, и со всем остальным. Некоторые люди будут хвастаться, а некоторые — стесняться, сидеть и молчать.
Не так давно я начал искать работу на позицию junior разработчика. Даже благодаря моему скромному резюме мне удалось побывать на не малом количестве собеседований за сравнительно малый промежуток времени.
Кажется, я догадываюсь, почему вас никуда не брали…
Я бы в джуниоре следующие главные черты выделил:
— Нормальное отношение к критике (это вообще редкость)
— Хорошая обучаемость
— Базовый общепрограммерский бэкграунд
— Горящие глаза :)
Смысла спрашивать о чем-то сложнее книг «для чайников» нет.
А вот знание паттернов на зубок, книг по рефакторингу Фаулера и еще over9000 признанных изданий может быть тревожным звоночком: человек без боевого опыта погрузившись в реальный продакшн средней софтверной компании офигеет насколько там всё «неправильно». Это приведет либо к конфликтам в команде, либо к плохому отношению к собственной работе.
— Нормальное отношение к критике (это вообще редкость)
— Хорошая обучаемость
— Базовый общепрограммерский бэкграунд
— Горящие глаза :)
Смысла спрашивать о чем-то сложнее книг «для чайников» нет.
А вот знание паттернов на зубок, книг по рефакторингу Фаулера и еще over9000 признанных изданий может быть тревожным звоночком: человек без боевого опыта погрузившись в реальный продакшн средней софтверной компании офигеет насколько там всё «неправильно». Это приведет либо к конфликтам в команде, либо к плохому отношению к собственной работе.
Про домашнее задание зря. В моей практике домашнее задание отсеивало некоторых кандидатов. Почему. На выполнение задания нужно было потратить время и умственные усилия, причем в объеме несколько больше 15 минут. К тому же обычно результат мы ждали уже на следующий день. Если человек не сильно то хотел к нам попасть, он просто забивал. Другой вариант, человек не нашел времени и сил сделать домашнее задание, а что будет в реальной боевой обстановке тогда. Если результат домашки мы получали в этот же день и правильно сделанное, был высокий шанс, что человек будет с нами работать.
Это несерьезно. По сути вы хотите, чтобы человек бросил всё, и сидел делал для вас задание. Заметьте, он не знает, возьмут его, сделай он задание верно, или не возьмут. Может у него на следующий день 15 дел, которые нужно обязательно сделать, а тут вы со своим заданием.
Задание хорошо показывает целеустремленность кандидата. Если его задача приткнуть задницу в теплое место, куда возьмут, туда и хорошо, то выполнять задание не нужно. Если он хочет устроиться именно к вам, он не просто его выполнит, но и пояснит каждую строчку. Основная проблема джуниора — отсутствие практики. Любые тестовые задания расширяют его кругозор.
Если он хочет устроиться именно к вам
Согласен. Но с таким подходом можно потерять кучу отличных кандидатов, которые могли бы быть вам очень полезны, но — увы — не хотели устроиться именно к вам.
Значит не судьба нам работать вместе. Тащить за руку к себе я не буду.
А у вас какая-то безумно классная компания, что кандидаты мечтают попасть именно к вам?
Сотрудникам компании тоже нужнее работу работать, чем кандидатов собеседовать.
Для них это отвлечение больше чем на 15 минут, и будет вполне справедливо, если и кандидат потратит свои 15 минут.
Для них это отвлечение больше чем на 15 минут, и будет вполне справедливо, если и кандидат потратит свои 15 минут.
Тут вопрос в том, нужны Вам программисты, или программисты сами мечтают попасть в Вашу компанию, т.к. она лидер рынка. Лично я, практически никогда не делаю тестовых заданий (но я и не на джуна на собеседования хожу). Потому что тестовые задания как правило скучны, есть другие предложения, и есть чем ещё заняться.
Если тестовое задание — интересно, то его можно сделать просто в качестве развлечения.
Если тестовое задание — интересно, то его можно сделать просто в качестве развлечения.
Мне тоже нравится идея домашнего задания, но имхо лучше его выдавать до реальной встречи и разрешать больше времени на выполнение. Задание на 1 — 2 часа, которое надо выполнить за неделю.
В нынешней компании задание выдаёт наш агент, а мы видим резюме сразу с написанной программой. Если резюме нравится, а программа компилируется и в ней есть тесты, то просим агента позвать человека. Написанный код очень полезен во время технического собеседования. Можно сесть вдвоём и пройтись по коду, попросить что-то тут же изменить. Идеально показывает, на сколько человек в теме. И не надо мучать теоретическими вопросами, нам же важно, чтобы он писал, а не зазубрил книгу.
В нынешней компании задание выдаёт наш агент, а мы видим резюме сразу с написанной программой. Если резюме нравится, а программа компилируется и в ней есть тесты, то просим агента позвать человека. Написанный код очень полезен во время технического собеседования. Можно сесть вдвоём и пройтись по коду, попросить что-то тут же изменить. Идеально показывает, на сколько человек в теме. И не надо мучать теоретическими вопросами, нам же важно, чтобы он писал, а не зазубрил книгу.
На следующий день — это перебор. Не надо обманывать себя и думать что человек хочет именно к вам. Человек ищет куда бы ему получше устроиться. У него сегодня и завтра еще несколько собеседований может быть.
Я делал так: давал тестовое задание и просил чуть позже по почте прислать срок, когда оно будет выполнено. Таким образом и само задание посмотрим, и срок, и адекватность оценки человеком этого срока.
Я делал так: давал тестовое задание и просил чуть позже по почте прислать срок, когда оно будет выполнено. Таким образом и само задание посмотрим, и срок, и адекватность оценки человеком этого срока.
Можно давать и неделю на тестовое. Главное давать его до собеседования. Пришло резюме — в ответ посылаешь тестовое. Тогда не придётся тратить время на людей, которые заведомо не хотят у тебя работать. Вот автор темы говорит, что на 20 собеседований сходил. Это значит, что в 19 компаниях 1-2 высокооплачиваемых специалиста впустую потратили минимум по часу на разговор с ним — в сумме целая рабочая неделя насмарку, считай.
Мне тестовые задания нравятся сразу по многим причинам.
Во-первых, мне психологически проще писать и документировать код, чем отвечать на устные вопросы. (Я и с начальником переписываюсь куда чаще, чем разговариваю вслух, пусть даже он сидит в шести метрах от меня.)
Я думаю, что не мне одному так.
Во-вторых, это и кандидату позволяет отсеивать нерелевантные вакансии ещё до собеседования. Объявления о вакансиях, как правило, дают намного меньше представления о том, чем придётся заниматься и с кем — чем такое представление дают тестовые задания.
В-третьих, задание позволяет обеим сторонам приготовиться к собеседованию, и не тратить время на то, чтобы объяснить кандидату задачу, подождать пока поймёт, подождать пока в спешке набросает решение — можно с самого начала собеседования перейти к предметному обсуждению.
Но времени, конечно, лучше дать больше чем до вечера — мало ли как кандидат успел спланировать свой день. Или (так делал Фейсбук) заранее договориться: «Нульнадцатого мартобря в 13:37 мы вышлем тестовое задание, у вас на его исполнение будет ровно час до 14:37.»
Во-первых, мне психологически проще писать и документировать код, чем отвечать на устные вопросы. (Я и с начальником переписываюсь куда чаще, чем разговариваю вслух, пусть даже он сидит в шести метрах от меня.)
Я думаю, что не мне одному так.
Во-вторых, это и кандидату позволяет отсеивать нерелевантные вакансии ещё до собеседования. Объявления о вакансиях, как правило, дают намного меньше представления о том, чем придётся заниматься и с кем — чем такое представление дают тестовые задания.
В-третьих, задание позволяет обеим сторонам приготовиться к собеседованию, и не тратить время на то, чтобы объяснить кандидату задачу, подождать пока поймёт, подождать пока в спешке набросает решение — можно с самого начала собеседования перейти к предметному обсуждению.
Но времени, конечно, лучше дать больше чем до вечера — мало ли как кандидат успел спланировать свой день. Или (так делал Фейсбук) заранее договориться: «Нульнадцатого мартобря в 13:37 мы вышлем тестовое задание, у вас на его исполнение будет ровно час до 14:37.»
«Вы называете свои личные мыслишки как «антипаттерны» — это так умилительно наблюдать со стороны.» читая эту фразу у меня возникла мысль, что я задел Вас за живое))
Выше я писал, что просто высказала в данной статье свои наблюдения.
К тому же, Вы ошибаетесь, если думаете, что я устраивался на свою первую работу. Мне довелось поработать и в международной компании над крупным проектом, поэтому я представляю как все выглядит на самом деле.
Выше я писал, что просто высказала в данной статье свои наблюдения.
К тому же, Вы ошибаетесь, если думаете, что я устраивался на свою первую работу. Мне довелось поработать и в международной компании над крупным проектом, поэтому я представляю как все выглядит на самом деле.
А я люблю шаблонные вопросы. Такие знаете, типа: напишите рекурсивную функцию вычисляющую n-ое число фибоначи.
Или напишите любой алгортим сортировки.
Но только в интервью на junior'a.
Мне кажется единственная цель этого интервью — определить какие базовые знания есть у человека. Если этих знаний достаточно — берем, и учим дальше.
Если не достаточно (не достаточно для обучения) — отправляем читать книжки.
Или напишите любой алгортим сортировки.
Но только в интервью на junior'a.
Мне кажется единственная цель этого интервью — определить какие базовые знания есть у человека. Если этих знаний достаточно — берем, и учим дальше.
Если не достаточно (не достаточно для обучения) — отправляем читать книжки.
еще лучше если ему расскажут что из него выйдет через год – полтора работы на данной должности
Откуда hr в принципе это знать? Может человека возьмут, а он даже испытательный срок не пройдет. Вызубрил к собеседованию что-то, прошел, но обучаемость плохая и если не уволят, то через год вполне можно остаться тем же джуниором или схватывать на лету и вести парочку проектов (утрирую конечно, но идея думаю ясна). Или имеется ввиду «у нас есть сотрудники которые пришли джуниорами, а через год у него уже свой кабинет и личная массажистка, давайте ка к нам»? Если в больших компаниях и есть какая-то статистика и можно сказать «в среднем» (хотя что это в среднем может дать такого ценного), то в маленьких вполне возможно, что нанимают первого джуниора и сами не знают, что с ним может быть через год =)
Но я ни разу не был на собеседовании, на котором спрашивали все, то что указано в вакансии, зато меня не раз спрашивали по всему поему CV, где половина всего вообще никак не связана с желаемой должностью. К сожалению, так бывает в большинстве случаев. Здесь возможны 2 варианта, либо компания не понимает кто ей нужен, либо ей подходят абсолютно все и вакансию HR набросал копи пастом за 10 минут.
Или проверить адекватность кандидата, хотя бы в оценке собственных знаний. А то бывает пишут Javascript средний уровень, а на деле хорошо если простенькую функцию напишут.
К тому же, как вы сами заметили пунктом ранее, надо четко понимать чего ты хочешь от позиции, зачем акцентировать внимание на знании html если собеседуешься на позицию сурового серверного С++ программиста? Или не зная чего хочешь впихнул в резюме все о чем слышал и разослал его на разные позиции от фронт-енд девелопера до С++ и мобайл?
По поводу аккаунта на гитхабе и опенсурса, когда искала работу на джуниор позицию, везде спрашивали, есть ли какие-нибудь проекты, для себя, по учебе и тд. и могу ли я что-нибудь о них рассказать.
Вот тут то и самое время рассказывать про опенсурс если таковой есть, про фриланс и про хабр если он повлиял на какой -то из проектов (аля… вот прочитал на хабре про knockaut.js и решил попробовать)
Вот тут то и самое время рассказывать про опенсурс если таковой есть, про фриланс и про хабр если он повлиял на какой -то из проектов (аля… вот прочитал на хабре про knockaut.js и решил попробовать)
Это вы на junior собеседовались? Сложилось впечатление, что вы сами там всех собеседовали, а дай вам такую возможность — уволили бы добрые две трети встретившихся вам на собеседовании сотрудников, которые вас опрашивали… Респект.
Google/Yandex/Bing не выдают одинаковые результаты кандидатам на вакансию и людям проводящим собеседование
Да-да, во всех крупных поисковиках сидят специально обученные люди, которые пишут алгоритмы, определяющие к какой категории относится автор поискового запроса и выдающие в зависимости от этого разные результаты! :-)
Прошу меня извинить, я программирую на Java уже около пяти лет, но «пример кода;» ввел меня в ступор. Может ли кто-нибудь из уважаемой публики, пояснить, как работает приведенный пример и почему. Я знаю, порядок инициализации объектов в Java (статиечсикии поля, статическии блоки, не-статическии поля, не-статическии блоки, конструктор верхнего класса в иерархии наследования), но в данном примере никак не могу разобраться.
Фишка в том, что при инициализации из супер класа вызывается метод наследника (вспоминаем про полиморфизм:)). Так как в Java не сущесвует перегрузки полей обявление переменной variable в класе B скрывает переменную супер класса. В методу происходит ее инициализация.
После завершения работы конструктора супер класа и до начала выполнения кода в консрукторе наследуемого класа происходит инициализация всех полей даного класа.
В этот момент переменной variable снова присваевается null.
Соответственно, без явного присваивания переменная будет иметь то значени которое ей присвоили в методе.
__________
Я с данным примером столкнулся в нашем проекте на прошлой работе и вынес из него для себя один урок. Плохая практика вызывать методы из конструктора класа.
После завершения работы конструктора супер класа и до начала выполнения кода в консрукторе наследуемого класа происходит инициализация всех полей даного класа.
В этот момент переменной variable снова присваевается null.
Соответственно, без явного присваивания переменная будет иметь то значени которое ей присвоили в методе.
__________
Я с данным примером столкнулся в нашем проекте на прошлой работе и вынес из него для себя один урок. Плохая практика вызывать методы из конструктора класа.
Что скажете о практике вообще не терять время на собеседование?
Это завуалированное собеседование, не больше. Шаблонный вопрос для отсеивания левых людей (сумма чисел от 1 до 99), тестовое задание (сделай патч), собственно собеседование (пиши нам, поговорим).
Нет никакого собеседования, и нет «пиши нам». Патч делает один из тысячи, и с ним уже нет смысла что-то обсуждать, он уже успешно работает над проектом.
Где же нет, когда «If you pass a trial test, we can further discuss and set up permanent job conditions: legal papers, social benefits, salary, preferred office location, etc.» где discuss — ссылка с mailto:? Вот это и есть собеседование.
can != must
Там всё написано в FAQ, можно ничего не обсуждать. Например, ожидания человека по деньгам определяются в рамках тестового задания, так как оно оплачивается.
Грубо говоря, если человек хочет служебный автомобиль, а не бесплатные обеды — на этом этапе такое можно обсуждать. Уже не обсуждается его способность работать.
Там всё написано в FAQ, можно ничего не обсуждать. Например, ожидания человека по деньгам определяются в рамках тестового задания, так как оно оплачивается.
Грубо говоря, если человек хочет служебный автомобиль, а не бесплатные обеды — на этом этапе такое можно обсуждать. Уже не обсуждается его способность работать.
Со столь малым количеством конкретной информации can превращается в must.
«Например, ожидания человека по деньгам определяются в рамках тестового задания,» — без обсуждения с человеком? Это как?
Давайте вспомним типичное собеседование: разговор о компании и проекте, тестовое задание, обсуждение его результатов, разговор о бенефитах. Чего именно у вас нет? На мой взгляд, все пункты присутствуют, просто растянуты по времени.
«Например, ожидания человека по деньгам определяются в рамках тестового задания,» — без обсуждения с человеком? Это как?
Давайте вспомним типичное собеседование: разговор о компании и проекте, тестовое задание, обсуждение его результатов, разговор о бенефитах. Чего именно у вас нет? На мой взгляд, все пункты присутствуют, просто растянуты по времени.
Прошу прощения, возможно я чмо не знаю некоторых вещей, но для меня вопрос «5 любимых рефакторингов» прозвучит примерно как «5 любимых замахов веником при подметании полов». То есть, ну они как бы все любимые, рефакторинги-то.
А так статья офигенская, спасибочки.
А так статья офигенская, спасибочки.
Почему в тексте постоянно встречается одиночная закрывающаяся скобка? Обычно в конце предложения. Это какая-то новая фишка русского языка?
Русский язык эволюционирует конечно не так быстро как английский — но каждое поколение он сильно меняется. Ничего плохого в этом нет :)
Я действительно не понял, что это за скобочки. Даже возвращался глазами по тексту в поисках открывающей — чтобы правильно понять, где основная мысль, а где — пояснение :( Видимо это таки новый вид смайлов! И, судя по моей карме, все уже давно в теме :))
Но всё же считаю, что если это действительно они, то автор всё-таки с этим переборщил.
Но всё же считаю, что если это действительно они, то автор всё-таки с этим переборщил.
Сначала по прочтении статьи начал хмуриться и злиться, но потом вспомнил как 6 лет назад проходил свое первое собеседование и даже улыбнулся. Думал что-нибудь посоветовать, но всему научитесь сами с опытом, юношеский максимализм немного пройдет (насколько я могу судить в свои четверть века), а всеобщая злоба на плохие компании, злой мир и бестолковых собеседующих уйдет.
Чему я истинно завидую — вашей энергии. 3.5 года работы на жестком аутсорсе у дяди почти убили мою внутреннюю мотивацию и энергию, теперь пестую ее по крупинкам в гораздо более солидном месте :) В целом, успехов!
Чему я истинно завидую — вашей энергии. 3.5 года работы на жестком аутсорсе у дяди почти убили мою внутреннюю мотивацию и энергию, теперь пестую ее по крупинкам в гораздо более солидном месте :) В целом, успехов!
А это нормально, что человек, собеседующийся на джуниора, рассказывает, как правильно его надо собеседовать? Не то чтобы я с чем-то в статье был несогласен, просто выглядит немного странно.
А это нормально, что человек, пользующийся какой-нибудь программой, рассказывает как этой программе следовало бы работать правильнее с его точки зрения? А ведь рассказывают, и разработчики их даже иногда слушают.
Скорее я хотел рассказать, как мне хотелось бы, чтобы меня собеседовали. Я написал свои мысли и хотел услышать мысли других в комментариях.
Примечательно, что все кто реpко отозвался о статье ничего более существенного и конструктивного чем «вы не были по другую сторону баррикад» сказать не смогли.
Никто не назвал хотя бы одну причину, что лично ему мешает придумать интересные вопросы для собеседования или предложить HR'ам давать кандидатам тестовое задание.
Примечательно, что все кто реpко отозвался о статье ничего более существенного и конструктивного чем «вы не были по другую сторону баррикад» сказать не смогли.
Никто не назвал хотя бы одну причину, что лично ему мешает придумать интересные вопросы для собеседования или предложить HR'ам давать кандидатам тестовое задание.
В больших компаниях все проще. Все знают, что там пересмотр зарплаты 2 раза в год. К тому же, крупные компании, как правило, готовы сразу платить неплохие деньги на junior позиции. По крайней мере туже средне рыночную ЗП там можно просить без зазрения совести. Просто поскольку крупная компания может себе позволить вложить в вас деньги авансом.
Что это за компании такие? Сколько знаю крупных компаний (что профильные софтверные, что непрофильные типа банков с крупными айти-отделами), там лишние 5к рублей надбавки получить практически не возможно. Ну, по кр мере честным путём, без вылизывания руководства и подсиживания. Формально да, пересмотр зарплаты есть. Для этого нужно заполнить унизительную форму самооценки. Типа что вы сделали полезного для компании за прошедший год. А по итогам тебе говорят, что либо то, что ты сделал, не полезно, либо ты ничего полезного не сделал. И не волнует никого, что полезного ты не делал потому, что на каждый чих нужно десяток подписей собрать.
Я когда-то работал в фирме, где было нас два человека. На покупку сертификата для подписывания приложений ББ ушло минут пять — оплатить с кредитки. Казалось бы. Но спустя пару лет я делал то же в крупной компании. Там эти несчастные десять баксов пол-года переводили. И так и пишешь в самооценке. Что вы сделали за пол-года? Ничего, потому что невозможно на девайс залить без сертификата. Вот видите, ничего не сделали, какой ещё пересмотр зарплаты.
Но это так, пример из жизни. Я к тому, что не верю я в крупные компании с регулярным пересмотром зарплаты.
Сколько знаю крупных компаний (что профильные софтверные, что непрофильные типа банков с крупными айти-отделами), там лишние 5к рублей надбавки получить практически не возможно.
Возможно вы с автором разные компании считаете большими? Ну а в банках вообще своя атмосфера.
Формально да, пересмотр зарплаты есть. Для этого нужно заполнить унизительную форму самооценки. Типа что вы сделали полезного для компании за прошедший год.
Что унизительного в том, чтобы ответить на вопрос, почему ваша работа теперь стоит дороже, нежели полгода тому?
Что унизительного в том, чтобы ответить на вопрос, почему ваша работа теперь стоит дороже, нежели полгода тому?
Наёмный работник в большой компании не делает ничего по своей воле, он часть бизнес-процессов. Поэтому его «хорошесть» для компании есть результат не столько его деятельности, сколько движения, в которое он вовлечён. Всё равно что бросить камень а потом спрашивать у него, зачем он полетел.
Не надо забывать о рынке труда. Если рынок переживает дефицит кадров, то цена разработчику выростает, даже если он делает то же самое, что и полгода назад.
-промахнулся-
Очень понравилось видение автора процесса собеседования, доводы и прочие мысли из статьи.
Вот чего я ещё не понимаю, так это когда на собеседованиях дают тест с вопросами например по Java,
где приведены ситуации, тонкостей языка, таких тонкостей, которых никогда в разработке и не встретишь, даже сложно написать такое, и вот тебе нужно сказать что же будет, например если писать
System.out.print(«This is» + 5 + 7 + "??? = " + 12);. Нет я понимаю это интересные тонкости языков, да, и для интереса нужно знать, но даже если ты такое напишешь у себя при разработке, ты сможешь увидеть за секунду что будет, и поправить как нужно, зачем мне знать на собеседовании что будет? Нет ну ладно, но когда ещё и судят по этому о знании языка, мне становится не понятна такая точка зрения. Такого рода задания можно встретить на тестах Oracle да, где ты именно хочешь получить сертификат что ты супер прошаренный в языке, но у нас тут собеседование и получение того что может кандидат, а не знает ли он странные тонкости языка.
По моему мнению, нужно спрашивать чем человек занимался, примеры проектов может, как он их реализовывал, что интересного и проблемного было, отсюда сразу видно что усвоил из этих проектов кандидат. Так же некоторые вопросы по резюме, о языках которые были написаны, знание ООП например, что очень полезно, возможно некоторые известные полезные паттерны, отсюда видно что человек сможет написать довольно гибкий код в будущем и понимает весь процесс разработки, и в каких ситуациях вообще это нужно. Так же неплохо поинтересоваться университетской если таково имеется подготовкой, имеется ввиду что проходил, отсюда видно что человек изучал, и например в дополнении спросить пару логических заданий, что бы увидеть и не требовать очень правильного ответа, увидеть как человек мыслит, как он приходит к решению, неплохо конечно и алгоритмическая небольшая подготовка, что бы понимать как работаю структуры данных как хеши, деревья, мэпы и когда что лучше применять. Так же можно привести пример ситуации из продакшина, и спросить как бы эту ситуацию попытался разрулить кандидат, тоже полезно и видно сразу как человек сможет при условиях реальной разработки мыслить.
Вот чего я ещё не понимаю, так это когда на собеседованиях дают тест с вопросами например по Java,
где приведены ситуации, тонкостей языка, таких тонкостей, которых никогда в разработке и не встретишь, даже сложно написать такое, и вот тебе нужно сказать что же будет, например если писать
System.out.print(«This is» + 5 + 7 + "??? = " + 12);. Нет я понимаю это интересные тонкости языков, да, и для интереса нужно знать, но даже если ты такое напишешь у себя при разработке, ты сможешь увидеть за секунду что будет, и поправить как нужно, зачем мне знать на собеседовании что будет? Нет ну ладно, но когда ещё и судят по этому о знании языка, мне становится не понятна такая точка зрения. Такого рода задания можно встретить на тестах Oracle да, где ты именно хочешь получить сертификат что ты супер прошаренный в языке, но у нас тут собеседование и получение того что может кандидат, а не знает ли он странные тонкости языка.
По моему мнению, нужно спрашивать чем человек занимался, примеры проектов может, как он их реализовывал, что интересного и проблемного было, отсюда сразу видно что усвоил из этих проектов кандидат. Так же некоторые вопросы по резюме, о языках которые были написаны, знание ООП например, что очень полезно, возможно некоторые известные полезные паттерны, отсюда видно что человек сможет написать довольно гибкий код в будущем и понимает весь процесс разработки, и в каких ситуациях вообще это нужно. Так же неплохо поинтересоваться университетской если таково имеется подготовкой, имеется ввиду что проходил, отсюда видно что человек изучал, и например в дополнении спросить пару логических заданий, что бы увидеть и не требовать очень правильного ответа, увидеть как человек мыслит, как он приходит к решению, неплохо конечно и алгоритмическая небольшая подготовка, что бы понимать как работаю структуры данных как хеши, деревья, мэпы и когда что лучше применять. Так же можно привести пример ситуации из продакшина, и спросить как бы эту ситуацию попытался разрулить кандидат, тоже полезно и видно сразу как человек сможет при условиях реальной разработки мыслить.
Мы пришли к простой схеме:
1) Стандартное для всех собеседование по телефону длительностью час, из них первые полчаса — написание кода в расшаренном веб-блокноте. Тестовые задания простые, типа FizzBuzz или даже проще. Удивительно, но 50% претендентов на должность синьора отсеиваются на этом этапе. Вторые полчаса — теория (ООП, дизайн, алгоритмы). Индусы на этом этапе ведут себя очень смешно — ответы тарабанят без запинки, но попытка уточнить, почему именно так вызывает зависание. Также прошу обычно набросать простенький дизайн для некой стандартной задачи — ну, например, набросать дизайн очень простого GUI фреймворка.
2) Следующий этап — тестовое задание. По времени — часа на 2-4.
3) И только если первые два этапа пройдены, зовем на личное собеседование. Тут уже говорим про прошлые проекты, оцениваем личность и так далее.
1) Стандартное для всех собеседование по телефону длительностью час, из них первые полчаса — написание кода в расшаренном веб-блокноте. Тестовые задания простые, типа FizzBuzz или даже проще. Удивительно, но 50% претендентов на должность синьора отсеиваются на этом этапе. Вторые полчаса — теория (ООП, дизайн, алгоритмы). Индусы на этом этапе ведут себя очень смешно — ответы тарабанят без запинки, но попытка уточнить, почему именно так вызывает зависание. Также прошу обычно набросать простенький дизайн для некой стандартной задачи — ну, например, набросать дизайн очень простого GUI фреймворка.
2) Следующий этап — тестовое задание. По времени — часа на 2-4.
3) И только если первые два этапа пройдены, зовем на личное собеседование. Тут уже говорим про прошлые проекты, оцениваем личность и так далее.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Собеседование на junior позицию. Антипатерны собеседующих