Антипаттерны для поиска соискателей

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


    И за это время у меня накопилось огромное количество смешных и грустных историй взаимодействия с рекрутерами с обеих сторон, которые я решил систематизировать в общий сборник антипаттернов. Поехали!


    Оформление вакансии


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


    Для начала, никогда не указывайте зарплату — соискатель должен мечтать работать в вашем стартапе ООО "Горим", и для него не должно быть важно, сколько денег ему заплатят. И вообще, зачем вам меркантильные сотрудники?


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


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


    Так же можно написать про ответственность, лидерские качества, и про то, что разработчик сам должен всё понимать и ставить себе задачи. В конце концов, у вас уже есть видение вашего продукта — осталось только его накодить, с этим и макака справится.


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


    Если вы не знаете ещё, какой стек будет использоваться в продукте, спросите у друзей или почитайте статьи в интернете — нужно, чтобы вы сразу определили, какого разработчика ищете. А в технологиях вы и сами разберётесь — легко. Например, вы можете понять, что чёткие пацаны пишут на go и при этом используют NoSQL — значит, вам точно нужен go разработчик со знанием NoSQL на ваш сайт по продаже шапок ушанок с полутора посетителями в день.


    Обязательно напишите, что скоро вы переезжаете в США или куда-нибудь ещё, куда обычно хотят программисты. Это безопасно. "Скоро" — это понятие растяжимое, обычно означает "как только мы внезапно получим кучу денег и будем купаться в них как Скрудж Макдак". Ну и что, что это в лучшем случае в перспективе пары лет. Может же случиться. Везёт же некоторым! Так что ваш стартап — убийца Фейсбука и Гугла одновременно — обязательно взлетит.


    Ни в коем случае не раскрывайте, над чем собственно придётся работать. У вас наверняка бесценная идея, и её может украсть коварный разработчик — молчите и загадочно намекайте на хайлоад, блокчейн, инстаграм, нейронные сети и SaaS.


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


    Обязательно сделайте необходимым добавление сопроводительного письма, где разработчик напишет, почему хочет идти именно к вам. Он же идёт не просто деньги за свою работу получать, а к Вам! Пускай обоснует, хотя бы символов на 500. Тех, кто пишет "хочу работать у вас, вроде вакансия мне подходит" можно сразу отфильтровывать.


    Кроме сопроводительного письма так же неплохо сделать анкету с 20 или больше вопросами — чем больше вы знаете про соискателя, тем лучше! Не стесняйтесь давать эту анкету соискателю несколько раз подряд — расхождения в ответах могут вам о многом сказать.


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


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


    Не забудьте написать в описании вакансии, что у вас есть печеньки. А ещё Agile и Scrum. Это так оригинально!


    Автоматическое письмо откликнувшемуся


    Ура, вакансия готова! Что же делать дальше? В первую очередь нужно написать ответное письмо, которое приходит от автомата заинтересованным соискателям. Лучше всего указать там свой номер телефона и написать, чтобы соискатель звонил вам, если ему вдруг всё ещё интересна вакансия, на которую он откликнулся пять минут назад.


    Поиск соискателей


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


    • Не совпадает зарплатная вилка в два раза? Не беда — вдруг он завышает требования или очень захочет работать в вашем стартапе?
    • Хочет на ведущего разработчика, а у вас вакансия Джуниора? Ну так пускай губу закатит.
    • Хочет заниматься бэкендом, а у вас фронтенд? Ну так выше же говорили, что разработчик должен быть только фуллстыком (или как оно там. Короче, должен уметь Windows переставить и кофемашину починить).

    В общем, у вас и так мало времени, а ваш KPI измеряется количеством соискателей, которые вы найдёте. Шлите всех, и пускай там уже высоколобые разработчики разбираются, подойдёт ли Javascript разработчик под Java, или 1C разработчик под C#.


    Работа с соискателем


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


    Отдельно замечу, что разработчики часто в резюме прикрепляют кучу всякого мусора — профили на каких-то сайтах, какой-то код… Нужно всё это отсечь, чтобы технарям ушла только нужная информация. ФИО и список мест работы — вот необходимый и достаточный набор данных.


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


    Тестовые задания


    Помните про тестовые задания! Надо же как-то людей фильтровать. Принято давать три категории тестовых заданий:


    1. Типовое задание, скачанное с интернета. Не беда если оно скучное — соискатель к вам не развлекаться идёт. Не имеет значения, что решение уже опубликовано на сотне ресурсов — наверняка же искать не станет. А на случай если станет — добавьте в тестовое задание таймер — все говорят мол “креатора дедлайн возбуждает”.
    2. Какое-нибудь сложное задание, чтобы соискатель показал себя во всей красе. Рассчитывайте, чтобы он потратил на него дня 2-3. В конце концов, он хочет у вас работать или нет?
    3. Последняя категория, которая в последнее время теряет популярность — взять некую текущую задачу вашей компании и попросить соискателя её сделать. Так сказать, протестировать в условиях приближенных к боевым. А на самом деле, можно использовать такие задания как бесплатный аутсорс. Круто же! Странно, что в последнее время вижу такие тестовые задания всё реже.

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


    Личные собеседования


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


    • Вы же знаете, что в гости прилично опаздывать на 15 минут? Ну и здесь так же. Начинайте собеседование через 15-30 минут после назначенного срока, это даст кандидату лучше подготовиться и успокоиться.
    • Если собеседование подразумевает подключение дополнительных людей, начинайте их искать в момент наступления собеседования. Не надо людей отвлекать заранее.
    • Для собеседования нужно хотя бы 4-5 человек, кроме самого соискателя. Им же потом вместе работать, так что пускай его оценивает вся команда, на первом же собеседовании. Они же просто сидят на стульях весь рабочий день — так пускай потратят его с пользой. Если вы привлекаете 5 человек и проводите хотя бы 3 полуторачасовых собеседования в неделю, то за неделю они проводят с пользой уже 3х5х1.5=22 часа, то есть почти три человеко-дня.
    • Не стоит тратить время на то, чтобы заранее вспомнить или приготовить резюме кандидата. В первые полчаса все и так вспомнят, кто он, на какую позицию пришёл, и он расскажет своё резюме ещё раз. Чтобы замаскировать то, что вы потеряли его резюме, можно попросить рассказать его резюме своими словами. Это солидно и многое покажет, в том числе кандидату.
    • Плох тот программист, который не готов писать код на бумажке. Пускай покажет, что может не только писать код в среде, которая всё за него делает. Причём писать обязательно нужно рабочий код на вашем конкретном языке, а не какие-то там Блок схемы (ну причём тут Александр?).
    • Наверняка соискатель пришёл к вам с ощущением, что он крутой и достоин многого. Даже если так, вам явно не хочется за него переплачивать — так что найдите в его резюме что-то, чем он занимался десять лет назад, и задайте вопросов посложнее. Пускай поймёт, что у вас он может только унитазы чистить.
    • Собеседований обязательно должно быть несколько. Например, первое происходит с HR, второе с разработчиком, третье с лидом, четвёртое со всей командой, и пятое — с генеральным директором. Никуда не торопитесь, соискатель — он не волк, в лес не убежит.
    • Делайте длительные паузы между каждым этапом собеседования, лучше не менее недели. Это даст возможность тщательно оценить кандидата и покажет, что у вас серьёзная компания, а не какая-то шарашка.
    • Если нужно перенести время собеседования, то сделайте это за полчаса до прихода кандидата. Ну нельзя же учесть заранее все возможные факторы.
    • Если кандидат сказал что-то, что вы не ожидали, то можно дружно посмеяться. Это очень разряжает атмосферу!
    • Если собеседование удалённое, то попросите соискателя включить камеру, а сами не включайте. Это ведь вы на него смотрите, а не он на вас.
    • Всякая роскошь вроде гарнитуры совсем не обязательна для собеседования. Эхо, шумы офиса, переговоры вокруг — это нормальная рабочая обстановка.
    • Если вам потребовалось во время собеседования выйти — смело делайте это. Можно оставить кандидату задачку и уйти на час-два. Пускай неспешно её решает и попьёт растворимый кофе из стаканчика, который ему любезно предложили.
    • Обязательно первым делом спросите у кандидата, что он знает о вашей компании. Если он не производил изыскания с получением информации о всех её продуктах и людях — значит, он в вас не заинтересован! В таком случае, не рассказывайте ничего сами.
    • Чуть не забыл. На любом собеседовании обязательно нужно спросить про паттерны. И попросить реализовать синглтон. Ну или хотя бы попросить написать какую-нибудь рекурсию или что-нибудь про числа Фибоначчи. Все серьёзные компании это спрашивают. Наверное, нужно было поставить это первым пунктом.

    Обязательно запросите рекомендации кандидата на текущем месте работы от его руководства. А то мало ли что.


    Если вам понравился кандидат, и вы во всём сошлись, то не забудьте поторговаться. У вас ведь в описании вакансии указано “до ххх”. Так что вы никого не обманете, если предложите “ххх:2”. Люди — это как арбузы на рынке, только люди. Принципы торговли те же. Если после вашего предложения соискатель пропал — ну, значит, он просто не мотивирован с вами работать и сам виноват.


    А если кандидат не соглашается принять ваше предложение, то расскажите, что ситуация на рынке сложная, работу найти не так просто, и у вас уже есть другие согласившиеся на это место кандидаты — пусть испугается и примет ваши условия!


    Если кандидат всё же согласился, то предлагайте выйти на работу завтра, а лучше — сегодня. Даже если у него указано текущее место работы. Зачем зря терять время?


    Лайфхак: в письме кандидату можно задать кучу вопросов и даже попросить рекомендовать кого-нибудь, и если в конце написать "Заранее спасибо", то можно уже не тратить время на ответ!


    Ещё одна общая рекомендация — помните: вы — машина, вы — комбайн по переработке заявок в людей! Ко всем нужно применять один и тот же подход, чтобы соискатель понимал, что он — потенциальный винтик огромной машины, который должен знать своё место в ней. Веерные рассылки, обмен базами соискателей, беспорядочные связи в linkedin — всё это годится для поиска людей!


    Ну и последнее. Если вам не понравился соискатель, то просто забейте на переписку. Зачем терять своё время на человека, который вам не подходит? К тому же, отказом вы можете ещё и обидеть человека! И не рассказывайте ему, что конкретно ему нужно подтянуть — если он не подошёл вам сегодня, значит не подойдёт никогда.


    Следуйте этим советам, и вы обязательно не найдёте себе нужного разработчика!




    Не хотелось бы, чтобы данный пост был принят за какое-то нытьё. Наоборот — мне хочется думать, что он дойдёт до многих рекрутеров, и они, заметив за собой некоторые пункты, будут над ними работать. Обе стороны (разработчики и рекрутеры) заинтересованы в том, чтобы работа искалась быстро и качественно.


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


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


    Указывайте в комментариях свои антипаттерны — давайте дополним список!


    UPD. Дополнено антипаттернами от kyb27, White_Scorpion, samuelsh, Idot, yefrem, michael_vostrikov, santanico.

    Only registered users can participate in poll. Log in, please.

    Со сколькими из указанных антипаттернов вы уже сталкивались в поиске работы?

    • 4.8%ни с одним35
    • 26.9%1-3193
    • 29%4-7208
    • 42.1%больше 8302
    Support the author
    Share post

    Similar posts

    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 483

      –3
      Недавно соискатель приходил. Рассказывал как он увлечен блокчейном, биг датой и другими модными технологиями. Рассказывал про самостоятельную реализацию библиотеки для MapReduce, про всякие интересные домашние проекты. З/п хотел под стать увлечениям.
      А потом я спросил чем абстрактный класс отличается от интерфейса. И стало неинтересно, скучно, и дальше как-то не заладилось.
        +17
        чем абстрактный класс отличается от интерфейса

        а в каком языке?

          –8

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

            +12

            Они будут отличаться даже для Java 7 и 8. Если уж говорить не про "ну, примерно вот так они отличаются", а про чёткий полный ответ.

              +13

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


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


              Что я забыл?

                +3
                > не являющиеся полями
                А статическое константное поле? Или это не считается полем?
                  0

                  Статический член — он почти глобальный, просто привязан к классу. Поэтому когда говорят о члене класса, обычно подразумевают именно нестатические члены. Да, статические константные поля в Java вроде как допустимы, как и в C++.

                  +3

                  Сказали лишнего и не раскрыли исключений (про java 8 и С++). Ну и вы, вероятно, не знаете все языки в мире. Я, например, не могу точно сказать, что исключение только java 8. А в С++ вообще нет интерфейсов. Ну и так далее. Лучше уточнять, о каком языке идёт речь сразу.

                    –3

                    В С++ обычно интерфейсом называют абстрактный класс, все члены которого являются открытыми чисто виртуальными (=абстрактными) методами.

                      +9

                      Ну вот видите, мой первый вопрос


                      а в каком языке?

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

                        +5
                        А ведь есть же еще языки в которых нет классов и/или интерфейсов, мне кажется такие вопросы задаются чтобы показать какой умный интервьюер вас собеседует, чтобы будущий работник понимал как ему будет «здорово» работать с таким коллегой/начальником.
                          +1
                          Мне кажется, что одна из целей собеседования в этом и состоит — убедиться, что работодатель и работник разговаривают «на одном языке». Так что такой открытый вопрос, или даже точнее тема для обсуждения, на собеседовании — это нормально, при условии, что ответ оценивает специалист, а не HR по бумажке.
                          +2

                          pure virtual method может иметь реализацию. просто он обязательно требует перегрузки.

                            0

                            А можно поподробее? pure virtual — это же


                            virtual void f() = 0;

                            Давненько не писал на С++, но вроде она не может иметь реализацию в этом же классе.

                              0
                              Если очень захотеть, то можно. Например, если охота написать базовый класс, который нельзя создавать (и в котором нету или очень мало виртуальных методов) то можно например создать чисто виртуальный деструктор + его реализацию в этом классе. То есть, с одной стороны, получается, что класс сам по себе создать нельзя, а с другой — это вполне целостный класс, который отвечает за объекты, которые в нем лежат (действительно ли это где-нибудь используется в продакшене, это уже другой вопрос)
                                +2

                                Действительно.


                                Код
                                #include <iostream>
                                class c {
                                    public: virtual void f() = 0;
                                };
                                
                                void c::f() {
                                    std::cout<<"c";
                                }
                                
                                class d: public c {
                                public:
                                    void f() {
                                        c::f();
                                        std::cout<<"d";
                                    }
                                };
                                
                                int main() {
                                    d x;
                                    x.f();
                                    return 0;
                                }
                                

                                Вывод: cd


                                Не перестану удивляться плюсам %)

                          0
                          Вроде в Kotlin в интерфейсе тоже можно описать реализацию методов, если память не подводит.
                            +1
                            А в С++ вообще нет интерфейсов

                            В C++ Builder, интерфейсы, кстати, есть.

                              –1
                              Instead of using the class keyword, interfaces are declared using interface. interface is a macro that maps to the class keyword. It is not necessary, but makes it clearer that the class is intended to act as an interface.
                              http://docwiki.embarcadero.com/RADStudio/Berlin/en/Inheritance_and_Interfaces

                              Я так понимаю, никто не запрещает вам в этом "интерфейсе" делать всё то, чего делать в нём не надо.


                              И даже больше:


                              #define __interface struct


                              http://docwiki.embarcadero.com/RADStudio/Tokyo/en/Delphi_Compatibility_Macros#interface

                              И это ещё раз подтверждает мой тезис — важен контекст(конкретный язык). Потому что "программист на С++Builder"(а встречаются и такие) скажет, что ничем они не отличаются.

                                +1

                                Разница в реализации компилятором. Для MSVC, GCC интерфейсов, понятное дело, не существует.


                                В Delphi же есть отдельная сущность — interface. Чтобы на C++ Builder можно было писать код с тем же функционалом, что и на Delphi, в C++ Builder абстрактные классы, удовлетворяющие признакам "интерфейса", обрабратываются специальным образом.

                                  –1

                                  Где пруфы, Билли?
                                  Я свои пруфы привёл — если судить по офф докам, то ничем они не отличаются, и компилятор тут вообще не при чём.

                                    0
                                    Интерфейс в Java, Delphi и С++Builder — это COM-interface. То есть под капотом — там всякие QueryInterface, AddRef, Release, своя собственная (стандартная для COM) vTable и так далее.

                                    А то, что C++ Buider опознает интерфейсы по INTERFACE_UUID — это детали реализации. В любом случае для Delphi и С++Builder интерфейс — это класс со второй таблицей виртуальных методов, выполненной в стандарте COM. И минимум 3 метода, неявно добавленных в класс — QueryInterface, AddRef, Release,

                                    Собственно прочитать об этом вы можете в любом учебнике дельфи, например тут
                                      0

                                      В Java? o_O
                                      В любом случае — что вы всем этим мне хотите сказать? То что эти "интерфейсы" чем-то там отличаются — вот это деталь реализации. Или вы хотите мне сказать, что в C++ Билдере нельзя описать не-абстрактные методы и поля-данные в структуре?
                                      С помощью этих ваших "интерфейсов" вы можете накостылить взаимодейтствие с делфи. Ну и что? Возможность наследовать реализацию не пропала.


                                      оффтоп

                                      Какое счастье, что я ушёл от этого. Делфи, билдер, бррр. Ура.“

                                        –4
                                        Угу. Насколько я знаю, в Java каждый класс является COM-интерфейсом.

                                        А сказать что простую вещь. Не лезьте в бутылку при виде #define __interface struct. COM-интерфейсы опознаются по INTERFACE_UUID. И к обычным языковым интерфейсам имеют небольшое отношение.

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

                                        Наследовать реализацию вы можете у класса. У интерфейса нету реализации. Интерфейс, в понимании Delphi — это COM-interface, то есть таблица методов. Канонически оно записывается на IDL. В билдере — это будет специфческая структура с GUID.

                                        А класс — это реализация интерфейса.

                                        Я понимаю, это сложно. Особенно в варианте билдера.

                                        Но это намного проще, чем работать с COM-интерфейсасми из чистого Си.
                                          –1

                                          Вы мне что доказать-то хотите?


                                          к обычным языковым интерфейсам имеют небольшое отношение.

                                          бинго.

                                            +2
                                            в Java каждый класс является COM-интерфейсом.
                                            Первый раз такое слышу. Технология от MS в Java? Вы точно ни с чем не путаете?
                                              –6
                                              Вы думаете, что Микрософт мог устоять от соблазна впихнуть свои технологии в написанную им JVM? Вы слишком хорошо думаете о Микрософте. Они впихивают свои технологи куда угодно и как угодно.

                                              Но пруфа я вам быстро не найду. Сам где-то читал лет 15-20 назад.
                                                +3

                                                Про эту херню (MSJVM) я тоже слышу впервые от вас. Не надо говорить "в Java", если это сделано в какой-то убогой древней реализации, которая не поддерживается уже больше 15 лет.

                                                  –4
                                                  Судя по вики — 2 года назад ещё была вполне жива.

                                                  По аналогии: атомные ледоколы и подводные лодки — в России. Хотя лишь в нескольких поселках городского типа (вроде Гаджиево) вы можете их увидеть воочию.
                                                    +3

                                                    Cудя по вики,


                                                    Microsoft settled the lawsuit with Sun and discontinued its Java implementation.

                                                    Это не называется "2 года назад была жива". Кроме того, это какая-то сторонняя реализация, не имеющая ничего общего с миром Java. Кончайте нести чушь, в общем. А то я могу тоже написать свою реализацию JVM и в ней навертеть всякого, и потом таким как вы впаривать — в Java есть то и это.

                                                      –7
                                                      Ну тогда впаривайте дальше, что в России нету атомных ледоколов и космических ракет лишь потому, что ни в одном крупном городе вы их не увидите. :-)

                                                      Вы — не микрософт. И ваша личная реализация JVM никому интересна не будет.

                                                      Судя по вики "Microsoft began bundling a standalone JVM in the Minecraft video game in September 2015", так что 2 года назад была вполне жива.

                                                      В любом случае, мне неинтересен «мир Java». COM-интерфейсы вроде ни в один язык программирования не вошли в качестве стандарта. Они всегда в реализации. И только — под windows. Что настолько противорчеит идеями Java, что ни о каком «мире Java» речи не идет.

                                                      COM-интерфейсы — это «мир Windows». И именно об реализациях COM-интерфейсов в языках программирования я вам и писал.
                                                        +6
                                                        Судя по вики "Microsoft began bundling a standalone JVM in the Minecraft video game in September 2015", так что 2 года назад была вполне жива.
                                                        А чукча читать умеет, нет? Вы бы окончание этой фразы прочитали, что ли: The JVM included in Minecraft is based on an official Oracle distribution

                                                        Нет никакой Microsoft'овской JVM уже давно. Sun заявил что именно из-за того, что Microsoft сдлела классы Java COM-обьектами его поделие нарушает лицензию на Java, называться Java не может и должно быть отозвано. Microsoft согласился.
                                                          0
                                                          Готов согласится. я действительно очень далек от явы и мог и перепутать, Вполне возможно, что именно это и было причиной закрытия MSJVM,
                                                          +1

                                                          Вы влезли со своими СОМ-интерфейсами абсолютно не в тему. При этом заявили, что они используются в Java. Если вам не интересен мир Java — не надо делать заявлений о нём на основании какой-то странной реализации JVM. JVM — это не Java. К Java ваши ненаглядные СОМ-интерфейсы отношения не имеют. К интерфейсам, обсуждаемым в треде — тоже.

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

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

                                                              –5
                                                              Вы утверждаете, что того, что вы не видели вживую — не существует. Так вот, ни атомных ледоколов, ни космических ракет — вы не видели вживую. По вашей логике их нет?

                                                              И ещё раз повторю, что COM-интерфейс — это классический пример интерфейса. Причем независимый от языка программирования.
                                                                +1

                                                                Не совсем так. В той же Delphi интерфейсы являются специальными типами данных с нетривиальной реализацией на стороне компилятора. И эта реализация COM-интерфейсов очень сильно привязана к языку.

                                                                  –1
                                                                  Давайте не путать протокол и его реализацию. Интерфейсы в дельфи — это классы со втором таблицей виртуальных методов.
                                                                  Реализация — разная, а протокол один В этом и есть достоинство протоколов, в том числе и COM-интерфейсов.
                                                                  –1

                                                                  Я такого не утверждал. Подмена понятий. См. мой комментарий про ракеты.


                                                                  Мне плевать на ваш СОМ, за державуджаву обидно.

                                                          0

                                                          Sun в своё время запретило чужие jvm из-за таких вот казусов...

                                                            +2
                                                            Sun никогда не запрещал «чужие» JVM. IBM J9, JRockit — живут и здравствуют (последнее, кстати, теперь стало немного напоминать шизофрению, так как сейчас её продаёт Oracle).

                                                            Что Sun запретил — так это вот как раз то, про что тут говорил Jef239: классический EEE — «зачем для этого городить новую технологию, если есть собственная?» (держа мысль «в скобках» — не лучше ли послать всех, у кого «своей собственной технологии» в жопу и занять весь рынок?)

                                                            Договор у Sun (теперь у Oracle) всегда был следующим: добавлять какие-то фичи — имеет полное право. Менять (и, уж тем более, удалять)? Ни в коем разе…
                                                              +1

                                                              кхм… вы правы — не совсем точно выразился. Запретила sun не реализации jvm вообще, а различные кастомы, не соответвующие спекам.

                                                              –3
                                                              Dalvik запрещен? Теперь буду знать, что у меня в мобильнике — запрещенный софт. :-)
                                                                +2
                                                                Фишка в том, что Dalvik — не JVM.
                                                                  +1
                                                                  Скорее всего у вас в телефоне ART, а не Dalvik — и да, это не JVM, как вам уже сказали. И да — Oracle очень старался доказать, что это — запрещённый софт, но… не смог. Потому что в отличие от Microsoft при разработке Google всё делал независимо и никаких договоров с Sun'ом не заключал…

                                                                  Был бы договор — скорее всего произошло бы то же самое, что и с MS JVM…
                                                                    +1
                                                                    ART впервые появился в Android 4.4,, а у меня — Андроид 1.5 (!!!), зато с QWERTY.

                                                                    Гик-порно для некрофилов
                                                                    image


                                                                    Хорошо, это не «виртуальная машина Java» (JVM), это «виртуальная машина, выполняющая код на языке JAVA» (VM for java). Разница — для истинных эстетов, к которым я не отношусь. :-)

                                                                    Как я понимаю, отличия в том, что наплевали на стандарт Java байткода и сделали свой байткод. Ну и транслятор в него.

                                                                    А называть ли это JVM — вопрос юридических споров между google и sun. В 2013 году на хабре ещё вполне называли dalvik JVM. Не говоря у же о других сайтах.
                                                                      +3
                                                                      Хорошо, это не «виртуальная машина Java» (JVM), это «виртуальная машина, выполняющая код на языке JAVA»

                                                                      Нет. Это даже не «виртуальная машина, выполняющая код на языке JAVA». Это «виртуальная машина, выполняющая какой-то свой собственный байт-код в каком-то своём собственном окружении». А в андроидовом SDK есть компилятор, который умеет компилировать программы на языке Java в этот байт-код. Поэтому разница не в трактовке, а довольно принципиальная.
                                                                        –1
                                                                        Вы хоть одну виртуальную машину писали или правили? :-)))

                                                                        Байт-код виртуальной машины, ровно так же, как и код реальной машины — языконезависим в очень широких пределах. Сколько там языков умеет исполняется стандартным байткодом JVM? про пяток я точно слышал. И это не компиляция в java, это компиляция именно в стандартный байт-код.

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

                                                                        Так что это именно VM, предназначенная для исполнения кода на языке JAVA. Просто исполняющая байт-код своего стандарта.

                                                                        P.S. я соавтор нескольких FORTH-систем, а в форте — нету стандартного бйаткода. каждая реализация — делает его самостоятельно.
                                                                          +2
                                                                          Сколько там языков умеет исполняется стандартным байткодом JVM? про пяток я точно слышал.

                                                                          Вы ошибаетесь :) Правильный ответ — ноль. Байт-код никакие языки не поддерживает, и не исполняет. Это, по сути, машинный язык абстрактной ЭВМ, ну или точнее, язык ассемблера (в каком-то бинарном представлении). Язык ассемблера ведь не умеет исполнять С++? Вот и байт-код ничего про Java не знает.
                                                                          С другой стороны, Java может и частично транслироваться в нативные инструкции процессора.

                                                                          Неа, не может. По крайней мере, такое не реализовано ни в одном из известных компиляторов Java. В нативные транслируется только байт-код, JIT-компилятором виртуальной машины. Если он есть.

                                                                          P.S. я соавтор нескольких FORTH-систем, а в форте — нету стандартного бйаткода. каждая реализация — делает его самостоятельно.

                                                                          Я не буду с вами спорить про реализацию FORTH-систем, чесслово. Но я точно вижу, что про реализацию JVM вы не в курсе ;) Не нужно их путать. В FORTH-системах язык и исполняющая среда, насколько я помню — одно целое. Верно? В JVM/.NET/Dalvik исполняющая среда не связана с языками программирования вообще. Это просто некий абстрактный компьютер, который умеет выполнять набор команд какого-то низкоуровневого языка, будь-то байт-код JVM, MSIL для дотнета или байт-код Далвика. Спецификация каждой машины определяет этот самый набор команд, допустимые типы данных и т.д. В ней нет ни джавы, ни сишарпа.
                                                                          А всё остальное, на чём пишутся программы живыми человеками, это уже отдельная от машины штука, компилятор с высокоуровневого языка в набор команд виртуальной машины.
                                                                          Вот Dalvik — это другая виртуальная, с другим набором команд, с другой спецификацией, поэтому она не имеет ничего общего с JVM. Ну да, для неё тоже написан компилятор с языка Java. В принципе, вы можете, как и упоминали, сделать компилятор с языка Java напрямую в x86. Это технически возможно, юридически не запрещено, на практике, наверное, будет невостребовано, но just for fun почему бы и нет.
                                                                            –1
                                                                            В нативные транслируется только байт-код, JIT-компилятором виртуальной машины.

                                                                            Тогда дивитесь на Jazelle. Между прочим, использовалось в большинстве старых мобильников.

                                                                            В FORTH-системах язык и исполняющая среда, насколько я помню — одно целое.

                                                                            Не всегда. Как пример — игрушка Ну-погоди из моего детства. Там только исполняющая среда форта.

                                                                            В JVM/.NET/Dalvik исполняющая среда не связана с языками программирования вообщe

                                                                            Не понимаю, о чем вы спорите, я вам ровно это и написал.

                                                                            Ну да, для неё тоже написан компилятор с языка Java.

                                                                            Насколько я знаю, вы ошибаетесь. Трансляция в Dalvik идет со стандартного байткода. Если отвлечься от тонкостей, "Dalvik Virtual Machine способна переводить байт-коды Java в коды своего собственного формата и также исполнять их в своей виртуальной среде. "
                                                                              +1
                                                                              Тогда дивитесь на Jazelle. Между прочим, использовалось в большинстве старых мобильников.

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

                                                                              Нет, Dalvik байт-код JVM не понимает. Просто в SDK есть кросс-компилятор.
                                                                              Как пример — игрушка Ну-погоди из моего детства. Там только исполняющая среда форта.

                                                                              Хм. Интересно. А где про это можно почитать?
                                                                                0
                                                                                Нет, Dalvik байт-код JVM не понимает. Просто в SDK есть кросс-компилятор.

                                                                                Пруф я вам дал. И не вижу ничего нереального в JIT-компиляции. Скорее всего так и было раньше, а потом — решили, что удобней компилировать все сразу. Вот вам ещё цитата "Сейчас Android-код выполняется в Java-машине, созданной Google специально для мобильных устройств, при этом он «на ходу» преобразуется в аппаратный (Just-In-Time Compilation)"

                                                                                Насчет ну-погоди — наверное у Ноздрунова нужно спрашивать. я фортом 30 лет назад занимался, что слышал — то и рассказываю.

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

                                                                                Самый простой вариант такой. В словарную статью форта добавляем поле — счетчик использования. После компиляции программы вначаеле обнуляем все счетчики. Потом рекурсивно обходим использованные все слова, начиная с «main», и увеличиваем счетчик при каждом использовании. В этот момент у нас есть словарь (то есть программа на форте), где помечено, что использовано, а что нет. Далее просто создаем другой словарь, где есть только использованные элементы.

                                                                                Ассемблерное ядро форта — это 3 килобайта кода. Все остальное — на самом форте. Так что сократить 14 килобайт полной форт-системы с редактором и компилятором в 6-7 килобайт приложения — не так сложно.

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

                                                                                Можно ещё и выкинуть имена из словаря и оставить только код. Это тоже не сложно.

                                                                                P.S. Для понимания. Слово форта — это процедура + её имя + поле для линковки слов в список.
                                                                                Словарь — это связный список слов, то есть набор программ. Выбор нужной программы — это набор её главного слова (аналога main).
                                                                            0
                                                                            А если запретить часть языковых возможностей — то можно вообще получить исполняемый модуль в нативных инструкциях процессора.
                                                                            Если «запретить часть языковых возможностей» — то это будет уже не Java. В частности в Java есть такая штука, как ClassLoader, который позволяет вам, ну, например, генерировать классы «на лету» и исполнять их (причём это не теоретическая возможность, есть библиотеки, которые это реально используют, в частности библиотеки работы с регулярными выражениями это делают).

                                                                            Dalvik и Art ничего этого не умеют и потому JVM не является. На них нельзя запускать произвольные программы на Java — только ограниченное подмножество.

                                                                            С тем же успехом можно говорить, что какой-нибудь Microsoft C 3.0 — это компилятор C++17. Ну да, часть фич не реализована — ну так и что теперь?

                                                                            Так что это именно VM, предназначенная для исполнения кода на языке JAVA. Просто исполняющая байт-код своего стандарта.
                                                                            Так не бывает. Бывает VM исполняющая код на языке Java, а бывает — исполняющая байт-код своего стандарта. Но если ваша VM не умеет исполнять байт-код Java, то это — не JVM.
                                                                              0
                                                                              Если «запретить часть языковых возможностей» — то это будет уже не Java

                                                                              Если вам отрезать палец — это будете вы или уже не вы? А если ногу? Сколько нужно вам отрезать, чтобы это были уже не вы? :-)))

                                                                              Диалект языка — это не отдельный язык. Например полный паскаль — огромная редкость. Самый распространенный диалект паскаля — не имеет пары операций (get и put с записями на файлах). И тем не менее — все его зовут паскалем.

                                                                              На них нельзя запускать произвольные программы на Java

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

                                                                              Так что возвращаемся к примеру с пальцем. :-)

                                                                              Бывает VM исполняющая код на языке Java,

                                                                              Не бывает. JVM исполняет байт-код и достаточно независим от языка, с которого этот байт-код компилился. Java — это не BASIC, исполнения исходного кода в режиме интерпретации каждой строки не будет.

                                                                              Это некоторая условность, что если байт-код как у Sun — так это JMV, а если нет — это VM for Java (VMJ). Тут важнее юридический смысл — то есть как обойти лицензионные ограничения sun. И вот юридически — да, это не JVM, это VMJ.
                                                                              +2
                                                                              Сколько там языков умеет исполняется стандартным байткодом JVM? про пяток я точно слышал.
                                                                              Вы не в ту сторону импликацию поставили. Вопрос не в том сколько языков может быть всунуто в байткод Java, а в том, сколько байткодов должна принимать JVM.

                                                                              Ответ: как минимум один — стандартный Java-байткод должен приниматься, так как без этого вы java.lang.ClassLoader не реализуете. И вот ровно-таки этого, обязательного требования ни Dalvik, ни Art «не умеют».
                                                                                0
                                                                                Ответ: как минимум один — стандартный Java-байткод должен приниматься, так как без этого вы java.lang.ClassLoader не реализуете.

                                                                                Но разве кто-то требует, чтобы JVM была монолитной? Без разделяемых библиотек, без вызова другого софта…

                                                                                Не вижу проблемы в реализации java.lang.ClassLoader сделать компиляцию в свою VM. Или сделать её JIT, то есть в ходе исполнения.
                                                                                И вот ровно-таки этого, обязательного требования ни Dalvik, ни Art «не умеют».

                                                                                Пруф дайте, пожалуйста. Потому что я лично вижу, что на андроид этот класс есть. Кроме того, есть dalvik.system.DexClassLoader — наследник от java.lang.ClassLoader
                                                                –5
                                                                На самом деле — вполне нормальное решение для написания собственной JVM, Все равно отладчику надо уметь обозревать классы и их методы и члены. Так зачем для этого городить новую технологию, если есть собственная? Тем более что язык не патентуется, а вот технология связи машины с отладчиком может быть и запатентована.

                                                                Ну и другие печеньки, типа вызова методов из Visual BASIC. Как известно из истории — BASIC — это самое любое детище Гейтса.

                                                                Но пруфа нет, просто где-то прочел о том, что они идеально наложили COM
                                                                  +1
                                                                  Все равно отладчику надо уметь обозревать классы и их методы и члены. Так зачем для этого городить новую технологию, если есть собственная?
                                                                  Затем что лицензия на Java требует реализации технологии от Sun (теперь, понятно, от Oracle).

                                                                  Как известно из истории — BASIC — это самое любое детище Гейтса.
                                                                  Было. До вызода .NET Visual FRED его фактически убил.
                                                          0

                                                          Читайте документацию внимательнее. По вашей же ссылке написано:


                                                          In C++Builder, the compiler recognizes classes that have only pure virtual methods and no data members as corresponding to Object Pascal interfaces.
                                                            0

                                                            Угу, интерфейсов нет, есть классы с чисто абстрактными методами, и есть макрос __interface.
                                                            Ну и всё это имеет какое-то отношение к интерфейсам из делфи.
                                                            Всё, вы меня утомили своим билдером. Я больше на эту ересь отвечать не буду.

                                                              0

                                                              Да я, что, спорю? Никакими ухищрениями типа CRTP, множественного виртуального наследования невозможно в С++ достичь того же, что доступно в тех же C# и Java. Просто есть нюанс, что конкретный компилятор может "соптимизировать" интерфейсы. Семантика от этого не меняется, меняется лишь представление в памяти.

                                                  +13

                                                  Всё проще.


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

                                                    +1
                                                    Наверно наиболее оптимальное определение, из тех что не дают тему для холивара.
                                                      +1
                                                      Я бы только, наверно, уточнил: не «протокол коммуникации», а «описание протокола коммуникации», поскольку «протокол коммуникации» может подразумевать конкретную реализацию.
                                                  +2
                                                  Я бы на этот вопрос ответил так:

                                                  Интерфейс — описание некой общности. Без конкретной реализации.

                                                  Абстрактный класс — частичная реализация, требующая уточнения, чтобы стать классом.

                                                  Оба понятия идут непосредственно из концепций ООП и никак не связаны с конкретным языком.

                                                  Остальное — нюансы, определяемые синтаксисом языка.
                                                  +1
                                                  Если расскажете чем отличаются абстрактные классы и интерфейсы на примере JavaScript, плюсану сюда и в карму)
                                                    0

                                                    Все просто. Интерфейсы в Javascript существуют только в документации. Пример чистого интерфейса — ChildNode, вы не найдете переменной с таким именем в рантайме.


                                                    Абстрактный же класс в javascript — это функция-конструктор, которую нельзя вызывать. При этом, он имеет имя, на него можно ссылаться и его прототип можно найти в цепочке прототипов некоторых объектов, что в свою очередь означает работоспособность оператора instanceof.


                                                    Пример абстрактного класса в Javascript — HTMLElement (в документации написано что это интерфейс, но это не противоречит тому что это еще и класс — в Javascript в силу слабой распространенности instanceof-проверок любой класс является еще и интерфейсом).

                                                      +1
                                                      Шикарно. То есть основное отличие — это названа та или иная сущность интерфейсом в документации или нет? А я бы все таки сказал, что понятия абстрактный класс и интерфейс не применимы к языку с архитектурой подобной JavaScript.
                                                      А что вы скажете о Python, там ситуация еще более интересная)

                                                        0

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

                                                          +1
                                                          Ну тогда наверно стоит пояснить что такое чистые и не чистые интерфейсы, а то все становится еще запутаннее. А в Python не так, во первых реализация абстрактных классов есть, хоть и с помощью модуля стандартной библиотеки. Разница между тем что принято называть интерфейсом и абстрактным классом такая же как и в С++, то есть формально никакой.
                                                            0

                                                            Чистый интерфейс — это интерфейс, который не является классом. Это понятие возникает в языках с утиной типизацией, где любой класс является одновременно еще и интерфейсом.

                                                              –1
                                                              В С++ есть чистый интерфейс, это не экзамен) Просто хочу понять мысль.
                                                                +1

                                                                Не слышал о таком понятии в С++.

                                                                  –1
                                                                  Короче, вы еще больше запутали, а что тогда означает «чистые интерфейсы не существуют в коде и в рантайме»?
                                                                  Разве я не могу через «чистый интерфейс» (полагаю имеется ввиду что-то типа COM интерфейсов) обратиться к объекту? Если так, то он и в коде есть, и в рантайме, пусть в виде некой структуры, но есть.
                                                                    0
                                                                    Все просто. Интерфейсы в Javascript существуют только в документации.

                                                                    Это понятие возникает в языках с утиной типизацией, где любой класс является одновременно еще и интерфейсом.

                                                                    При чем тут "что-то типа COM интерфейсов"?

                                                                      –1
                                                                      Ну все понятно теперь, но не троллинга ради) вернемся к вашему первому утверждению «Это общие понятия, там ответы будут очень похожими для любых языков где есть абстрактные классы и интерфейсы»

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

                                                                        Интерфейсы — зависят. Понятие интерфейса — общее.


                                                                        Напомню, вы спрашивали про чистые интерфейсы.

                                                                          0
                                                                          Вообще-то я спросил про JavaScript, а там оказались не простые, а как мы выяснили «чистые интерфейсы». Согласитесь разница между логическим понятием «чистые интерфейс» и например интерфейсом реализованным как часть языка C# имеется, и весьма приличная.
                                                                            0

                                                                            Так там никаких противоречий и не было. Интерфейс — это свойство (или набор свойств в понимании JS), которым обладают объекты. Что в C#, что в Javascript.


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


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

                                                                              0
                                                                              Ладно, закроем тему, а то уже пошло обсуждение «вопросов веры» и «трактовки священного писания». В этом похоже вы выиграли, судя по минусам у вас есть как минимум один последователь)
                                                      0

                                                      Как-то так:


                                                      /** @interface */
                                                      class BuzzerInterface {
                                                        constructor() {
                                                          throw Error('Can not instantiate BuzzerInterface');
                                                        }
                                                      
                                                        buzz() {
                                                          throw Error('Not implemented');
                                                        }
                                                      }
                                                      
                                                      /** @abstract */
                                                      class AbstractClass {
                                                        constructor(a) {
                                                          if (new.target === AbstractClass) {
                                                            throw Error('Can not instantiate AbstractClass');
                                                          }
                                                      
                                                          this._a = a;
                                                        }
                                                      
                                                        getA() {
                                                          return this._a;
                                                        }
                                                      }
                                                      
                                                      /** @implements BuzzerInterface */
                                                      class ConcreteBuzzer extends AbstractClass {
                                                        constructor(a) {
                                                          super(a + 1)
                                                        }
                                                      
                                                        buzz() {
                                                          return `${this.getA()} buzz buzz`
                                                        }
                                                      }
                                                    +3
                                                    А какая разница про какой язык он не смог ответить?
                                                      +3
                                                      На некорректно поставленные вопросы зачастую лучше не отвечать. Ибо всякий ответ будет равносилен вбросу.
                                                        +3
                                                        А с чего вы взяли что вопрос был поставлен некорректно? Соискатель-то знал про какой язык речь идет.
                                                        • UFO just landed and posted this here
                                                            0
                                                            Нет, речь не о PHP. Вопрос, думаю, не редкий. И часто лежит не в плоскости технических отличий, а отличий смысловых. Когда правильно использовать интерфейс, а когда абстрактный класс. По технической части их, худо-бедно, различают.
                                                              0
                                                              Такой вопрос задают для всех языков: C++, Java, C# и т.д. При чём здесь PHP?
                                                        0
                                                        Очевидно, в указанном в вакансии.
                                                        А если не уточнили — то с точки зрения ООП на этот вопрос есть вполне конкретный ответ.
                                                          –1

                                                          Только вот есть проблема — в ООП нет понятий "абстрактный класс" и "интерфейс" в том виде, в котором их можно сравнить.

                                                            +1
                                                            Абстрактный класс в объектно-ориентированном программировании — базовый класс, который не предполагает создания экземпляров. Абстрактные классы реализуют на практике один из принципов ООП — полиморфизм. Абстрактный класс может содержать (и не содержать[1]) абстрактные методы и свойства. Абстрактный метод не реализуется для класса, в котором описан, однако должен быть реализован для его неабстрактных потомков. Абстрактные классы представляют собой наиболее общие абстракции, то есть имеющие наибольший объём и наименьшее содержание.

                                                            Интерфе́йс (англ. interface) — программная/синтаксическая структура, определяющая отношение между объектами, которые разделяют определенное поведенческое множество и не связаны никак иначе. При проектировании классов, разработка интерфейса тождественна разработке спецификации (множества методов, который каждый класс, использующий интерфейс должен реализовывать).


                                                            В каком месте их нельзя сравнить? Уверяю вас, даже если вы привёдете просто определение и того и другого — 99% интервьюэров этого хватит.
                                                        +21
                                                        Всё верно говорите. Если человек имеет показать «интересные домашние проекты» и пилит либы для MapReduce, то после вопроса «чем абстрактный класс отличается от интерфейса» ему сразу становится совсем неинтересно, скучно, причём настолько, что даже не заладится.

                                                        Такие вопросы в лучшем случае являются лёгким тролингом, но обычно говорят о том, что вы вообще не понимаете, кто вам нужен.
                                                          –7
                                                          Знаете, красиво рассказывать не значит понимать. Если человек красиво рассказывает, но не знает основ, то он точно нам не нужен. А без понимания основ, я даже боюсь представить, что у него за MapReduce.
                                                            +6
                                                            Может стоило все же посмотреть? Вдруг код хороший.
                                                              +1
                                                              чудес не бывает
                                                                +3
                                                                Ну так он его и не показывал. И в открытом доступе, как он сказал, его нет. Да и, как верно заметили в соседнем комментарии, чудес не бывает.
                                                                  0
                                                                  Можно показать код и работающее приложение через TeamViewer или предоставить любой кусок кода, которым гордишься. Было бы желание и наличие чего показать.
                                                                  +1
                                                                  Намного проще и быстрее отсеить дурака — задать простые вопросы, а не смотреть код у каждого соискателя.
                                                                  +27
                                                                  А вы не бойтесь и не представляйте, а возьмите и посмотрите код. Вам за это деньги платят вообще-то. Собеседование — процесс обоюдный, надо готориться и вам тоже.
                                                                  Вообще это цирк с конями какой-то. «Проект на ГитХабе является плюсом», но проект мы смотреть не будем, а то вдруг он основ не знает.

                                                                  >>но не знает основ

                                                                  О да, моё любимое. Вы поди каждый день абстрактные классы пишите. Вот сколько от вас абстрактных классов ушло в продакшн?

                                                                  Если перед вами «боевой командир» с опытом в 10+ лет, проектами на Гитхабах и прочим, то на подобные вопросы он может не ответить только потому, что он это забыл за ненадобностью. Какой вообще практический прок от этого знания? Только не надо закатывать очи горе и рассказывать про «основы». Привидите пример из жизни, когда это сакральное знание на что-то может повлиять.
                                                                    –7
                                                                    10+ опыта и забыл про абстрактные классы? А что он 10 лет писал, FizzBuzz?

                                                                    Я не о том уместен или неуместен вопрос, а об отмазке забыл за 10 лет. А в прод он Визуал Бейсик запускал?
                                                                      +18
                                                                      Было озвучено ДВА простых вопроса: «сколько от вас абстрактных классов ушло в продакшн» и «пример из жизни, когда это сакральное знание на что-то может повлиять».

                                                                      Ответы на них дадут импульс продуктивоной беседе. Я, наверное, невнимателен, но в вашем коментарии я их не вижу вообще. Буду рад, если вы опровергнете моё впечатление и укажете конструктив.
                                                                        –1

                                                                        Эм. В смысле? Много, я не считал. Знание и понимание того, зачем нужен абстрактный класс никуда пока не делось.

                                                                          –1
                                                                          Знаете, вот по «сколько от вас абстрактных классов ушло в продакшн» — уже можно докапаться и сделать вывод, что вы не понимаете зачем нужны абстрактные классы. Имхо, гораздо правильнее спросить «сколько от вас классов ушло в продакшн, которые унаследованны от какого-либо абстрактного класса?» — и вот тут будет ответ — процентов 50 классов, написанных мной на бекенде.

                                                                          Пример: делал когда-то сайт на ASP.Net — был в отпуске. Дали на поддержку какому-то фрилансеру, он изменил(вместо оверрайда на конкретной странице) метод PageLoad базового класса прямо на продакшене, что привело к недоступности сайта на 3 часа.
                                                                            0
                                                                            Судя по тому как заминусовали, я могу сделать вывод о текущем уровне части читателей Хабра. Если утверждение о том, что за 10 лет в индустрии про абстракт классы можно забыть (мы говорим о разработчиках и архитекторах) то по сути, здесь уже не о чем говорить. О конкретных количествах абстракт классов ушедших в прод тоже. Я не считаю. Концепция абстракт классов это инструмент, инструмент для лучшей борьбы со сложностью, DRY и все такое. Не вижу смысла вести дискуссию с людьми, кто не понимает элементарных вещей. Я думаю на собеседовании этот вопрос по прежнему остается актуальным. Кто бы что не говорил.
                                                                              +1
                                                                              Забавно, я вообще в основном embedded и драйверами занимаюсь, на C примусы починяю. ООП пользую редко и не очень люблю, в middleware и applications стараюсь не лезть без нужды и экспертом ООП себя не считаю. Но я всё же слегка прифигел от количества плюсов на комментах yorick_kiev_ua и минусов на ваших. Если человек претендует на знание ООП чуть дальше азов, то вопрос на понимание сути интерфейсов и абстрактных классов не должен его смущать. Это абсолютно нормальный вопрос, если на работу нужен ООП разработчик, а не быдлокодер, который прочитал пол книжки.
                                                                                +2
                                                                                На самом деле, когда проводишь какое то количество собеседований, то очень видно как огромное количество людей, позиционирующих себя как серьезные девелоперы инженеры, отсеиваются на азах. Отсюда и попаболь которая сквозит во всех этих удивленных вопросах, о том зачем это надо, я фулл стек инженер, и мне не надо знать ни абстракты, ни структуры данных, я пользуюсь готовыми. В любом серьезном бэкэнде, особенно критичном по скорости или обьему, таких вопросов даже не ставится. Это кирпичики, и инструменты для разбиения сложности. Со сложностью можно по разному бороться, но ООП в принципе и было представлено как адекватное решение многих проблем. В этом плане интересно написал Б. Страуструп в своей культовой С++, расказывая о проблемах и сложностях кодовой базы в десятки тысяч строк кода. Я сейчас проектирую большие API и проблемы борьбы со сложностью там встают как нельзя больше, код готорый мы генерируем из схем весь абстрактный, то есть все классы абстрактные, расширение функциональности происходит от наследования от них. Это все тонкие вопросы и серебряной пули нет.
                                                                                Здесь в ссылке есть отличный пост на эту тему.
                                                                                https://blog.codinghorror.com/why-cant-programmers-program/
                                                                                  +3
                                                                                  Меня, кстати, это тоже удивило. Как-то слишком тут много приверженцев утверждения «Зачем знать названия педалей, чтобы быть профессиональным водителем? Я вот десять лет вожу машину, и до сих пор не знаю»
                                                                                    0

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

                                                                              0
                                                                              На прошлой неделе два абстракт класса.
                                                                              Пример из жизни, когда реализуется какая либо общая функциональность для различных имплементаций.
                                                                              Например генераторы кода для С, Java, Json схем, из XML схем.
                                                                              0
                                                                              Да, я 10 лет пишу абстрактные классы и интерфейсы, но я понятия не имею какой из них как называется. Я просто пишу код, и называю классы семантически правильно. Если мне нужен класс с набором публичных свойств, только чтобы другие объекты правильно реализовывали этот интерфейс — я сделаю так, не задумываясь об академических наименованиях.
                                                                                +2

                                                                                Если в вашем языке нет отдельного понятия "интерфейс" — ок. А если есть… всё плохо.

                                                                                  +2

                                                                                  Проблема в том, что сейчас всё таки необходимо владеть профессиональным языком. 95% проектов — командная разработка, командная разработка предполагает коммуникацию — если вы будете пытаться объяснять кусок кода на том же Code Review, а вас не поймут — это ненормально. Или на объяснения вы будете тратить лишнее время.


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


                                                                                  Т.е. в современном мире важно не только программировать, но и доносить свои идеи до начальника, коллектива, документации — поэтому понимание и общая терминология всё таки важны.

                                                                                    +5
                                                                                    обеспечь архитектектурное решение по ограничению доступа к ресурсу по принципу: в одну единицу времени только один любой экземпляр объекта может иметь к нему доступ — запросы других объектов блокируются/должны обождать выполнения текущих процессов

                                                                                    Это мьютекс.


                                                                                    реализуй синглтон, для доступа к ресурсу

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

                                                                                      –3

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


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

                                                                                        +4

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

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

                                                                                        Одно другому не мешает. Можно и вопросы позадавать, и тестовое задание дать, чтобы код посмотреть. Первое — чтобы проверить теоретические знания, второе — практические.
                                                                                  +6
                                                                                  среднего размера проекты на C# — и интерфейсов и абстрактных классов хватает. Мало того, они действительно нужны, а не вам на зло придуманы. И если я спрашиваю про них — так это потому, что человеку придётся с этим работать.
                                                                                    0
                                                                                    Еще раз, для тех кто невнимательно читал. Соискатель не предоставил код, его нет в открытом доступе и показывать он ничего не собирался.

                                                                                    И да, интерфейсы и абстрактные классы я пишу довольно часто. И почти все они в продакшене.
                                                                                    А этот «боевой командир» просто балаболка. Он это не забыл за ненадобностью, а просто не знает.

                                                                                    Вы бы, наверное, Грефа взяли программистом, он тоже про Agile и блокчейн красиво рассказывает. Да только знания надо подтверждать.
                                                                                      0
                                                                                      Если Греф на такую зарплату придет, конечно возьмут, даже если он аджайл от блокчейна отличает только по цвету папки. Хотя, возможно, и после тщательного медицинского обследования.
                                                                                        0
                                                                                        Не, ну не такую зарплату. Ему надо платить больше, ведь он знает такие умные слова )))
                                                                                      +1
                                                                                      Это как спросить носителя языка, почему к этому глаголу нужен этот падеж или каково происхождение корня этого слова. Все отвечают «эээ… ммм… не знаю, я не лингвист», но при этом блестяще выражают свои мысли.
                                                                                        +2
                                                                                        Вы, когда пишете программу, скажем, на C# или Java, написали слово public, а какое за ним слово писать — «interface» или «abstract class» — как определяете?

                                                                                        Вот это и спрашивают :)

                                                                                        Вы не знаете, в чем разница? А вы точно знаете язык?..
                                                                                      0
                                                                                      Ну то есть если человек, знает алгоритмы может спроектировать систему «с нуля» и обосновать свой выбор, но не знает чем отличается абстрактный класс от интереса то он не знает основ? довольно спорное утверждение мне кажется?
                                                                                        +1
                                                                                        А кто сказал что он все это знает? Он ни про алгоритмы, ни про проектирование ничего не говорил. Только про то что это классно, что ему этим интересно заниматься, что за этим будущее и пр. Если бы он все это знал, то я бы не стал спрашивать такие простые вещи.
                                                                                          0
                                                                                          Если так то противоречия нет, просто если говорить об основах, то имхо такие вещи как алгоритмы будут действительно показателем базы.
                                                                                      +3
                                                                                      А потом возьмёте такого человека, он половину ваших задач посчитает «лёгким троллингом».
                                                                                      — Как это почистить и отрефакторить код для будущего расширения? Я же тут только интересными проектами занимаюсь, мне ваш скучный код не упёрся.
                                                                                        +4
                                                                                        Как часто вы рефакторите абстрактные классы? Как часто незнание отличия абстрактного класса от интерфейса приводит к проблемам?

                                                                                        Примеры кода — бесценно.
                                                                                          0

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

                                                                                            +2
                                                                                            Скажите, а вас что держит в месте, где полно унылых задач? Что компенсирует вам то распространяющее вокруг вас ощущение уныния во всём. Что даёт свет в тоннеле?

                                                                                            Знание абстрактных классов и интерфейсов?
                                                                                            +1

                                                                                            Мне кажется, или вы перегибаете?
                                                                                            Это настолько же базовые вещи, как разница между if и for.
                                                                                            И да, практически в любом языке с моделью ООП а-ля java, без них никуда

                                                                                              0
                                                                                              Вам пытаются намекнуть, что разработчики больше практики, чем академики. Намного проще предложить соискателю написать немного кода. В конце концов, поставьте 2 задачи на 10 минут каждая, в одной по смыслу нужен абстрактный класс, в другой — интерфейс. Руки разработчика сами все вспомнят и напишут.
                                                                                                +2
                                                                                                Руки разработчика сами все вспомнят и напишут.
                                                                                                Или не напишут. Я помню одно из моих первых интервью, где я был «тенью» (человек, тихо сидящий в сторонке и на задающий вопросы, а просто смотрящий на то, как «старшие товарищи» ведут интервью). Кандидат знал больше о синхронизации, чем интервьюер, но… при попытке «развернуть слова в строке» минут 10 ушло на попытки вспомнить как в Java эту строку модифицировать, а когда эту проблему разрулили — код так и не появился. Потом выяснилось, что в резюме была «неточность»: оказалось, что опыта написания кода у кандидата нет вообще, есть опыт работы тестировщика.
                                                                                                0
                                                                                                Я бы сказал, что это больше разница как в do… while и while… do, на крайний случай for. Или как цикл и рекурсия. Но не оператор цикла и ветвления. В C++ нет интерфейсов, поэтому «маємо, то что маємо». А так как в Jave нет множественного наследования, то и замена интерфейса абстрактным классом выглядит подозрительным. Я бы спрашивал не теоретические отличия, а практический смысл в этом.
                                                                                            +2
                                                                                            что вы вообще не понимаете, кто вам нужен.
                                                                                            Для меня это прямо загадка века. Зачем компании нанимают разработчиков? Чтобы были? Чтобы сделали что-то конкретное? Потому что «нужно больше программистов»?

                                                                                            Где-то надо допилиливать какую-нибудь легаси систему на миллионы строк, которая писалась 20 лет и со временем только обрастает костылями, потому что рефакторинг займёт ещё 10 лет. Где-то надо каждый месяц клепать новый проект для «иностранных заказчиков», используя устоявшийся конвейер из модных фрэймворков, шаблонов и чёрт знает чего ещё. А где-то тебе просто скажут: «Вот наша студия поймала очередной заказ с upwork-а, выполняй».

                                                                                            Где-то хряк-хряк — и в продакшн, потому что «надо вчера», лишь бы работало. Где-то вылизывают каждый класс и над строчкой кода можно думать по часу, а на code review обсуждают Макконелла и best practices (нет).

                                                                                            Где-то надо будет придумывать, как решать сложные задачи, используя результаты научных исследований и наработки флагманов индустрии. А в другом месте говорят: «Вот у нас есть то-то и то-то, надо ещё примерно такого же 50 штук, вперёд!».

                                                                                            «Кто нужен-то и для чего?» — вот какой вопрос у меня теперь постоянно возникает, когда я вижу очередные статьи и комментарии о human resources.
                                                                                              0
                                                                                              Спорный момент, если честно. С одной стороны, если парень увлекается программированием для души, это хорошо. С другой стороны, это всё-таки больше инженерная работа, чем искусство, а инженер должен знать матчасть. Вы же не будете брать на работу в конструкторское бюро парня, который рисует офигенски красивые мосты, но не учил такой нудный и унылый сопромат?
                                                                                                +2
                                                                                                Знаете, если человек утверждает на собеседовании, что явсляется экспертом в линейной алгебре и решил в ней кучу прикладных задач, но не может ответить на вопрос, чес вектор отличается от скаляра, это, мягко говоря, подывает доверие к его экспертизе.

                                                                                                Если же он, в сочетании с неответом на тривиальный вопрос, говорит, что указанные решения задач он по какой-либо причине предъявить не в состоянии, то это просто значит, что он лжет.
                                                                                                –2
                                                                                                Вот интересно, какую пользу может принести это конкретное знание?
                                                                                                На мой взгляд только:
                                                                                                Абтсрактный класс может быть только один в родителях а интерфейсов много.
                                                                                                При этом где-то это огрнаичения языка а где-то хорошие практики.
                                                                                                  0

                                                                                                  Опять вы говорите про конкретный язык (или несколько языков). А правильный вопрос я уже задавал выше.

                                                                                                    0
                                                                                                    Где я говорю про конкретный язык?

                                                                                                    Вы понимаете что интерфейс можно написать даже на С. (Не на С++).

                                                                                                    Что такое интерфейс? Интерфейс это контракт описывающий целостную грань поведеиня объекта (чем бы он ни был) компоненты или класса посредством перечисления доступных действий. При этом никак не определяет реализацию. Здесь целостная грань — это архитектурное представление, а не формальное описание и означает что берется какой-то аспект поведеиния целиком не разбиваясь на подгруппы.

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

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

                                                                                                    У интерфейсов кстати есть один некритичный недостаток. Интерфейс определяет набор действий но не задает их последовательность. А иногда это не обходимо.
                                                                                                    0
                                                                                                    «Абтсрактный класс может быть только один в родителях а интерфейсов много.»
                                                                                                    Ответ не верный, в C++, Python (это из распространенных) вполне могут быть, часто даже по адекватным причинам.
                                                                                                      –5
                                                                                                      Не ужели! Век живи — век учись. Правда «При этом где-то это огрнаичения языка а где-то хорошие практики.» как-то не отпечаталось в сознании.
                                                                                                      Да… за ваш ответ вы бы ушли с моего собеседования улицы мести.
                                                                                                      Формальная возможность языка не значит что так и надо делать.
                                                                                                      Множественное наследование в практичеких случаях либо не возможно либо бессамысленно. Потому что скорее всего ваши абстрактные классы уже имеют общего предка.
                                                                                                    +4
                                                                                                    А я встречался с кодом, где ВСЁ! на интерфейсах и абстракциях. И ещё иногда final встречается. Лучше бы автор вообще не знал про интерфейсы и абстрактные классы, было бы намного проще этот код поддерживать.

                                                                                                    Поговаривают, что любовь к абстракциям у него появилась после ZCE и я сразу расхотел его сдавать :)
                                                                                                      0

                                                                                                      Бред какой-то. Что именно "ВСЁ!" там на интерфейсах и абстракциях? А то может проблема не в нём, а в вас?

                                                                                                        +3
                                                                                                        Это, кстати, любопытное замечание.
                                                                                                        Вера в догматику уровней абстракций говорит об опыте и кругозоре человека не в лучшую сторону.
                                                                                                        Чем больше опыта, тем меньше убежденность, что всё можно решить заранее волшебством паттернов, соблюдением закона Диметры, слабой связанностью и прочими правильными и красивыми терминами, порождающими из примитивной задачи монстров на несколько десятков тысяч строк кода. Вместо простых и прагматичных решений, пускай и не кричащих, что автор читал очень умные и правильные книжки.
                                                                                                        Сужу во многом по себе.
                                                                                                          0
                                                                                                          А ну его, энтот «мотан»! Мы — люди простые, мы университетов не кончали, но сами кого хошь жить научим.

                                                                                                          То, что вы называете «верой в догматику», а данном случае — простая грамотность. Это не значит, что надо «порождать из примитивной задачи монстров на несколько десятков тысяч строк кода». В каждый конкретный момент надо думать над задачей, а не над теорией. Это правда. Но это не отменяет необходимость знать теорию. Ну хоть немного. И уж точно отсутствие понимания теории — не предсет для гордости разумного человека.
                                                                                                        +2
                                                                                                        Опытный разработчик может забыть определение интерфейса и абстрактного класса, тем более, что эти понятия в современных языках достаточно размыты.

                                                                                                        Но он точно не может забыть, когда он использует интерфейсы, а когда — абстрактные классы. От джуна стоить ждать определения, от сеньора — устное эссе на 200 слов по теме.
                                                                                                          0
                                                                                                          Предполагаемый диалог в ответ на вопросы «Чем отличаются И и А»
                                                                                                          — Я вам отвечу про отличие интерфейса от абстрактного класса (эссе на 200 слов или таблица для PHP), но прежде вы ответьте, зачем бы вы их использовали? В каком случае можно обойтись без них, а в каком без них обойтись нельзя?
                                                                                                          +3
                                                                                                          Интерфейс от абстрактного класса отличаются тем, что в Го нет абстрактного класса, а интерфейс — есть.
                                                                                                          А еще они ничем не отличаются друг от друга в Руби — их там просто нет.
                                                                                                          Замечательно они не-реализованы и в JS тоже.

                                                                                                          Такие абстрактные вопросы — замечательны сами по себе. Мол, щас я его срежу, ахахаха, смешно. Моделей объектно-ориентированного программирования (вернее, их конечных реализация в языках) примерно два вагона и еще сто тысяч штук. Пооопэшить можно даже в Эликсире, который совсем не ООП язык. Но есть процессы.

                                                                                                          Понятно, что человек, задающий такой вопрос, по-умолчанию подразумевает, что собеседуемый умеет читать мысли и угадает о чем идет разговор, и даже сейчас же ответит чем интерфейс от абстраткного класса отличается в Яве — ведь «это же самое классическое ооп, ну ты чо».
                                                                                                            +2
                                                                                                            Да, собеседуемый знает на каком языке ему предстоит программировать, более того, он в резюме указал тот же язык. Обе стороны прекрасно знали о каком языке речь. Ваши домыслы это попытки представить вопрос по конкретному языку — абстрактным, и от нежелания читать и вникать в то что написано. Перечитайте еще раз то что уже написано, подумайте и не пишите больше чуши про абстрактные вопросы. Никто не задает на собеседовании абстрактные вопросы про абстрактные интерфейсы. Может вам и хочется считать что собеседующие идиоты, но это не так.
                                                                                                              +2
                                                                                                              Увы, и многие собеседуемые, и многие собеседующие — идиоты.
                                                                                                                +1
                                                                                                                Не согласен. Много кого собеседовал и сам проходил не раз собеседования, но идиотов не встречал. Есть люди которые не знают, есть те кто упорствует в своем незнании, но идиотов не видел.
                                                                                                            +1
                                                                                                            а вот и герой нашей заметки! :)
                                                                                                              0
                                                                                                              Где, говорите, работаете?
                                                                                                              +1
                                                                                                              Пока HR не будут видеть разницу между HTML и языком программирования — ничерта не изменится.
                                                                                                              Не стоит тратить время на то, чтобы заранее вспомнить или приготовить резюме кандидата. В первые полчаса все и так вспомнят, кто он, на какую позицию пришёл, и он расскажет своё резюме ещё раз.

                                                                                                              ЕЕЕЕ… просто самый вкусный момент… зачем вообще заставлять человека пересказывать свое резюме?
                                                                                                              Неужели нельзя подготовить какие то целевые вопросы по резюме и просто их спросить? В итоге, из Х времени на собеседование Х/3 я рассказываю где я был и что я там делал, но окей — у меня всего 3 места работы, но есть люди с большим послужным списком? Зачем Вам знать что я там писал на Делфи на первой работе, при том что сейчас я какой нить JS Developer или верстальщик?
                                                                                                                0

                                                                                                                Я обычно рассказываю про 1-2 последних мест работы. Зачем вы рассказываете про делфи — я не знаю.

                                                                                                                  0
                                                                                                                  Обычно вопрос звучит так: Расскажите о своих местах работы, проектах, технологиях (учитывая что ровно все это описано в самом резюме)
                                                                                                                    0
                                                                                                                    У вас все, что вы можете рассказать о вашей работе в проекте записано в резюме? У вас резюме такое большое, или вы рассказать можете так мало?
                                                                                                                      0
                                                                                                                      Кмк, у каждого есть какие-то задачи, которые он считает достижениями или просто сложные и крупные проекты/задачи, обычно люди в резюме указывают именно их. А вам очень хочется знать про рутинные задачи? Зачем? Они по определению унылое говно, даже если вы работаете на урановом руднике — это интересно послушать ровно один раз, дальше будет тоже самое.
                                                                                                                        +1

                                                                                                                        Если у человека последние интересные задачи, о которых самые яркие воспоминания, были на делфи 10 лет назад — ему можно только посочувствовать.

                                                                                                                          +3
                                                                                                                          Если ваше резюме занимает положенные 1-1.5 страницы, то у вас не так много места, чтоб рассказать про проект и свою роль в нем. Про действительно интересные задачи там не поместится.

                                                                                                                          Даже если у вас была рутина, то рутина доже бывает разная. Когда вас спрашивают, чем вы занимались, то хотят услышать чуть больше, чем «работал работу, снимал с карты зарплату».
                                                                                                                          0
                                                                                                                          Я обычно не рассказываю, о том что уже и так написано, если HR или кто там еще, пол А4 листа резюме, то мне тратить 1 час своей жизни на такое собеседование не особо хочется.
                                                                                                                          Второй момент, в резюме я стараюсь кратко изложить все, возможно важные детали которыми занимался на проекте, а в процессе «повествования» на собеседовании, в плане пересказа своего резюме, я обязательно могу что либо пропустить.
                                                                                                                          Третий момент, читая резюме и видя какие то знакомые слова в резюме, в голове интервьюера, могут всплывать вопросы по тем или иным пунктам, которые он хочет бы спросить, и получается если я что то не расскажу на собеседовании, то интервьюер не спросит об интересующих его вещах (очень часто интересуются за тестирование СУБД, и реально часто я забываю это рассказать, помещая это просто в лоад-тестирование, то есть вопрос рождается уже в процессе совершенно других разговоров).
                                                                                                                            0
                                                                                                                            если я что то не расскажу на собеседовании, то интервьюер не спросит об интересующих его вещах

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

                                                                                                                              0
                                                                                                                              Ну, я смутно себе представляю подготовку, без чтения резюме.
                                                                                                                        +1

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

                                                                                                                          0

                                                                                                                          Дык даже куча примеров про составление резюме — не надо на 3-4 листа и все места работы указывать. Достаточно последних 2-3 и указания общего опыта работы. Точно так же не надо указывать технологии, которые вас сейчас не интересуют (зачем JS Developer указывает Delphi? Для увеличения объема?). Рекомендуется даже иметь 2-3 резюме с разными технологиями, если вы имеете опыт в разных областях и рассматриваете разные позиции.

                                                                                                                            0

                                                                                                                            С одной стороны — да. С другой — часто рекрутера интересует некий "общий стаж", а так же компании, в которых вы работали, и роли, в которых вы там выступали. А ваша текущая сфера специализации и ожидания в любом случае указываются отдельно. Опять же, даже Node.JS разработчику может быть частично релевантен опыт работы с Delphi, если он использовал в Delphi проектах, например, реляционные СУБД.


                                                                                                                            Так что обычно лучше написать больше. Если это не нужно, то для рекрутера не должно составить проблем выкинуть несколько листочков — а не вчитываться в хроники 90х годов.

                                                                                                                              0
                                                                                                                              Если это не нужно, то для рекрутера не должно составить проблем выкинуть несколько листочков

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

                                                                                                                                0
                                                                                                                                О, это идея. Специально в резюме написать — «После этой черты можно выкинуть, если детали неинтересны» )
                                                                                                                                0

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

                                                                                                                                +1
                                                                                                                                зачем JS Developer указывает Delphi

                                                                                                                                Как дополнительные сведения, что он знаком с компилируемыми языками и WinAPI, а значит лучше представляет, как браузер работает "под капотом". А для серверного разработчика на любом языке навык работы с сильной статической типизацией это тем более плюс.

                                                                                                                                  +6
                                                                                                                                  зачем JS Developer указывает Delphi

                                                                                                                                  это как шрамы у мужчин
                                                                                                                                    +1

                                                                                                                                    Эээ. Ну вот мой опыт общения с дельфистами подсказывает, что указание делфи в резюме вовсе не означает знание WinAPI(В делфи? зачем бы?) и понимания компилируемых языков. А из этих двух знаний вообще никак не следует знание того, как браузер работает под капотом.

                                                                                                                                      0

                                                                                                                                      Я имел в виду общие сведения касательно устройства Windows-приложений и разных видов типизации, а не знание того, как написать компилятор JS самому или автоматическое знание C++)

                                                                                                                                        0

                                                                                                                                        Знаете, своё общение с делфи я благополучно закончил 9 лет назад, на первом курсе универа. Но. В то время я довольно много сидел на форумах посвящённых этому языку, и вот могу сказать, что подавляющее большинство людей, могущих указать делфи в качестве языка первой работы, не знают, как устроены Windows-приложения. Тем более, не знают о разных видах типизации. Они, скорее всего, умеют кидать баттоны на форму.
                                                                                                                                        Не поймите превратно, я тоже писал на делфи какое-то время, и отдаю ему должное. Но нет, указание его в резюме не наведёт меня на все эти, указанные вами, мысли.

                                                                                                                                          +2

                                                                                                                                          Поддерживаю. Умение создавать решения на Дельфи само по себе не делает человека программистом. Фреймворк, не побоюсь этого слова TApplicstion защищает программиста от жизненного цикла приложений. VCL целиком — обёртка, защищающая от знания WinApi. А благодаря некоторым моментам реализации программист не только защищён от приснопамятных синглонов, но даже и много больше — многие "программисты" не представляют даже, что их формы можно инстанцировать во множественном числе.
                                                                                                                                          Ну так тем больше стОит Дельфи-программист "с понятием".
                                                                                                                                          P.s. Сам пишу на Дельфи. И вижу, что в этой нише зачастую умение решать задачи бизнеса важнее умения программировать.

                                                                                                                                            0

                                                                                                                                            Я ж не говорю про всех программистов) Если ваше собеседование пройдут 2 человека, у них примерно одинаковый уровень знаний фронтенда, но один кроме JS других языков не знает, а другой писал на Delphi, кого вы выберете? А кого выберет большинство работодателей — более узкого специалиста или у которого кругозор шире? Вот потому и пишут.

                                                                                                                                              +1

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

                                                                                                                                0
                                                                                                                                На хабре статья была на тему как написать резюме так, чтобы HR было за что зацепиться. Иначе стандартная «учился работал участвовал» ни о чём не говорит, а разговор по такому резюме опять скатывается к стандартным вопросам и просьбе пересказать свой опыт своими словами.
                                                                                                                                +1

                                                                                                                                del
                                                                                                                                UPD. Сорри, не понял, что это сарказм

                                                                                                                                  +12
                                                                                                                                  Для меня как для соискателя особенно важно, чтобы компания была динамично развивающейся, а коллектив молодой и дружный. Ну и желательно печеньки чтоб были.
                                                                                                                                    +1
                                                                                                                                    В чем ценность этой статьи и для кого она действительно предназначена?
                                                                                                                                      +10

                                                                                                                                      Для рекрутеров в IT. Это реальный список того, с чем я сталкивался — причём и сам выступая в роли соискателя, и нанимая людей через рекрутинговые агентства. Можно использовать как чеклист. Конечно, есть нюансы, но если рекрутер видит там несколько знакомых пунктов — это значит, что что-то пошло не так.

                                                                                                                                        –8
                                                                                                                                        Простите, но (имхо, конечно) для этого стоило бы написать список полезных советов (и не употреблять слово «антипаттерн», который рекрутер не знает)? А не писать полные сарказма «вредные советы».
                                                                                                                                        Не забудьте написать в описании вакансии, что у вас есть печеньки. А ещё Agile и Scrum. Это так оригинально!

                                                                                                                                        Писать язвительную статью на хабре про признаки «лучшей» компании/собеседования/коллектива/менеджера — это так оригинально. Даже в комментариях каждый раз одно и то же.
                                                                                                                                          +6

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


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

                                                                                                                                      +2
                                                                                                                                      Чуть не забыл. На любом собеседовании обязательно нужно спросить про паттерны. И попросить реализовать синглтон. Наверное, нужно было поставить это первым пунктом.
                                                                                                                                      Чего плохого в том, что бы спросить про паттерны? На моей практике были случаи когда кандидат просил зарплату в 100к рублей, при этом не мог назвать ни одного паттерна, кроме синглтона.
                                                                                                                                        +4

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

                                                                                                                                          +2
                                                                                                                                          На самом деле, любой вопрос который вы задаете могли спросить уже вчера. Тут просто нужно более грамотно подходить к процессу, и если задается вопрос про патерны/технологии/утилиты то стоит в догонку распросить и про недавние случаи их применения.
                                                                                                                                            +1
                                                                                                                                            А еще лучше спрашивать про те вещи, которые вы реально применяете или же хотите увеличить экспертизу в этих вещах, будь то паттерны, фреймворки, языки, да что угодно. Так можно удостовериться, что кандидат очень хорошо подходит именно вам, а не всем.
                                                                                                                                          +9
                                                                                                                                          Программисты бывают разными. Тем, кто работает на низком уровне, паттерны зачастую безынтересны.
                                                                                                                                            +18
                                                                                                                                            Знаю отличных разработчиков, которые не знают паттерны. В то же время знаю тех, кто провалил собеседования, но назвал с десяток паттернов с примерами.

                                                                                                                                            Есть одно важное правило по паттеры — про них нужно знать, но их не нужно учить. Т.е. при проектировании системы можно увидеть ситуацию похожую на шаблон и тогда уже загуглить варианты реализации паттерна и сделать. К тому же чаще всего при проектировании они получаются сами собой. Множество разработчиков писали, к примеру, декораторы, не зная о том что это «Декораторы». Да и из своего опыта — за 10 лет разработки паттерны приходилось использовать раз 10. Несколько раз синлетоны, репозитории (не считая готовых реализаций для IoC), фабрики, по одному два раза декораторы, стратегию, строителя. Из них осознано — только половину. Смог бы я прожить и писать хороший код не зная паттерны — скорее да, чем нет.

                                                                                                                                            Помимо того что этот вопрос очень шаблонный и предсказуемый, я бы не стал его спрашивать у джуниоров — мидов (разве что для понимания уровня кандидата). Зато спросил бы у архитектора или сеньёра. Для них это уже важнее.
                                                                                                                                              +3
                                                                                                                                              Мне кажется, ничего удивительного. Если на мидла собеседовали, то хорошим уровнем было бы просто распознавание паттернов, навроде «это вот что» — «это фабрика», «а это что» — «это итератор», большего на какое-то время и не нужно. Гораздо хуже, когда человек недавно выучил «паттерны для чайников», и пытается всюду их приплести. Иной раз лучше бы и не знал.
                                                                                                                                              Ну а для синьора зарплата вызывает сомнения.
                                                                                                                                                0
                                                                                                                                                Каждый хороший программист проходит через «Синдром патернизации всего и вся». Даже если сейчас он их не знает, рано или поздно он все равно заинтересуется паттернами. Так что чем раньше он этим переболеет тем лучше.
                                                                                                                                                +1
                                                                                                                                                Зачем вообще специально учить паттерны, если большинство из них и так интуитивно понятны при достаточном понимании архитектуры языка и достаточном уровне квалификации и опыта? Зачем мне знать название для решения, которое я сам спокойно придумал и прекрасно осведомлен о его плюсах и минусах? Что мне оно даст, слово это? Я открою статью с названием паттерна и внезапно узнаю о каких-то невиданных и доселе неизвестных мне свойствах абстрактных классов, наследования или композиции?
                                                                                                                                                  +5

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

                                                                                                                                                    +8

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

                                                                                                                                                    +1
                                                                                                                                                    «Зачем вообще специально учить паттерны?»
                                                                                                                                                    Знать названия паттернов нужно как минимум для общения с коллегами. Причем все знать не обязательно, достаточно помнить самые часто используемые. Их можно по пальцам пересчитать.

                                                                                                                                                    «Зачем мне знать название для решения, которое я сам спокойно придумал и прекрасно осведомлен о его плюсах и минусах?»
                                                                                                                                                    Можете ли вы быть на 100% уверенным, что ваше решение не будет антипаттерном? Сколько времени вы потратите на поиск собственного решения?

                                                                                                                                                    Вообще такое мнение, как ваше, говорит лишь об отсутствии стремления к саморазвитию. Такие люди довольствуются знаниями полученными в процессе работы ну и изредка из прочитанных статей. Вы вот например когда последний раз книгу по своей профессии читали и какая это была книга?
                                                                                                                                                    +2
                                                                                                                                                    про паттерны я обычно отвечаю, что я как господин Журден, который не знал, что разговаривает прозой. Но как-то удосужился просмотреть список паттернов и нашел в нем только полтора, которые следовало бы изучать — Visitor и MVC. Остальные нормальный программист переизобретет, как только они ему понадобятся.
                                                                                                                                                      +1
                                                                                                                                                      Я помню собеседовался как-то на вакансию с запросом зарплаты в 100к рублей.
                                                                                                                                                      Меня спросили про то, какие я знаю паттерны. Я спросил все ли мне по списку перечислять или лучше что-то конкретное на примере рассказать? Спросили про синглтон и про то, в каком случае лучше всего использовать именно его. Я ответил что обычно нет случаев, когда можно использовать только синглтон и ничего другого. В любом случае есть разные варианты, а злоупотребление синглтонами некоторые считают антипаттерном. Рассказал немного про strategy и композицию вместо наследования, про template method. Из рабочей практики кроме этих вещей вспомнить ничего больше не смог, хотя в своё время прям балдел от этих паттернов (тот самый период паттернов головного мозга), прочитал Head First и оригинальную книжку банды четырёх.

                                                                                                                                                      В конце общения тоже спрашивал вопросы у собеседующих и один ответ вспоминаю до сих пор.
                                                                                                                                                      Вакансия — Unity / C# разработчик на мобилки.
                                                                                                                                                      Мой вопрос был такой — какие основные причины утечек памяти по ресурсам (текстуркам и мешам) можно выделить при работе с Unity.
                                                                                                                                                      Ответ — про Unity я не знаю, но вот в Marmalade / C++ мы делали вот так… (и далее собственно ответ про ресурсы, я не запомнил все подробности. По-моему это был лид команды разработки на Unity).

                                                                                                                                                      В отзыве о собеседовании получил «отсутствие знаний основных паттернов и неумение их применять». (отзыв кстати был подробным, что сейчас редкость)
                                                                                                                                                        +1
                                                                                                                                                        Скорее всего это означает просто, что ваше собеседование для него было первым)
                                                                                                                                                          0
                                                                                                                                                          А как коррелируют паттерны и уровень з/п? По моему личному опыту чуть меньше, чем никак.
                                                                                                                                                          +2
                                                                                                                                                          Каждый раз читая такие списки глаз цепляется за написание кода на листочке. Хороший программист должен уметь писать код на листочке! Это показывает, насколько человек понимает работу дебаггера, как хорошо понимает код.
                                                                                                                                                          Да в таком случае не надо придираться к синтаксическим ошибкам, названием системных функций и т.д. Но уметь разворачивать алгоритм без IDE, видеть граничные условия — это важный программистский навык.
                                                                                                                                                            +3

                                                                                                                                                            Здесь есть нюанс в различии между "на листочке" и "без IDE". Про себя скажу, что люблю начинать писать с драфта, а потом его наращивать. Плюс к этому, у меня ужасный почерк. Так что к любому предложению написать что-то на бумаге я отношусь негативно. В специализированном тренажёре, текстовом редакторе или скайпе — ещё более-менее. Хотя если честно, я не понимаю, какой такой бонус может дать разработчику IDE, чтобы его лишать этого бонуса на тестировании.


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

                                                                                                                                                              +1
                                                                                                                                                              Корявость подчерка, возможно, единственное оправдание нежеланию писать на листочке. Согласен, что вариант вроде блокнота либо специального сайта, синхронизирующего текст, тоже сойдет.

                                                                                                                                                              А хорошо настроенная IDE со статическим анализатором кода очень сильно обленяет программиста. Напоминает о граничных условиях, например. Ну и если дебаггер использовать, тоже смысл теряется.

                                                                                                                                                              На практике людям полагающимся на IDE это может аукнутся. Встречал ситуацию, когда разработчик не глядя принял автомотический рефакторинг решарпера и тем самым сломал логику функции. (за давностью лет конкретный пример не вспомню)
                                                                                                                                                                +4
                                                                                                                                                                Я на листочке разве что блок-схему могу нарисовать, писать разучился совсем — буквы путаю, раскладка постоянно переключается, шрифты сбиваются…
                                                                                                                                                                  +1
                                                                                                                                                                  Всё же спорное решение.

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

                                                                                                                                                                  Конечно есть вопросы, ответы на которые проще набросать на доске, но написание сколько-нибудь значимого объёма кода я бы проверяла в максимально комфортной для человека среде, со всеми плагинами, сниппетами и кастомными шорткатами, потому что именно так будет выглядеть реальный процесс решения рабочих задач в случае если соискатель будет нанят. А так получается человек не только с волнением во время собеседования будет бороться, но и элементарно с мышечной памятью. И чем сильнее он оптимизировал рабочий процесс, тем сложнее ему придётся.
                                                                                                                                                                    0
                                                                                                                                                                    Обсуждение изменчивой реальности уже было в соседнем треде. Проект может разрастись и начать долго компилироваться, стектрейс или логи могут прийти по которым проблема не воспроизводится, просто на руках может не быть ни устройства ни эмулятора этого устройства. Да в конце концов в IDE и плагинах тоже бывают ошибки, не умея компилировать код своей головой обнаружить их будет затруднительно.

                                                                                                                                                                    И я не говорю про написание целого проекта, я говорю про обход дерева, которое пришло на вход, например. Задачки на пару вложенных циклов.