Pull to refresh

Comments 483

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

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

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

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

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


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


Что я забыл?

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

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

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

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

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


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

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

А ведь есть же еще языки в которых нет классов и/или интерфейсов, мне кажется такие вопросы задаются чтобы показать какой умный интервьюер вас собеседует, чтобы будущий работник понимал как ему будет «здорово» работать с таким коллегой/начальником.
Мне кажется, что одна из целей собеседования в этом и состоит — убедиться, что работодатель и работник разговаривают «на одном языке». Так что такой открытый вопрос, или даже точнее тема для обсуждения, на собеседовании — это нормально, при условии, что ответ оценивает специалист, а не HR по бумажке.
UFO landed and left these words here

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


virtual void f() = 0;

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

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

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


Код
#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


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

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

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

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"(а встречаются и такие) скажет, что ничем они не отличаются.

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


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

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

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

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

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

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


оффтоп

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

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

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

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

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

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

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

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

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


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

бинго.

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

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

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

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

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

Cудя по вики,


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

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

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

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

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

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

COM-интерфейсы — это «мир Windows». И именно об реализациях COM-интерфейсов в языках программирования я вам и писал.
Судя по вики "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 согласился.
Готов согласится. я действительно очень далек от явы и мог и перепутать, Вполне возможно, что именно это и было причиной закрытия MSJVM,

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

Всё проще.


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

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

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

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

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

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

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


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


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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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


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


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

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

Как-то так:


/** @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`
  }
}
А какая разница про какой язык он не смог ответить?
На некорректно поставленные вопросы зачастую лучше не отвечать. Ибо всякий ответ будет равносилен вбросу.
А с чего вы взяли что вопрос был поставлен некорректно? Соискатель-то знал про какой язык речь идет.
UFO landed and left these words here
Нет, речь не о PHP. Вопрос, думаю, не редкий. И часто лежит не в плоскости технических отличий, а отличий смысловых. Когда правильно использовать интерфейс, а когда абстрактный класс. По технической части их, худо-бедно, различают.
Такой вопрос задают для всех языков: C++, Java, C# и т.д. При чём здесь PHP?
Очевидно, в указанном в вакансии.
А если не уточнили — то с точки зрения ООП на этот вопрос есть вполне конкретный ответ.

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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


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


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

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

Это мьютекс.


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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Но он точно не может забыть, когда он использует интерфейсы, а когда — абстрактные классы. От джуна стоить ждать определения, от сеньора — устное эссе на 200 слов по теме.
Предполагаемый диалог в ответ на вопросы «Чем отличаются И и А»
— Я вам отвечу про отличие интерфейса от абстрактного класса (эссе на 200 слов или таблица для PHP), но прежде вы ответьте, зачем бы вы их использовали? В каком случае можно обойтись без них, а в каком без них обойтись нельзя?
UFO landed and left these words here
Да, собеседуемый знает на каком языке ему предстоит программировать, более того, он в резюме указал тот же язык. Обе стороны прекрасно знали о каком языке речь. Ваши домыслы это попытки представить вопрос по конкретному языку — абстрактным, и от нежелания читать и вникать в то что написано. Перечитайте еще раз то что уже написано, подумайте и не пишите больше чуши про абстрактные вопросы. Никто не задает на собеседовании абстрактные вопросы про абстрактные интерфейсы. Может вам и хочется считать что собеседующие идиоты, но это не так.
UFO landed and left these words here
Не согласен. Много кого собеседовал и сам проходил не раз собеседования, но идиотов не встречал. Есть люди которые не знают, есть те кто упорствует в своем незнании, но идиотов не видел.
а вот и герой нашей заметки! :)
Пока HR не будут видеть разницу между HTML и языком программирования — ничерта не изменится.
Не стоит тратить время на то, чтобы заранее вспомнить или приготовить резюме кандидата. В первые полчаса все и так вспомнят, кто он, на какую позицию пришёл, и он расскажет своё резюме ещё раз.

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

В крайнем случае можно использовать доску. Так и нагляднее для всех участников собеседования, и пространство заведомо ограничено, что гарантирует компактность задачи, стереть можно на ходу что-то. А главное доска – вполне распространённый в командной работе инструмент, человеку есть смысл это уметь. А ручкой я, например, 10+ строк буду писать через физическую боль. Печатаю быстро, рисую охотно, а вот мелко писать что-то длиннее предложения давно разучилась. Руку сводит.

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

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

Вы поймите меня правильно, это не критика конкретно вас или процесса собеседования в вашей компании. Возможно, у вас действительно всё находится в рамках разумного. Эта статья про обобщённые проблемы найма, и моё мнение в данном случае писалось именно в этом ключе.
В крайнем случае можно использовать доску. Так и нагляднее для всех участников собеседования, и пространство заведомо ограничено, что гарантирует компактность задачи, стереть можно на ходу что-то. А главное доска – вполне распространённый в командной работе инструмент, человеку есть смысл это уметь. А ручкой я, например, 10+ строк буду писать через физическую боль. Печатаю быстро, рисую охотно, а вот мелко писать что-то длиннее предложения давно разучилась. Руку сводит.
Листок тоже заведомо ограничен, для меня удивительно что вам принципиально неудобнее писать на бумаге, чем на доске.

Ну и под «писать на листочке» я уже в нескольких комментах написал что вполне допускаю Notepad или специально предназначенные для этого сайты.
Листок тоже заведомо ограничен, для меня удивительно что вам принципиально неудобнее писать на бумаге, чем на доске.
Характер движений разный. Доска – это движение «от плеча», в меньшей степени «от локтя». Буквы крупные, поэтому даже кистевые движения относительно размашисты. Примерно так же нагрузка распространяется при рисовании на бумаге, которую я очень охотно использую для этих целей.

А вот мелкий рукописный текст – это большое количество мелкоамплитудных движений и очень жёсткий контроль кисти. Мне с непривычки больно. И в отличие от навыка письма на доске, поддерживать мне эту привычку особо незачем.

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

самый главный недостаток бумаги (и достоинство доски): с доски


стереть можно на ходу что-то

Ну реально, опечатки (описки), изменения по алгоритму (когда понял, что можно написать лучше) и прочие мелкие улучшения… я на бумаге это не смогу!.. Ну а если вы потребуете всё-таки писать на бумаге — то вы ССЗБ. Писать нормальным почерком я не умею (хоть и читабельно, но к нему привыкнуть надо), а вот обидеться на неадекватную постановку задачи и написать кеглем 1.5-2мм — вполне осилю. Вероятность адекватной постановки задачи на бумаге я допускаю, но считаю её чрезвычайно маленькой.

UFO landed and left these words here
нравиться

Иногда просьба написать что-то на бумажке показывает и уровень осмысленности работодателя.
Коду и компилятору вообще глубоко фиолетово как он написан, он в любом случае отработает так как сказано. Другое дело люди — вот им важно в коде не запутаться и иметь возможность легко поддерживать, поэтому есть какие-то требования к коду и без их озвучивания вопрос «что не так в коде» просто не имеет смысла(за исключением очевидных опечаток) — компилятору всё равно что не так в коде.
UFO landed and left these words here
UFO landed and left these words here
Из всего в глаза бросились SQL-запросы… особенно если это веб-приложение, становится как-то стрёмно. И пароль к базе прямо в коде захардкожен…
И SQL injection, и строки в HTML не ескейпятся, и клевый способ проверки на наличие прав админа. Да и вообще на наличие прав.
UFO landed and left these words here
UFO landed and left these words here
самое интересное начинается

когда выясняется, что работодатель родного языка не знает даже на уровне младших классов школы, и освоить разметку на хабре не в состоянии…
UFO landed and left these words here

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

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

В реальной жизни код пишется кусочками, в процессе периодически проверяется его работоспособность.
Реальная жизнь обширна и разнообразна. Некоторые проекты позволяют не думать и после каждой строки компилировать и запускать программу для проверки. А в некоторых случаях код, который вчера компилировался две минуты, сегодня компилируется 10, и из-за глупой ошибки терять 20 минут очень печально. Не говоря уже о том, что после завтра вы можете попасть в ситуацию, когда дебаггер вам недоступен вовсе, и есть только код, логи и ничего более.
после завтра вы можете попасть в ситуацию, когда дебаггер вам недоступен вовсе, и есть только код, логи и ничего более
У меня это каждый день :) Иногда пишешь код и коммитишь без возможности проверить и запустить — реальная жизнь обширна и разнообразна :)
У меня не каждый день, но это вполне сценарий разбора крешлога, который не могут воспроизвести тестеры. Рутина.
Иногда пишешь код и коммитишь без возможности проверить и запустить — реальная жизнь обширна и разнообразна :)
Тогда вы НЕ МОЖЕТЕ быть уверены в том, что ваш код корректен. Я серьёзно. Обратная связь бесценна. Дробите ваши монолиты, от которых IDE виснет на полчаса, настраивайте распределённую сборку (где-то тут видел статью), но обеспечьте хотя бы проверку на синтаксис, сиречь компиляцию.
Ну то, что ты здесь и сейчас не можешь запустить свой код, не значит, что ты не можешь получить обратную связь. У меня как-то коллега писал приложения для не вышедшей версии Tizen на засекреченном телефоне. Причем телефон физически находился у Самсунга в Корее. Ни телефон, ни эмулятор предоставить не могли (был эмулятор для предыдущей версии).

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

Зря так на ad1Dima накинулись — скилл писать без дебаггинга действительно порой востребован. Например, у меня были случаи, когда нужно было через цепочку RDP+TeamViewer+SSH на проде внести мелкие правки при помощи vim. Другой вопрос, что если это не единичный случай, а система, то бегите из компании со всех ног.


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


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

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

Не поймите меня неправильно. Ситуации бывают разные, согласен. Изначально речь шла о написании алгоритмов, а не про «в интерфейсе было firstName, добавить ещё и lastName», например. В этом ключе я и рассуждаю. Реализовав какой-нибудь алгоритм посложнее пузырька, нужно как-то убедиться, что он работает.

Вообще, призываю сторонников чёткого ТЗ. Они объяснят, что все ваши задачи, интерфейсы, сигнатуры и операции с чёрным ящиком должны быть специфицированы, а если написано «на вход пришло А и Б — выдать В и Г», то должно быть так и никак иначе.

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

Этим страдают не только крупные банки. Но и мелкие конторы… хоть исходники и есть, но ощущение черного ящика всё ещё не отпускает.
Спасибо, кэп. Я написал это не как инструкцию для организации работы программистов, а пример того, как это бывает в реальной жизни.
Спасибо, кэп.
Всегда пожалуйста.
Я написал это не как инструкцию для организации работы программистов, а пример того, как это бывает в реальной жизни.
Да, мир не идеален. И всем, кто говорит про «реальную жизнь», у меня к вам огромная просьба. Давайте вы будете в своих вакансиях сразу писать (убеждать ваших тимлидов и HR-ов писать) про эту нелёгкую жизнь в ваших компаниях, как у вас всё бывает порой печально IRL. Это было бы очень здорово.
Да и так программистов по полгода ищут, а если честно всё написать, то кто работать будет? :)
Тут я с вами частично согласен. Но данный подход применим к программистам уровня Senior+ или Guru. И если уж вы дали такое задание, вы должны четко понимать для чего вам это нужно. Так же неплохо было бы дать это понять и соискателю.
В большинстве же случаев, в этом нет необходимости. Иной раз доходит до смешного. Одному моему другу, Java разработчику, дали бумажное задание на Паскале! Что еще более забавно, через месяц, когда он уже нашел себе работу, ему позвонили и сказали, что он прошел на второй тур.
Даже джуниор должен уметь писать на бумажке. Не важно на каком языке, главное чтоб интервьюируемый и интервьюер друг друга поняли. И чтоб не придирались к синтаксису.

Суть моего коммента в общем-то в том, что само по себе написание кода на бумажке/без IDE — важный программистский навык нужный в реальном кодинге. И, такие вот «антипаттерны» являются сами по себе антипаттерном: начинающие разработчики читают и думают, что это бесполезный навык.
Тогда уже не писать код, а проектировать приложение. Нарисовать блок-схему или диаграмму последовательности действий. Или, к примеру, структуру БД. Писать код на бумажке — самое бесполезное занятие для разработчика. В школе писал так олимпиаду по программированию — это был ужас.

Вообще, важно чтобы работодатели были адекватными. В идеале вопросы должны быть не теоретическими и с целью завалить собеседуемого, а нацеленными на конкретную должность, технологии, используемые в настоящий момент в компании (+ те что в планах). Хорошо спросить о предыдущих проектах — какой опыт получил, какие были проблемы, как решал.
А когда начинают давать тестовые задания на 4 часа работы или грузить теорией, которая не будет никак использоваться в работе, то это плохо и для соискателя и для работодателя.
Проектировать приложение это другой уровень. И меня вполне спрашивали такое.
А чем написание кода на бумажке отличается от написания в IDE?
Если условились не придираться к синтаксису, то и разницы нет никакой получается. Что на бумаге пишем логику на псевдоязыке, что в компьютерной программе пишем эту же логику, но только с подсказками от компьютера по синтаксису (который мы в расчет не берем и так)
UFO landed and left these words here
но написание кода — итеративный процесс
И написание кода без IDE как раз хорошо показывает, насколько вы можете думать на несколько шагов вперед.
Именно поэтому, когда меня на собеседовании попросили написать код на бумажке я начал имитировать работу IDE прямо на этой бумажке. Я писал длинные и понятные названия классов и переменных, но в местах где их использовал не дописывал их названия до конца, рисуя стрелку к месту объявления и подписывая к ней слово «автокомплит». Части кода я писал на самоклейках и клеил их к месту на котором писал Ctrl+V. Кончились мои интервьюеры когда я переписал на отдельный листок часть кода, свернул лист так, что скрыл её и попросил кусочек скотча для операции Ctrl+X-Ctrl+V. А ещё я подчёркивал места где пропускал приведения типов волнистой линией, жаль красной ручки не было.
А если нет разницы, то почему все так против? может потому, что разница есть? Выше я написал, что текстовый редактор типа Блокнот тоже подойдет.

Нет разницы в плане проверки умения программировать (что является целью), есть разница в плане удобства использования (что является средством).

Все же на бумажке и «без IDE» — довольно разные варианты. Непонятно, чем именно бумажка лучше простого редактора с подсветкой. Да и непонятно, чем IDE помешает, кроме того, что плохо подходит для маленьких задачек. Неужто автокомплит помешает проявить навыки? Если принципиально знание конкретных методов, то проще их и спросить (хотя это тоже антипаттерн имхо).
Хороший программист должен уметь писать код на листочке!
О5 25. Холивар «IDE vs листочек», наверно, даст фору табам против пробелов. Впору опрос проводить, сколько программистов умеют писать код на листочке, и как это умение коррелирует с профессионализмом.
такой опрос не поможет, потому что многие, кто умеют. давно уже не пробовали.
Очень даже поможет. Я бы предположил, что многие вообще никогда не пробовали либо пробовали неудачно, многие даже не считают этот навык достойным умения, а те, кто когда-то умели, но давно не пробовали, уж верно смогут сказать, по-прежнему они умеют или уже разучились.
что многие вообще никогда не пробовали либо пробовали неудачно
и при этом умеют
и при этом умеют
Чудеса, да и только. Я вот никогда не пробовал рубить деревья, а вдруг окажется, что я это умею, мало того, заткну за пояс лучших лесорубов. Надо как-нибудь попробовать.
Все очень просто, я в таком задании вижу набор конкретных умений:
  1. Умение решить простую задачу
  2. Умение составить алгоритм
  3. Умение выразить этот алгоритм в (псевдо)коде.
  4. Умение мыслить на несколько итераций вперед
  5. Умение без помощи спецсредств просчитывать граничные условия
  6. Умение дебажить без помощи спецсредств

Первые 4 пункта — навыки которые можно получить в школе (по крайней мере в программе старшей школы они есть уже 20-25 лет).
5й и 6й — уровень техникума для программистов.
Если человек имеет эти навыки, то написать код на бумажке не составит никакого труда. Так вот, скажите мне, какой из этих навыков программисту не нужен?
Писание кода на бумажке, как таковое, показывает, умеет-ли человек писать код на бумажке. В реальной жизни навык полезен, чтобы быстро объяснить коллеге принцип решения. IDE дольше загружать и мучаться с непривычными шоткатами на чужой машинке. Но, да, занятие специфическое. Особенно когда бумажки — салфетки.

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

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

  1. Задача решается в IDE гораздо наглядней. Код написан, скомпилировался, корректно отработал и выдал верный результат на тестовых данных — задача решена.
  2. Чтобы написать код в IDE, как раз и надо сперва знать или составить алгоритм. Автокомплит для алгоритмов пока не придумали.
  3. Так в псевдо- или в коде? Если в коде, не вижу причин не использовать IDE.
  4. О каких итерациях идёт речь, алгоритма или написания алгоритма? Если написания алгоритма, то это совершенно ненужное умение, т.к. в IDE всегда можно что-то поправить, прежде чем показать код интервьюеру или отправить в продакшн либо ещё куда.
  5. А какие спецсредства здесь могут что-то подсказать? Разве есть такие?
  6. Зачем? Зачем дебажить без отладчика? Можно и шуруп вкручивать без помощи отвёртки, например плоскогубцами, навык закручивания шурупа это никак не показывает. Ясен пень, если человек умеет дебажить, то он догадывается, что операторы и функции выполняются не в рандомном порядке.
1) расскажите это олимпиадникам, ага.
2) МС как-то демонстрировал возможность Roslin с помощью экстеншена, который втраивал код из ответов SO в проект.
3)…
4) Удачи с дебагингом по невоспроизводимым шагам
5) Да, статический анализатор кода называются
6) Выше есть несколько примеров Все так привыкли к дебаггеру, что даже не представляют что его может и не быть по разным причинам.
Хорошо, допустим, вы собеседуете кандидата. Отрубите интернет, раз вы сами взяли вашу задачу оттуда и не хотите, чтоб соискатель нагуглил решение. Или чтобы не спросил на SO, хотя я сомневаюсь, что он успеет получить ответ. Предоставьте ему просто IDE, без статических анализаторов. И озвучьте запрет на дебаггинг (хотя я бы при этом мысленно покрутил пальцем у виска). Так и скажите грозным голосом: «Вам запрещается запускать и отлаживать своё решение!» Ну и следите, как он кодит ваши пузырьки или фибоначчи, да пусть даже ханойские башни. Вот чем, скажите, в такой ситуации бумажка выиграет у IDE?
Вы предлагаете убрать IDE из IDE и сравнить его с бумажкой/Notepad'ом?
Я пытаюсь понять, почему вы считаете, что выполнение задания на бумажке покажет уровень кандидата лучше, нежели в IDE. Если цель — максимально усложнить ему жизнь, можно вот так ещё делать:
тестовое задание джуниору на бумажке

Ну а что, мало ли какие бывают ситуации в реальной жизни, вдруг придётся писать код там, где нет стульев. Я считаю, что это очень важный навык для программиста. Вот у нас среди клиентов есть очень большой и крупный международный банк, так представляете, у них мебели не хватает, компьютеры на полу стоят. Что бы делали разработчики, привыкшие писать код, сидя в комфортном кресле? А так пришёл, быстренько интегрировал ПО или что-то поправил, стоя на корточках, и готово. Естественно, настоящий профессионал сумеет писать код и стоя. Если на собеседовании человек даже не может этого сделать, то с ним не о чем разговаривать. Все так привыкли к стулу, что даже не представляют что его может и не быть по разным причинам.
Можно и ножом винты откручивать, ага. Вот только это относится скорей к экстремальным условиям и должно соответствующе оплачиваться, но почему-то работодатели не хотят…

Причём дебаггинг по невоспроизводимым шагам к наличию текстового редактора и REPL на машине, в которых можно чуть эффективнее обращаться с текстом и быстро проверять гипотезы соответственно?

Вопрос в том сможете ли вы это все оценить, если человек давно не писал ручкой? Или вы таких сразу отсеиваете? Например у меня тупо начинает болеть рука после 10-12 строчек и разобрать простой текст уже становится сложно.
И еще раз скажу, что что 1) больше 10-20 строк и не надо. 2) под «писать на листочке» в моем понимании Notepad тоже попадает.

Ну и просто пожелание: мелкая моторика полезна для мозга.
Я уже видел, что вас уговорили на Notepad) Ну а для развития мозга у нас с вами есть более интересные темы, обсудить чем например интерфейс отличается от абстрактного класса)

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

Ну и просто замечание: Кстати печать на клаве двумя руками разве не эта самая моторика?
Я уже видел, что вас уговорили на Notepad)
Никто меня не уговаривал. Просто в моей голове, что на листочке, что в редакторе типа блокнот отличаются лишь умением человека пользоваться ручкой, не более того.

Кстати печать на клаве двумя руками разве не эта самая моторика?
ваши болящие руки и есть ответ на этот вопрос.
Не знаю, как отвечают на этот вопрос руки Alesh, но мои утверждают, что с мелкой моторикой у них всё в порядке. И приводят в качестве доказательств показания свидетелей, которые зовут меня каждый раз, когда надо что-то очень точно отрезать, провести особо ровную линию, попасть чем-то куда-то или собрать / разобрать какой-то особо мелкий механизм.

Рукописный текст – это нагрузка крайне однообразная, значительная по силе и довольно длительная. Это упражнение на выносливость, не более. Если есть такие-то травмы, связанные, например, с длительной работой с мышкой, проблема может усугубляться.
ваши болящие руки и есть ответ на этот вопрос

Можете шире выразить свою мысль, я вас не понял.

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


Кроме того, если я исповедую TDD (которое type-driven development), и серьёзно полагаюсь на тайпчекер в процессе написания кода и иногда даже продумывания алгоритмов (если инварианты или что-то этакое удаётся выделить в виде типов), то на бумажке мне будет очень больно.


Кстати, ещё можно просить в процессе написания кода танцевать (проверяет многозадачность и координацию движений) или декламировать Бородино (проверяет, опять же, многозадачность и память).

Кроме того, если я исповедую TDD (которое type-driven development), и серьёзно полагаюсь на тайпчекер в процессе написания кода и иногда даже продумывания алгоритмов (если инварианты или что-то этакое удаётся выделить в виде типов), то на бумажке мне будет очень больно.
Ну вы можете обход дерева или массива делать через TDD, если так сильно хочется. Написать десяток тестов, классы нагенерировать для алгоритма на 10 строк… Все во имя того, что вы исповедуете.

Ну вот, я же даже в скобочках специально расшифровку написал, а вы её не прочитали :(

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

Есть рынок, за порогом ведь всегда толпа желающих, которые любят и умеют в бумажки, лично знакомы со всеми паттернами и антипаттернами, выучили ответы на все тупые задачки с нечёткими условиями, запомнили 150 отличий абстрактного класса от интерфейса, на короткой ноге с большим О, могут без смеха обосновать почему они хотят работать именно здесь, не против ненормированного дня и серой зарплаты; всегда найдется подходящий кандидат, который сумеет классическим образом заехать на данную конкретную карго-хату.
Я знаю пару компаний, гда даже кодить уметь не надо, чтоб программистом работать.
Это идеально. Когда система родилась в виде идеи, архитектуры и набора технологий, изложить это на машинно-понятном языке — сущая рутина и при должном навыке легко измеряется в человеко-часах среднего квадратно-гнездового кодера.
Просто меняют иконки и засирают стор, а не то, что вы подумали.

Хех, на первом месте, куда я устроился программистом семнадцать лет назад, мне обещали, что если хорошо буду работать, дадут компьютер. Через два месяца дали. Как раз к моменту, когда все работники из отпусков вышли, а вы что подумали? Кстати, на собеседовании, делая тестовое задание, первый раз притронулся с Visual Basic (задание сдал успешно). Так что безвыходных ситуаций не бывает. Будет надо — и ручкой напишу, но предупрежу, что код не скомпилируется и предложу интервьюеру исправить ошибки так, чтобы скомпилировалось с певого раза. Ручкой, без IDE. Торгуйтесь, господа соискатели, многое зависит именно от вас!

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

Но неделю назад проходил собеседование, меня попросили написать код на бумажке, и я просто взял бумажку и начал писать. Я тогда вообще не задумывался о том, что здесь какой-то особый навык нужен, которого у меня нет.
Автодополнение…
Я например в упор не помню chain-функции для работы со строками.
IDE как раз дает мне подсказку, и я выбираю ту функцию которая мне нужна.
Ну не помнишь и не помнишь, сказал об этом, назвал её как вспомнил, обозначил она делает, и дальше пошёл.
Ну как сказать… Могут ведь и прикопаться :-)
Ну фигово тогда. Я бы не стал в такой конторе работать.
Я на том собеседовании, о котором писал выше, забыл две вещи: 1). порядок аргументов в одной функции и 2). какой оператор используется в питоне для побитового XOR.
Просто сказал об этом собеседующему, никто не стал прикапываться, просто подсказали и я продолжил писать код.

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

С знанием библиотек на память согласен, но не владеть синтаксисом языка на котором пишешь это большой красный флаг.
Все время от времени забывают ';', мало практической пользы помнить порядок в `public static partial override async void MegaFinction()`. Помнить все перегрузки ToString() тоже не критично.

Я говорю именно про придирки, особенно про придирки к опечаткам
Что даст вам например на собеседовании написанный мною код на листочке, если у меня почерк как у курицы лапой? Вы просто не разберете что я написал, а если мне надо будет исправить что-то в коде, то как? Будете ждать пока я все перепишу на чистовую? А если опять исправить?) Не мучайте людей и себя, давайте им хотя бы обычный текстовый редактор.
Вы невнимательно читаете мои комментарии. Я подробно расписал, что я подразумеваю под писанием на листочке.

Можно оставлять по 10 пустых строк между строками кода (не зря ж в бейсике в своё время было принято нумеровать метки через десятки) и надеяться, что у интервьювера достаточно бумаги.

Для этого надо думать на несколько шагов вперед. Сами же пишете, что это ненужно программисту.

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

Я добавлю:
— звоните соискателю, обещайте золотые горы и пропадайте. Вообще. Капитально. Соискатель сам напишет если вдруг что — у вас есть дела и по-важнее
— ни в коем случае не смотрите на github и прочую опенсорсную активность кандидата. А если вы и уделяете этому внимание — то контрольными вопросами должно быть «сколько человек пользуется вашей поделкой?» и «как часто вы выпускаете новые релизы и общаетесь с коммьюнити?». Что ж это за соискатель такой, что даже не может раскрутить свой проект водиночку. Вам же нужен разработчик с навыками маркетолога, ведь правда?
— не доверяйте соискателю. Вообще. Он — грязное и хитрое создание, которое пришло похитить у вас деньги. Поэтому лучше вообще не говорите ему чем занимаетесь до подписания NDA, которое лучше заставить подписать прямо с порога. Помните что соискатель абсолютно ничего не понимает ни в своей профессии, ни в вашей системе, поэтому любые его предложения относительно, например, архитектуры систем надо рассматривать свысока, цокая языком, а еще лучше — обсмеивая.
— выше уже было про рассылку писем-автоответов. Я хотел бы добавить изюминку: обязательно дописывайте в конце, что по всем возникшим вопросам соискатель может не стесняться писать или звонить вам. Укажите что вы всегда готовы ответить на все вопросы. Желательно дать несуществующий e-mail и неактивный номер телефона.
— отличным ходом является дать соискателю ссылку на автоматический входной тест знаний. Сделайте его в самой убогой системе тестирования — в Moodle например. К вопросам особых требований нет. Спросите про его настрой, психологический профиль, дайте задачку на решение уравнений, накидайте вопросов по сетевым технологиям и программированию. Само собой, тест по времени стоит ограничить — ибо нефиг. Соискателей, отсеенных по результатам автоматического тестирования сразу добавляйте в бан-лист и больше никогда не рассматривайте. Автоматизация-с! И да! Ни в коем случае не предупреждайте соискателя о тесте и не предоставляйте подробностей о вопросах. Интригу надо сохранить, а хороший соискатель должен быть всегда ко всему готов. Как пионер. Больше чем пионер.

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

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

Трапы с сиськами (и членом), что тоже встречаются?

Ещё пара советов:


  • после неудачного собеседования никогда не сообщайте о результатах, во-первых это требует очень много времени, а во-вторых кандидат может обидеться;
  • в письме потенциальному кандидату можно назадавать кучу вопросов и даже попросить рекомендовать кого-нибудь, но если в конце написать "Заранее спасибо", то тогда можно уже не тратить время на ответ потратившему время бедолаге;
  • рассказав о проекте, попросите кандидата пересказать услышанное, задайте ещё пару вопросов, чтобы точно убедиться что он внимательно вас слушал;
  • ну и наконец, если кандидат не соглашается принять ваше предложение, начинайте рассказывать, что ситуация на рынке сложная и работу найти не просто или что у вас есть другие уже согласившееся на это место кандидаты — пусть испугается и согласится!
после неудачного собеседования никогда не сообщайте о результатах

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

… ну или ограничьтесь шаблонной и унизительной формулировкой вроде «наши руководители проектов сочли ваш уровень квалификации недостаточным» (особенно эффективно работает если соискатель окажется бородатым сениором с 15-летним стажем и текущим окладом выше чем зарплата рекрутера за полжизни). Это очень позитивно повлияет на имидж компании — наверняка после такого соискатель порекомендует вашу компанию друзьям. Никогда не признавайтесь что не смотрели резюме, или было лень, или планы поменялись, или вам просто не понравился соискатель. Оставайтесь окутанными пеленой тайны.
еще нужно обязательно дать несколько строк кода на листочке в черном белом варианте, распечатанном не моноширинным шрифтом, и сидеть удивляться как соискатель ищет ошибки в этой ереси, за написание которой, можно сразу увольнять
Да да да! Еще важный совет. Надо давать больше заданий а-ля «что выведет на экран этот код?». Недостижимый идеал здесь — дать код, запускающий несколько потоков с подозрением на мертвую блокировку, но по факту содержащий синтаксическую ошибку (не компилирующийся). Ведь вы нанимаете не программиста, вам нужен профессиональный решатель ребусов. Здесь профессионалы порекомендуют дать соискателю поразгадывать кроссворд, но пока что эти технологии никем не освоены — станьте первым!
если соискатель не способен прочитать код на листочке без IDE, по тратить время на ленивого балбеса не имеет смысла
балбес это ты и твои соратники,
есть такое понятие, как уважение, «балбес» тоже к этому относится, так вот, если хочешь показать свою какаху будущему работнику, которая ничего общего не имеет с реальным миром, то уж хотя бы распечатай ее в моноширинном шрифте, а-ля Consolas. А если твоя какаха, это реальный код из реального проекта, то говори об этом сразу, чтобы можно было развернуть и уйти, не теряя свое время. Программисты не пишут код в блокноте Windows с использованием Times New Roman. Речь больше об этом, а не об умении читать что там на листочке.