Join Yalantis and get a $1000 sign-in bonus! React.js, React Native, Python, Java, DevOps, BА. Apply now!
×Закрыть

Как попасть на работу в среднюю или крупную компанию

У меня 2 года опыта, за все это время я работал в одной компании, которая довольно маленькая (2 программиста и опыта больше у меня). Хочу увидеть и попробовать как оно работать в большом колективе.

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

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

Так вот, раз я уже работаю 2 года, могу сам написать модуль к системе с которой работает компания(Zend framework + Doctrine + DI и разные мелкие фишки)... неужели я не смогу понять почему вываливается ошыбка или начать использовать новую библотеку?

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn

Лучшие комментарии пропустить

Такие вопросы задают, чтобы понять, понимает ли человек осовные принципы ООП и особенности реализации ООП в конкретном языке программирования. Предполагается, что кандидат четко себе представляет, что есть абстрактный класс (и чем он отличается от обычного), и что есть интерфейс.

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

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
о том вывалится ли ошыбка если абстрактный клас унаследовать от интерфейса и в класе не описать функцию интрефейса

Прошу прощения, но как этого можно не знать с 2 годами опыта работы? Это ведь элементарные вещи, а не

какие то странные вопроси

Что обосновать? Если человек использует, например Java, на протяжении 2 лет(как я понимаю, использует в коммерческой разработке) и при этом не знает

о том вывалится ли ошыбка если абстрактный клас унаследовать от интерфейса и в класе не описать функцию интрефейса
?Я правильно понимаю, уважаемый?

Ключевое слово абстрактный. Я б интервьюверов за такие вопросы банил бы пожизнено. Пролистай ветку пониже, м.б. поймешь.

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

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

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

Если человек использует, например Java, на протяжении 2 лет(как я понимаю, использует в коммерческой разработке)

Прочесть внимательно не?

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

А может легче понять/изучить ООП, а не кидатся г*вном в интервьюверов

Очередной пост, отдаленный от конкретики типа «кодерку не понять».
Для вас, RUDOLF и остальных «сеньеров» . Почему в первом случае в классе Abstract2 не обязательно описывать метод DoIt
abstract class Abstract1
{
public abstract void DoIt();
}
abstract class Abstract2 : Abstract1
{
}

А в этом случае надо:

interface Interface1
{
void DoIt();
}
abstract class Abstract1 : Interface1
{
public abstract void DoIt(); //иначе вылезет ошибка, компилятор не может вывести этот член сам
}

Мое мнение — разрабы компилятора C# просто поленились (или не захотели по каким то причинам, но не по причине невозможности) обработать этот частный случай, просто оставив общее поведение в реализации интерфейсой всеми классами.

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

Пролистай спецификацию и попробуй включить здравый смысл
А может легче понять/изучить ООП
как этого можно не знать с 2 годами опыта работы?
Кодерку, для которого реализация интерфейса через абстрактный класс диковинка, не понять

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

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

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

а в чем преимущество? почему тогда не надо в каждом классе-наследнике заново переобъявлять все абстрактные члены, пока не будут реализованы? шли бы уже до конца: «либо явно объявлять абстрактными, либо реализовывать».

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

та ну. появится — там где надо. где будет реализация.
мы говорим: «объекты этого класса могут выступать в роли генератора списка», имея в виду интерфейс Iterable. И нам пофиг на нюанс, что для этого надо реализовать где-то методы reset, next, current и total. Главное, что объект этого класса можно будет передавать в for и вызывать на нем count. А на каком уровне классовой иерархии появляется реализация — безразлично. Пока она появляется. Нет реализации — есть ошибка. Делов-то.
оперируя вашим же призывом: надо работать с выражением процессов и объектов, а не с категориями языка.
P.S. а вообще, как-то непонятно. Судя по подписи, должны бы знать, что в РНР как раз не обязательно в абстрактном классе явно декларировать методы, описанные в интерфейсе.

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

А насчет PHP... мы тут как бы C# обсуждаем. Честно говоря мне C# намного больше нравится чем PHP и Java, но увы его нет на линукс (Mono не рассматриваю).
Кстати в PHP я следую тому же правилу хоть оно и не обязательно.
и где-то в результате такого подхода проект становится сложным в поддержке.
С чего? Все описано в интерфейсе. Реализовано в классах, которым это нужно. Клик с зажатым Ctrl в IDE переводит к реализации. Не, ну, если использовать блокнот, не имеющий представление о конструкциях языка и подсветки синтаксиса, то да.
мы тут как бы C# обсуждаем
угу, я заметил:
Если человек использует, например Java, на протяжении 2 лет
Вот пыхе не обязательно, и чо, умник? Пых придумали люди лишенные здравого смысла?
Мое мнение — разрабы компилятора C# просто поленились
С чего? Все описано в интерфейсе.
повторюсь, как уже говорил ниже.
Когда абстрактный класс реализует уже 2 или 3 интерфейса это крайне неудобно, даже имея кучу тулзов накруток в ИДЕ и я более чем уверен, что врядли есть конвенции, которые будут рекомендовать implicit реализацию интерфейсов, хотя мне конвенции пхп и не знакомы.
Это все равно, что везде пихать виртуальные публичные методы и говорить, а чего б и нет, конструкция языка-то позволяет.
повторюсь, как уже говорил ниже.
тогда и я повторюсь: если отойти от интерфейсов и взять просто абстрактный класс(можно — полностью абстрактный, до полного совпадения с концепцией интерфейса). И как, в каждом классе-наследнике мы будем снова и снова переобъявлять те абстрактные члены, которые в текущем классе не реализуются?
Это все равно, что везде пихать виртуальные публичные методы
не понял. а виртуальные публичные методы в чем виноваты? даешь статику? к черту полиморфизм?

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

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

да если метод астрактный, его надо реализовать в каждом наследнике
в каждом наследнике, который будет инстанцироваться — согласен. иначе ошибка.
а если абстрактный класс наследует абстрактный класс?
abstract class Base {
 public abstract void test();
}
abstract class MoreSpecificBase : Base {
 public abstract void test();
}
в чем смысл такого переобъявления?
кроме разделения программирования на структурное и обьектное, есть еще и принципы обьектного дизайна
а еще — синтаксис языка, лексические парсеры, багтикеты, ROI и депозитные вклады. при чем тут это?
UPD: привел код-пример в соответсвие с блоком выше. Чтоб не было повода для «в Java синактсис не такой, пример неправильный»

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

а еще — синтаксис языка, лексические парсеры, багтикеты, ROI и депозитные вклады. при чем тут это?
Да при том, что расширенная функциональность языка может не только нести пользу но и вред при разработке ис, поэтому предпочтительным в наше время остаеться хорошо продумманый расширяемый код, а не быстро решенная локальная задача.
Поэтому implicit реализация интерфейса, помоему мнению, а виртуальный публичные метод , общепризнано — плохая практика.
updated
implicit реализация интерфейсов на уровне абстрактного класса фича сомнительная
почему «отсутствие необходимости переобъявлять абстрактными» становится «неявной реализацием»? вот, если б каждый абстрактный член таки реализовывался неявно в виде метода с пустым телом — это да. А тут — неясно. В любом случае будет ошибка, если в конечном классе не реализовать метод. Так зачем копипастить сигнатуры?
Вы так аргументируете, как будто абстрактный класс и интерфейс абсолютно взаимозаменяемая штуковина с точки зрения логической уместности их применения.
Вообще-то, нет. Если, вдруг, не в курсе, абстрактный класс допускает реализацию в своих неабстрактных методах. А интерфейс — нет.
поэтому предпочтительным в наше время остаеться хорошо продумманый расширяемый код, а не быстро решенная локальная задача
эээ. давайте говорить очевидные банальности. это удобный аргумент. согласятся с одним — согласятся и с другим.
виртуальный публичные метод , общепризнано — плохая практика
не понимаю. можно, на примере? может, я не дорос до правильного определения виртуального метода?
Вы так аргументируете, как будто абстрактный класс и интерфейс абсолютно взаимозаменяемая штуковина с точки зрения логической уместности их применения.
Вообще-то, нет. Если, вдруг, не в курсе, абстрактный класс допускает реализацию в своих неабстрактных методах. А интерфейс — нет.
Есть у меня такое чувство, что:
Товарищи утверждаю что для бизнес-логики имеет значение является сущность интрефейсом или (абстрактным)классом (На мой взгляд это ошибка). То есть (на примере):
Здание — не может быть интерфейсом, а должно быть классом.
А вот Входбл (то куда можно войти) — может быть только интерфейсом и не может быть классом.
Поэтому если у вас у Здания есть метод войтиВнутрь и Дом (наследник) Здания абстрактный, то он должен __явно указывать что он соблюдает протокол родителя__.
А вот тот факт что Дом реализует интерфейс Входбл __уже должно указывать__ на то что Дом соблюдает протокол родителя.
.
Судя по тому что тут аж 2 таких мнения, они явно окуда-то это вычитали, от только не понятно откуда.
.
виртуальный публичные метод , общепризнано — плохая практика
не понимаю. можно, на примере? может, я не дорос до правильного определения виртуального метода?
От мне так же интересен пример.
Но не уверен что вы его получите, создатель Ц№ сказал что это плохо, а у дотНетчиков не принято прерикатсо с МСом :)
Так зачем копипастить сигнатуры?
что бы не искать потом элементы сущности по всему проекту.
не понимаю. можно, на примере? может, я не дорос до правильного определения виртуального метода?
www.spatial.com/...ethods-bad-idea

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

по ссылке толково написано.
я даже соглашусь с приведенным там примером про Save.
решение о разделении выглядит нормально. но без переключения «public→private» это была бы обычная декомпозиция — т.н. «шаблонный метод». И никакого придания анафеме свойства языка.
не нравится категоричность. это раз.
в случае с конструкторами, как раз, вынесение специфической инициализации только ради вынесения считаю зряшным плодением сущностей(особенно, как в примере — если мы доопределяем метод, а не меняем, то у нас в базовых классах будет просто проброс из публичного метода в приватный). забыть вызвать родительскую реализацию можно и в приватном методе. это два.

зачем так много сарказма? неужели здесь действительно кого-то волнует, насколько вы уверенны в своей квалификации? в конце концов, не для посмеяться вы же пишите все эти раз-два-три)
зы: меня действительно «ругали» за таких штуки в коде.

зачем так много сарказма?
хм. раз одна последняя строка мешает читать остальное, я её удалил.
И никакого придания анафеме свойства языка.
не нравится категоричность.
ну принципы дизайна приложения не категоричные, можно им не следовать, никто не заставляет, целые нации умудряются их успешно игнорить. :) но это не отменяет их общепризнанною ’предпочительность’.
забыть вызвать родительскую реализацию можно и в приватном методе.
в рассматриваемом примере как раз таки эта ситуация исключается. там вызывается публичный метод, а тот уже дергает виртуальный враппер, что наследуется.
в рассматриваемом примере как раз таки эта ситуация исключается
угу. не досмотрел :(
А насчет PHP... мы тут как бы C# обсуждаем
А еще пару постов назад вы пытались «мыслить абстрактно» ( dou.ua/...ic/8518/#381348 ) :)
Поведение описанное в dou.ua/...ic/8518/#381338 больше __похоже__ на баг, возможно связанный с (не)виртуальными методами.
Во втором варианте мы говорим что со следующим объектом мы должны иметь определенный способ работы. И если он присущ роду то нам стоит явно указать что какойто определенный метод должен быть определен у вида, хотя он присущ роду.
От интересно, вы это в какой-то книге вычитали или сами придумали? Если в книге, то дайте ссылку почитать.
Я как бы не сталкивался с такой «школой ООП», обычно достаточно было понятия протокола/интерфейса.
А еще пару постов назад вы пытались «мыслить абстрактно»
каюсь :)
От интересно, вы это в какой-то книге вычитали или сами придумали?
второй вариант. долго думал об идеологической составляющей программирования и того как она влияет на результат моей работы, вот примерно до такого мнения и дошел.
долго думал об идеологической составляющей программирования и того как она влияет на результат моей работы, вот примерно до такого мнения и дошел.
Излишне долго. В реальности все намного проще :)
Есть сообщения, есть протокол, надо (чаще всего) прятать данные за протокол (бо без этого неудобно получается) — это и есть вся философия. Все остальное придумали хитрые раввины от программирования шоб зашибать бабло.

Не имею ничего против отсутсвия этой «фичи» в C# и присутствия в PHP, я лишь против вопросов на собеседованиях, не имеющих однозначных ответов.

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

Дело в том, что к сожалению мой ответ «не уверен, по идее да, а может и нет» врядли трактовался бы положительно, скорее трактовался бы так:

как этого можно не знать с 2 годами опыта работы? Это ведь элементарные вещи
Дело в том, что к сожалению мой ответ «не уверен, по идее да, а может и нет» врядли трактовался бы положительно, скорее трактовался бы так:
Тут многое зависит от собеседующего. Если в его глазах собеседование == тестирование, то, боюсь, тут Вы правы с трактовкой.
С другой стороны, не стоит обобщать так уж категорично. Некоторые вопросы специально могут задаваться с целью проверить, будет ли кандидат пытаться «угадать» или честно скажет, что не знает ответа. А вот это «не знаю» даст возможность расширить вводную ситуационным примером, где подобное знание применимо, и предложить поразмышлять... Лучше всего ход мыслей проявляется когда кандидат не знает правильного ответа, но в ситуационных примерах, пользуясь другими знаниями может аргументировать, что «скорее всего правильный ответ дожен быть таким-то, потому что...»

Если б все интервьюверы были б такими как вы говорите, я был бы очень рад.

Вы путаете собеседование с тестированием или экзаменом.
К сожалению, не он один путает: dou.ua/...ic/8518/#381382
Вопросы из серии «пазлы» это очень интересный инструмент, от только многие таки ожидают на них «правильного ответа», а не «ход мыслей». И это очень печально.

Если для вас вопрос "

о том вывалится ли ошыбка если абстрактный клас унаследовать от интерфейса и в класе не описать функцию интрефейса
" это вопрос на который нужно услышать ход мыслей, то мне вас и вашего работодалея искрене жалко. Ибо элементарные вещи.
Ход мыслей нужно ожидать, на то как человек может решить какую то задачу или предложить вариант решения. Но ни как не на базовые вещи.
Собеседование должно состоять как из вопросов на которые человек должно ответить однозначно, так и из задач, которыми можно посмотреть может ли человек размышлять и предлогать варианты решения.
о том вывалится ли ошыбка если абстрактный клас унаследовать от интерфейса и в класе не описать функцию интрефейса
Пост на который вы отвечали
dou.ua/...ic/8518/#381233
не содержит указанной цитаты.
то мне вас и вашего работодалея искрене жалко.
А мне вас нет, ваше неумение держать контекст в голове — это не моя проблема, а люкс за вас в любом случае получает процент :)
Но ни как не на базовые вещи.
Базовые вещи — это всякие общие алгоритмы, структуры данных, концепции программирования. А не знание того когда компилятор вываливает ошибку. Поведение которое будет в случае из вашей цитаты я знаю только потому что сталкивался с таким (это довольно простой случай с ним наверное все сталкивались), но это не делает эти знания базовыми. «Базовые вещи» и «простые случаи» — это разное.
А тот пример на который вы отвечали:
В случае с конструктором final почему-то не разрешен.
Это них не базовая вещь, а как раз «пазл». И тут как раз куда важнее ход мыслей чем знание спеки или правильного ответа.

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

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

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

Как коррелируется отличное знание спецификации с неумением абстрактно мыслить? Чёт снова Остапа понесло.

Ничего, возможно на следующем интервью обоснуете своё мнение «синьеру» — идиоту и тогда надеюсь Вам пояснят, что есть

верх идиотизма
. Хотя судя по рьяным доводам Вы уже столкнулись с поддобным и Вас успешно сбрили.
Как коррелируется отличное знание спецификации с неумением абстрактно мыслить? Чёт снова Остапа понесло.
 2 е качество каднидата на собеседовании должно цениться намного больше первого, поэтому должны быть подобраны соответствующие вопросы.
Хотя судя по рьяным доводам Вы уже столкнулись с поддобным и Вас успешно сбрили
Последний раз 2 года назад бывало, попросили все виды сортировок расписать. Еще разок было: спросили за ASP.Net темы, мой ответ (как сторонника MVC) — типа я этим г*вном не пользуюсь с обоснованием почему, не очень их впечатлил))
А так недавно друг собеседовался, у меня уши вяли от тех вопросов что ему задавали сеньеры с зп до 4к...

В абстрактном классе не обязательно реализовывать метод интерфейса

O my god!!! Не может быть, а мы то думали, что обязательно:-) Ну а если серьёзно — то это элементарные вещи, которые должен знать любой человек, считающий себя разработчиком(в данном контексте — Java разработчиком).

в данном контексте — Java разработчиком
Zend framework + Doctrine + DI и разные мелкие фишки
Какая-то странная Java, чесслово

Пшп копировало ООП с джавы, так что там тоже скорей всего так

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

Так вот, в вашем посте два вопроса — один в теме, второй в последнем предложении.
1) Как попасть на работу в компанию — очень просто, надо сперва самостоятельно оценить, насколько ваш текущий опыт релевантен той вакансии, на которую вы претендуете, затем надо подготовиться к интервью — ознакомиться с технологиями, и что очень важно, но часто новички не делают -
Совет 1: ПОЗВОНИТЕ РЕКРУТЕРАМ И ПООБЩАЙТЕСЬ С НИМИ!!! РАССПРОСИТЕ, О ЧЕМ ВАС БУДУТ СПРАШИВАТЬ НА ИНТЕРВЬЮ!
Это часто помогает.

2)

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

Совет 2: НЕ СТЕСНЯЙТЕСЬ В ХОДЕ ТЕХНИЧЕК ЗАПРАШИВАТЬ БЫСТРЫЕ ОЦЕНКИ ОТ ОЦЕНИВАЮЩИХ ЭКСПЕРТОВ
Сам факт что вы признаете собственные ошибки, быстро анализируете ошибки, а не прячете свои недостатки, поможет избежать ошибок тим лидов в эстимации тасков, а значит это всегда плюс на собеседовании.

Совет 3. ЕСЛИ ВЫ ПОЛУЧИЛИ ОТКАЗ, НО ХОТИТЕ ВСЕ ЖЕ ПОПАСТЬ В КОМПАНИЮ — НЕ СДАВАЙТЕСЬ СРАЗУ. СПРОСИТЕ, ЧТО ВАМ НАДО ПОДКАЧАТЬ И КОГДА МОЖНО БУДЕТ ПРИЙТИ ПОВТОРНО.

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

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

Совет 1: ПОЗВОНИТЕ РЕКРУТЕРАМ И ПООБЩАЙТЕСЬ С НИМИ!!! РАССПРОСИТЕ, О ЧЕМ ВАС БУДУТ СПРАШИВАТЬ НА ИНТЕРВЬЮ!
а я наивно полагаюсь на описание вакансии
Я самоучка, и пользуюсь тем что знаю, также по немногу стараюсь узнать новое, но практически всегда попадаются какие то странные вопроси о каких-то библиотеках, о том вывалится ли ошыбка если абстрактный клас унаследовать от интерфейса и в класе не описать функцию интрефейса.. и т д...
Этот вопрос вполне нормальный.
Но если не знаешь, на практике проверяется очень быстро, функцию попросит реализовать или просто переупомнить.
Странные вопросы — это когда просят вспомнить все ключи web.config или все перегрузки какого-то метода.
Хочу увидеть и попробовать как оно работать в большом колективе.
Большая компания != большой коллектив.
Обычно подразделения (проекты) вообще никак не взаимодействуют в профессиональном плане.
И даже внутри одного проекта у вас будет ваша команда (обычно до 10 чел.) и не факт, что вы будете как-то сильно взаимодействовать с остальными, не являясь менеджером или тимлидом.

Мне даже говориили, что много людей в команде это плохо... Шум, неразбериха...

Оно-то, возможно, и так, но речь ведь о команде, а два человека — это еще даже не команда :)

Да, это нормально. Собеседования — это лотерея. У каждого работодателя свои «тараканы».
Никогда не знаешь, что спросят на следующем собеседовании.
Я думаю, что все эти стандартные тесты и вопросы, логические задачки ничего не показывают вообще. Они проверяют, какое-то знание каких-то нюансов, с которыми можно никогда в жизни не столкнуться.
С другой стороны, работодателей тоже можно понять: надо как-то просеивать поток желающих получить работу, а более эффективных способов отбора еще не придумали.
Сильно помогает в прохождении собеседований прочитать 2-3 умных книги по теме — все расставляет по полочкам в голове.

Согласен с первой частью поста, а вот со второй, наверное, не соглашусь :)

а более эффективных способов отбора еще не придумали
ИМХО, одна из возможных альтернатив.
Начальные предполагаемые условия:
1).Компания нанимает сотрудника для работы не в вакууме, а в реальном проекте.
2).Проект не является стартапом.
Инструменты, технологии, фреймворки, процессы использующиеся в проекте известны.
3).Компания достаточно «богата», чтобы выделить два компьютера/ноутбука под собеседование.
На одном настроена реальная среда разработки использующаяся в проекте, а другой необходим лицу проводящему собеседование (пока кандидат будет занят, лицо сможет заняться своими текущими задачами зайдя удаленно на свой рабочий компьютер).

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

Выполнение реального задания в реальном окружении расскажет о кандидате всё или почти всё что необходимо знать для успешного найма.
А именно:
1).Знание IDE, технологий и фреймворков.
2).Использование документации (найденной в сети и локальной).
3).Качество решения.
4).Качество кода (именование, структура, комментарии, используемые средства языка и тд.)
5).Коммуникативные качества. Какие вопросы задавались, как они задавались и тд.
6).Адекватность реакции на критику решения и способность предложить изменения в связи с полученными замечаниями.
7).Знание средств вроде StarUML (если того требовало задание). Ясность построенных диаграмм.
8)....

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

сценарий нереальный. Не просто так же его сейчас не практикуют.
Выполнение сферического тестового задания удаленно не покрывает пункты 5, 6 что разве, но для этого вполне достаточно 2-3 часов собеседования с разного профиля спецами в компании.
Что бы вникнуть в серьезный реальный проект и решать какие-то не локальные задачи, да еще и соблюдать конвенции и соглашения это надо полдня день потратить, на посмотреть и поговорить. Исходники любого серьезного проекта практически всегда упираються в NDA, да и показывать его не будут каждому кандидату, это уже 2-3 этап собеседования должен быть. Зачем тратить столько времени и ресурс штатного разработчика(уровня не ниже сениора) на обычного кодера, если есть уйма других проверенных более быстрых и дешевых способов, не понятно.

Чтобы за 1,5-2 часа решить новую задачу в незнакомом окружении, нужно обладать достаточно высокой квалификацией. Думаю, что хороший способ отбора на позицию уровня Senior Developer.
Кстати, я знаю одну такую компанию — только для отбора кандидатов у них дается учебный проект на 3 месяца. Если все сложится, то, надеюсь, что буду там работать.

1) большая 5ка (см. рейтинг на этом сайте) пожбирают ЛЮБОГО кто показал знания выше джуниора и не пытался на собеседовании обратить интервьювера в веру магических мощей — вобщем заметных СОЦИАЛЬНЫХ неадекватов. Показать уровень знаний выше джуна после прочтения 2-3 книги + фриланс площадка и попытки в течении 2х недель делать маленькие и интуитивно понятные задачки, не пытаясь выиграть тендер, а получая задачки реальнл нужные заказчикам — думаю что у кандидата продшего такую подготовку есть шансы. Второй вариант безденежный — интернатура или джуниорские программы. Для люкса кажется 3 месяца обучения, по успешному окончанию можно и о зп поговорить.
2. Настройка ноута со средой разработки и задачки по 1.5 часа — шикарно если нужно GUI скилы проверять. А если доменная область банковские операции с деривативами ? Про ноут для интервьювера вообще не выдерживает критики — проект может иметь второй кольцо защиты внутри компании. ЮБС, Барклайс и прочие дойчи меня поймут...
Какую IDE будет использовать работник всем до фени, если проект имеет нормальный CI механизм и билд менеджер.

1) большая 5ка (см. рейтинг на этом сайте) пожбирают ЛЮБОГО кто показал знания выше джуниора и не пытался
а кое кто подбирает и джунов, которые вызывают недоумение даже у часто некомпетентного бизнесса при собеседовании очередного аутстафера, так и у пма или лида в других компаниях, как вы выразились, большой пятерки, при попытке незаметно сменить боевой лагерь

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

пипл партнеров которые сопли все грустным вытерают
проясните, что это значит?

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

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

Меня обычно просто брали на работу. Как-то так сложилось. С испытательным.

На собеседованиях надо показывать не только знания, но и умение думать . Поэтому на вопросы на которые ты не знаешь ответа, можно и пофантазировать. В примере с интерфейсами можно было начать ответ в стиле — «Сам я так никогда не делал, но если бы я проектировал язык php, я бы сделал так ...... потому что ..... »

Я ответил «Незнаю..., но думаю что да — вывалится»

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

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

Такие вопросы задают, чтобы понять, понимает ли человек осовные принципы ООП и особенности реализации ООП в конкретном языке программирования. Предполагается, что кандидат четко себе представляет, что есть абстрактный класс (и чем он отличается от обычного), и что есть интерфейс.

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

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

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

Может хватит жевать сопли? То ты, блин, изучал-разобрался, и, OMFG, даже модуль в состоянии написать, то «код был не мой, я просто разместил объяву был читателем».
Если собеседования проходили в таком же формате, странно, что вообще доходило до «сложных вопросов».

Был похожий вопрос, который звучал так: «Можно ли в Java объявить конструктор со спецификатором final?». Как по мне то это самый тупой вопрос о котором я слышал. Что по нем можно понять? Понимает ли человек что конструкторы в Java финальные? Если так то почему абстрактный метод интерфейса нельзя объявить со спецификатором abstract?

Понимает ли человек что конструкторы в Java финальные?
а они финальные? о_0

Как-то так Эккель писал.

Можно ли в Java объявить конструктор со спецификатором final?
Нет
почему абстрактный метод интерфейса нельзя объявить со спецификатором abstract

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

Методы объявленные в интерфейсе по сути и есть абстрактными, и потому жаба-компилятор разрешает для них спецификатор abstract. В случае с конструктором final почему-то не разрешен.
Я очень сомневаюсь что знание поведения в приведенных мной случаях хоть что-то решает. А также в случае топикстартера с абстрактным классом. Конечно, если речь идет о позиции разработчика компилятора то возможно это имеет определенный смысл...

В случае с конструктором final почему-то не разрешен.
Может, потому что нет смысла запрещать в классе-наследнике дополнять инициализацию?
Хочешь запретить наследование — делай весь класс final
Есть резон?

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

Мне современные интервью в точности напоминают школу, где Машенька молодец потому что все формулы помнит и Таблицу Брадиса на память, но при этом практически применять эти знания не умеет. А рядом Ванечка такой-сякой двоечник не помнит во сколько часов Кейтель подписал капитуляцию.
Видимо от-туда то корни и идут.

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

Если бы вы брали на работу жонглёра — как бы вы его собеседовали?

берем лягушку, берем соломинку...

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

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

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

Годный вброс.

неужели я не смогу понять почему вываливается ошыбка или начать использовать новую библотеку?

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

Наверное нужно напоминать на какую вакансию ты претендуешь...)

Не понимаю вашей мысли.

Я не претендую на вакансию синиора...

Если работодатель считает синиоров тупыми настолько, что могут идти только проторенным путем, отчего надо его опрашивать по конкретике, то вы считает, что джунов и миддлов он будет воспринимать, как что-то лучшее?

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

— ога, 100 процентных синьйоров. да, вопрос не самый тривиальный, но синьйоры то к этому причем?

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

вывалится ли ошыбка если абстрактный клас унаследовать от интерфейса и в класе не описать функцию интрефейса.
а если в ответ сказать что-то типа «я такой херни не пишу»?)

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

я имел в виду не совсем то, хотя пхп я в жизни тоже не видел

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

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

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

Получается замкнутый круг...

Как минимум, вы можете спрашивать у собеседующих вас людей, чего не хватает и над чем нужно развиваться. Если это не какие-то личные качества, то вам обязательно скажут и подскажут.
Еще вам очень поможет если ваше отношение к собеседованию будет не как к экзамену/тесту, где вас оценивают, а как к встрече деловых партнеров, где и вам есть что предложить, и вашему собеседнику. Тогда разговор не будет идти в одни ворота — и вы будете больше расспрашивать о проекте, команде, как организована работа с заказчиком. И техническое собеседование будет более интересно и успешно для вас, если именно вы начнете говорить о своих сильных сторонах и что вы умеете, а не собеседующий будет угадывать что же лучще спросить. Одним словом, пытайтесь быть более активным собеседником, как будто вы пришли на презентацию себя, ну и ответить на интересующие вопросы из «зала».

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

вывалится ли ошыбка если абстрактный клас унаследовать от интерфейса
Zend framework + Doctrine + DI
Вы где-то нас обманываете :)

Нет, все именно так. Я не создавал систему, я просто хорошо узучил ее.

Гуглить вопросы собеседований,читать фундаментальные книги по програсмированию и по технологии/платформе, с которой работаете, ходить на много собеседований — профит

))) ходил на много!, и были предложения, но это были как бы не те компании куда я хотел. Я даже на одном сам задавал вопросы с другого собеседования, мужык улыбался и не понимал для чего их мне задавали... ) Смысл тогда учить эти вотпросы? чтоб просто пройти собеседование? Я конечно понимаю если ето вакансия на 2к баксов тогда да, ты должен быть супер специалистом, но если я не знаю вывалится лы ошибка, но знаю как ето работает и для чего, то и с ошыбкой смогу разобратся. И тоже... бесит..., сначала простые вопросы а потом сложные, почему сразу не спросить сложный вопрос, так и быстрее будет...

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

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

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

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

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

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

Вывались один раз — пофиксил,
это = подождал полтора часа пока соберется билд, предположил в чем проблема, попробовал исправить, подождал еще полтора часа, итого впустую слил пол дня. Конечно, пример может быть преувеличен, но учитывая что ты не понимаешь основ- будешь сплошь и рядом допускать такие ошибки.
Увидеть ошибку, подумать и исправить сможет даже далекий от программирования человек.
От тебя же хотят что бы ты допускал самое малое кол-во таких ошибок...а такой подход как ты сейчас тут пропагандируешь- никому не нужен... "создание модулей для сайта"- уровень школьника, прочитавшего 2 книги на каникулах, серьезно.
Или ты думаешь что весь мир разработки это написание модулей для гавносайтов, где через контрол+с -> альт+таб->ф5?)
Отбрось свое завышенное ЧСВ, прислушайся что тебе советуют люди...

Ну я тему для того и создал чтобы получить советы.

Только Вы определитесь с советами. Вам в компанию попасть или баги пофискить научиться?
И тему соответствующую заведите

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

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

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

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

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

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

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

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

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

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

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

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

«в дотнете тоже нужно определять абстрактный метод руками. » -

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

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

почему глупо?
в РНР именно так: явно в абстрактном классе не надо переопределять абстрактные члены, полученные из интерфейса. реализовывать — можно. заново указывать — не обязаетельно.
phpfiddle.org/...in/code/x04-6pm

ну вот, а в C# нужно, так что все зависит только от тонкостей синтаксиса языка

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

facepalm. Конструткоры по умолчанию, авто свойства, параметры по умолчанию, вывод generic-типов и пр — не, не слышал? C# пестрит синтаксическим сахаром как павлин, при чем здесь вообще строгая типизация и адекватность? Стогость типизации никоим образом не нарушится в данном случае, зачем спорить.

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

И что есть какие-то конвенции, что рекомендуют так делать?

а в чем проблема?
упорно не понимаю.
вот, у нас есть базовый абстрактный класс. объявляет реализацию iSerializeable. конкретная реализация будет в дочерних классах.
Чем нам поможет явное переобъявляение всех элементов интерфейса в виде абстрактных членов, раз реализовывать в базовом классе не собираемся?

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

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

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

вывалится ли ошыбка если абстрактный клас унаследовать от интерфейса и в класе не описать функцию интрефейса
довольно таки глупый, т.к. ответ — «как бэ да, но если б разарабы языка захотели — то необязательно»

Подписаться на комментарии