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

Очередной пост, отдаленный от конкретики типа «кодерку не понять».
Для вас, 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 годами опыта работы?

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

Відповісти

Підтримати

anonymous

anonymous 03.11.2013 11:03

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

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

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

Відповісти

Підтримати

Сергей Анисимов

Євген Козлов Front-end developer в SoftServe 03.11.2013 14:34

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

Відповісти

Підтримати

anonymous

anonymous 03.11.2013 14:42

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

Відповісти

Підтримати

Євген Козлов

Євген Козлов Front-end developer в SoftServe 03.11.2013 14:52

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

Відповісти

Підтримати

anonymous

anonymous 03.11.2013 15:10

та ну. появится — там где надо. где будет реализация.

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

оперируя вашим же призывом: надо работать с выражением процессов и объектов, а не с категориями языка.

да только они должны быть четко формализированы

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

А насчет PHP... мы тут как бы C# обсуждаем. Честно говоря мне C# намного больше нравится чем PHP и Java, но увы его нет на линукс (Mono не рассматриваю).
Кстати в PHP я следую тому же правилу хоть оно и не обязательно.

Відповісти

Підтримати

Євген Козлов

Євген Козлов Front-end developer в SoftServe 03.11.2013 15:34

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

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

мы тут как бы C# обсуждаем

угу, я заметил:

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

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

Мое мнение — разрабы компилятора C# просто поленились

Відповісти

Підтримати

anonymous

Дмитро 03.11.2013 15:39

С чего? Все описано в интерфейсе.

повторюсь, как уже говорил ниже.
Когда абстрактный класс реализует уже 2 или 3 интерфейса это крайне неудобно, даже имея кучу тулзов накруток в ИДЕ и я более чем уверен, что врядли есть конвенции, которые будут рекомендовать implicit реализацию интерфейсов, хотя мне конвенции пхп и не знакомы.
Это все равно, что везде пихать виртуальные публичные методы и говорить, а чего б и нет, конструкция языка-то позволяет.

Відповісти

Підтримати

Євген Козлов

Євген Козлов Front-end developer в SoftServe 03.11.2013 15:47

повторюсь, как уже говорил ниже.

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

Это все равно, что везде пихать виртуальные публичные методы

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

Відповісти

Підтримати

Дмитро

Дмитро 03.11.2013 16:02

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

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

Відповісти

Підтримати

Євген Козлов

Євген Козлов Front-end developer в SoftServe 03.11.2013 16:08

да если метод астрактный, его надо реализовать в каждом наследнике

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

abstract class Base {
 public abstract void test();
}
abstract class MoreSpecificBase : Base {
 public abstract void test();
}

в чем смысл такого переобъявления?

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

а еще — синтаксис языка, лексические парсеры, багтикеты, ROI и депозитные вклады. при чем тут это?
UPD: привел код-пример в соответсвие с блоком выше. Чтоб не было повода для «в Java синактсис не такой, пример неправильный»

Відповісти

Підтримати

Дмитро

Дмитро 03.11.2013 16:19

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

а еще — синтаксис языка, лексические парсеры, багтикеты, ROI и депозитные вклады. при чем тут это?

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

Відповісти

Підтримати

Євген Козлов

Євген Козлов Front-end developer в SoftServe 03.11.2013 17:35

implicit реализация интерфейсов на уровне абстрактного класса фича сомнительная

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

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

Вообще-то, нет. Если, вдруг, не в курсе, абстрактный класс допускает реализацию в своих неабстрактных методах. А интерфейс — нет.

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

эээ. давайте говорить очевидные банальности. это удобный аргумент. согласятся с одним — согласятся и с другим.

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

не понимаю. можно, на примере? может, я не дорос до правильного определения виртуального метода?

Відповісти

Підтримати

Дмитро

Bogdan Shyiak SE or Dev 03.11.2013 17:56

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

Есть у меня такое чувство, что:
Товарищи утверждаю что для бизнес-логики имеет значение является сущность интрефейсом или (абстрактным)классом (На мой взгляд это ошибка). То есть (на примере):
Здание — не может быть интерфейсом, а должно быть классом.
А вот Входбл (то куда можно войти) — может быть только интерфейсом и не может быть классом.
Поэтому если у вас у Здания есть метод войтиВнутрь и Дом (наследник) Здания абстрактный, то он должен __явно указывать что он соблюдает протокол родителя__.
А вот тот факт что Дом реализует интерфейс Входбл __уже должно указывать__ на то что Дом соблюдает протокол родителя.
.
Судя по тому что тут аж 2 таких мнения, они явно окуда-то это вычитали, от только не понятно откуда.
.

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

От мне так же интересен пример.
Но не уверен что вы его получите, создатель Ц№ сказал что это плохо, а у дотНетчиков не принято прерикатсо с МСом :)

Відповісти

Підтримати

Євген Козлов

Дмитро 03.11.2013 18:05

Так зачем копипастить сигнатуры?

что бы не искать потом элементы сущности по всему проекту.

не понимаю. можно, на примере? может, я не дорос до правильного определения виртуального метода?

www.spatial.com/...ethods-bad-idea

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

Відповісти

Підтримати

Євген Козлов

Євген Козлов Front-end developer в SoftServe 03.11.2013 18:15

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

Відповісти

Підтримати

Дмитро

Дмитро 03.11.2013 18:26

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

Відповісти

Підтримати

Євген Козлов

Євген Козлов Front-end developer в SoftServe 03.11.2013 18:33

зачем так много сарказма?

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

Відповісти

Підтримати

Дмитро

Дмитро 03.11.2013 18:54

И никакого придания анафеме свойства языка.
не нравится категоричность.

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

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

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

Відповісти

Підтримати

Євген Козлов

Євген Козлов Front-end developer в SoftServe 03.11.2013 18:58

в рассматриваемом примере как раз таки эта ситуация исключается

угу. не досмотрел :(

Відповісти

Підтримати

Дмитро

Bogdan Shyiak SE or Dev 03.11.2013 15:39

А насчет PHP... мы тут как бы C# обсуждаем

А еще пару постов назад вы пытались «мыслить абстрактно» ( dou.ua/...ic/8518/#381348 ) :)
Поведение описанное в dou.ua/...ic/8518/#381338 больше __похоже__ на баг, возможно связанный с (не)виртуальными методами.

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

От интересно, вы это в какой-то книге вычитали или сами придумали? Если в книге, то дайте ссылку почитать.
Я как бы не сталкивался с такой «школой ООП», обычно достаточно было понятия протокола/интерфейса.

Відповісти

Підтримати

anonymous

anonymous 03.11.2013 18:18

А еще пару постов назад вы пытались «мыслить абстрактно»

каюсь :)

От интересно, вы это в какой-то книге вычитали или сами придумали?

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

Відповісти

Підтримати

Bogdan Shyiak

Bogdan Shyiak SE or Dev 03.11.2013 19:25

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

Излишне долго. В реальности все намного проще :)
Есть сообщения, есть протокол, надо (чаще всего) прятать данные за протокол (бо без этого неудобно получается) — это и есть вся философия. Все остальное придумали хитрые раввины от программирования шоб зашибать бабло.

Відповісти

Підтримати

anonymous

Сергей Анисимов 03.11.2013 18:00

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

Відповісти

Підтримати

anonymous

Andrusenko Dmytro Senior Developer в DataArt 03.11.2013 20:28

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

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

Відповісти

Підтримати

Сергей Анисимов

Сергей Анисимов 03.11.2013 20:38

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

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

Відповісти

Підтримати

Andrusenko Dmytro

Andrusenko Dmytro Senior Developer в DataArt 03.11.2013 21:30

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

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

Відповісти

Підтримати

Сергей Анисимов

Сергей Анисимов 04.11.2013 00:38

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

Відповісти

Підтримати

Andrusenko Dmytro

Bogdan Shyiak SE or Dev 03.11.2013 20:53

Вы путаете собеседование с тестированием или экзаменом.

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

Відповісти

Підтримати

Andrusenko Dmytro

Ivan Skrypka Senior Developer в McGraw Hill Education 03.11.2013 21:01

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

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

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

Відповісти

Підтримати

Bogdan Shyiak

Bogdan Shyiak SE or Dev 03.11.2013 21:22

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

Пост на который вы отвечали
dou.ua/...ic/8518/#381233
не содержит указанной цитаты.

то мне вас и вашего работодалея искрене жалко.

А мне вас нет, ваше неумение держать контекст в голове — это не моя проблема, а люкс за вас в любом случае получает процент :)

Но ни как не на базовые вещи.

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

В случае с конструктором final почему-то не разрешен.

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

Відповісти

Підтримати

Ivan Skrypka

Andrusenko Dmytro Senior Developer в DataArt 03.11.2013 21:12

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

Відповісти

Підтримати

Bogdan Shyiak

Valter Scott 03.11.2013 21:22

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

Відповісти

Підтримати

Andrusenko Dmytro

anonymous 03.11.2013 16:00

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

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

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

верх идиотизма

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

Відповісти

Підтримати

Сергей Анисимов

Сергей Анисимов 03.11.2013 20:28

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

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

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

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

Відповісти

Підтримати

anonymous

Java Adept 02.11.2013 03:05

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

Відповісти

Підтримати

anonymous

anonymous 02.11.2013 07:48

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

Відповісти

Підтримати

Java Adept

Євген Козлов Front-end developer в SoftServe 02.11.2013 09:03

в данном контексте — Java разработчиком

Zend framework + Doctrine + DI и разные мелкие фишки

Какая-то странная Java, чесслово

Відповісти

Підтримати

anonymous

Viacheslav 02.11.2013 16:25

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

Відповісти

Підтримати

Євген Козлов

Микола Федчик Dev Manager в OpenBet 31.10.2013 10:05

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

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

2)

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

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

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

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

Відповісти

Підтримати

Sergii Kudriavtsev Senior Software Developer в Lemonade 31.10.2013 12:15

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

Відповісти

Підтримати

Микола Федчик

Назар Казымов Java Developer 02.11.2013 16:53

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

Відповісти

Підтримати

Микола Федчик

anonymous 03.11.2013 07:56

Совет 1: ПОЗВОНИТЕ РЕКРУТЕРАМ И ПООБЩАЙТЕСЬ С НИМИ!!! РАССПРОСИТЕ, О ЧЕМ ВАС БУДУТ СПРАШИВАТЬ НА ИНТЕРВЬЮ!

а я наивно полагаюсь на описание вакансии

Відповісти

Підтримати

Микола Федчик

Антон Харуйманов 30.10.2013 14:06

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

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

Відповісти

Підтримати

anonymous 30.10.2013 13:47

Хочу увидеть и попробовать как оно работать в большом колективе.

Большая компания != большой коллектив.
Обычно подразделения (проекты) вообще никак не взаимодействуют в профессиональном плане.
И даже внутри одного проекта у вас будет ваша команда (обычно до 10 чел.) и не факт, что вы будете как-то сильно взаимодействовать с остальными, не являясь менеджером или тимлидом.

Відповісти

Підтримати

Володимир Бучач PHP Developer 30.10.2013 13:52

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

Відповісти

Підтримати

anonymous

Mr Grinch 30.10.2013 14:15

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

Відповісти

Підтримати

Володимир Бучач

Станислав Скребцов Java Developer, Embedded Developer в Looking for a job in Kiev 30.10.2013 13:43

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

Відповісти

Підтримати

Oleksandr Markushyn Senior Java Developer and Team Leader Deputy at ISD 31.10.2013 00:52

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

а более эффективных способов отбора еще не придумали

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

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

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

Відповісти

Підтримати

Станислав Скребцов

Володимир Бучач PHP Developer 31.10.2013 08:19

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

Відповісти

Підтримати

Oleksandr Markushyn

Дмитро 31.10.2013 08:43

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

Відповісти

Підтримати

Oleksandr Markushyn

Станислав Скребцов Java Developer, Embedded Developer в Looking for a job in Kiev 31.10.2013 09:03

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

Відповісти

Підтримати

Oleksandr Markushyn

WilD FlY pm в Luxoft 01.11.2013 23:11

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

Відповісти

Підтримати

Oleksandr Markushyn

Дмитро 01.11.2013 23:25

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

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

Відповісти

Підтримати

WilD FlY

WilD FlY pm в Luxoft 01.11.2013 23:32

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

Відповісти

Підтримати

Дмитро

Євген Козлов Front-end developer в SoftServe 01.11.2013 23:37

пипл партнеров которые сопли все грустным вытерают

проясните, что это значит?

Відповісти

Підтримати

WilD FlY

WilD FlY pm в Luxoft 01.11.2013 23:44

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

Відповісти

Підтримати

Євген Козлов

Євген Козлов Front-end developer в SoftServe 01.11.2013 23:51

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

Відповісти

Підтримати

WilD FlY

Андрей Гаврилин 10.11.2013 14:34

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

Відповісти

Підтримати

Станислав Скребцов

Макс Матюхин программист в Badoo 30.10.2013 13:21

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

Відповісти

Підтримати

Володимир Бучач PHP Developer 30.10.2013 13:52

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

Відповісти

Підтримати

Макс Матюхин

Mr Grinch 30.10.2013 14:08

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

Відповісти

Підтримати

Володимир Бучач

Макс Матюхин программист в Badoo 30.10.2013 14:28

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

Відповісти

Підтримати

Володимир Бучач

Dmytro Lapshyn Tech Lead в Fulcrum Rocks 30.10.2013 12:23

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

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

Відповісти

Підтримати

noname fordou 30.10.2013 12:59

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

Відповісти

Підтримати

Dmytro Lapshyn

Володимир Бучач PHP Developer 30.10.2013 13:56

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

Відповісти

Підтримати

noname fordou

Mr Grinch 30.10.2013 14:05

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

Відповісти

Підтримати

Володимир Бучач

anonymous 02.11.2013 11:22

-

Відповісти

Підтримати

Dmytro Lapshyn

Євген Козлов Front-end developer в SoftServe 02.11.2013 12:23

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

а они финальные? о_0

Відповісти

Підтримати

anonymous

anonymous 02.11.2013 12:30

-

Відповісти

Підтримати

Євген Козлов

Viacheslav 02.11.2013 16:26

Можно ли в Java объявить конструктор со спецификатором final?

Нет

Відповісти

Підтримати

anonymous

Dmytro Lapshyn Tech Lead в Fulcrum Rocks 02.11.2013 18:09

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

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

Відповісти

Підтримати

anonymous

anonymous 02.11.2013 18:35

-

Відповісти

Підтримати

Dmytro Lapshyn

Євген Козлов Front-end developer в SoftServe 02.11.2013 23:09

В случае с конструктором final почему-то не разрешен.

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

Відповісти

Підтримати

anonymous

Ivan Skrypka Senior Developer в McGraw Hill Education 03.11.2013 13:41

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

Відповісти

Підтримати

anonymous

anonymous 03.11.2013 14:46

-

Відповісти

Підтримати

Ivan Skrypka

Ivan Skrypka Senior Developer в McGraw Hill Education 03.11.2013 15:13

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

Відповісти

Підтримати

anonymous

Pavel Kruchina CTO 03.11.2013 15:34

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

Відповісти

Підтримати

Ivan Skrypka

Євген Козлов Front-end developer в SoftServe 03.11.2013 15:50

а если бы — палача? о_0

Відповісти

Підтримати

Pavel Kruchina

Димон 03.11.2013 16:50

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

Відповісти

Підтримати

Євген Козлов

Ivan Skrypka Senior Developer в McGraw Hill Education 03.11.2013 17:49

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

Відповісти

Підтримати

Pavel Kruchina

Pavel Kruchina CTO 03.11.2013 23:01

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

Відповісти

Підтримати

Ivan Skrypka

anonymous 03.11.2013 21:10

-

Відповісти

Підтримати

Ivan Skrypka

trimm Developer/Independent contributor в IDAP 30.10.2013 10:16

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

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

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

Відповісти

Підтримати

Володимир Бучач PHP Developer 30.10.2013 10:20

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

Відповісти

Підтримати

trimm

trimm Developer/Independent contributor в IDAP 30.10.2013 10:36

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

Відповісти

Підтримати

Володимир Бучач

Володимир Бучач PHP Developer 30.10.2013 10:37

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

Відповісти

Підтримати

trimm

trimm Developer/Independent contributor в IDAP 30.10.2013 10:38

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

Відповісти

Підтримати

Володимир Бучач

noname fordou 30.10.2013 13:01

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

Но тут ориентировка идет на синиоров

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

Відповісти

Підтримати

trimm

trimm Developer/Independent contributor в IDAP 30.10.2013 13:35

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

Відповісти

Підтримати

noname fordou

Oleh Korotkov девелопер в шоке 30.10.2013 09:33

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

а если в ответ сказать что-то типа «я такой херни не пишу»?)

Відповісти

Підтримати

Дмитро 30.10.2013 09:52

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

Відповісти

Підтримати

Oleh Korotkov

Oleh Korotkov девелопер в шоке 30.10.2013 10:03

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

Відповісти

Підтримати

Дмитро

Сергей Анисимов 01.11.2013 10:55

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

Відповісти

Підтримати

Oleh Korotkov

Sergey Khaperskov Lead Engineerist 30.10.2013 09:02

просто что я за человек, до вопросов по професии)))

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

практически всегда попадаются какие то странные вопроси

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

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

Відповісти

Підтримати

Володимир Бучач PHP Developer 30.10.2013 09:48

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

Відповісти

Підтримати

Sergey Khaperskov

Sergey Khaperskov Lead Engineerist 02.11.2013 05:26

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

Відповісти

Підтримати

Володимир Бучач

Євген Козлов Front-end developer в SoftServe 30.10.2013 01:22

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

Відповісти

Підтримати

anonymous 30.10.2013 01:05

вывалится ли ошыбка если абстрактный клас унаследовать от интерфейса

Zend framework + Doctrine + DI

Вы где-то нас обманываете :)

Відповісти

Підтримати

Володимир Бучач PHP Developer 30.10.2013 08:18

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

Відповісти

Підтримати

anonymous

Oleksii Khorchev Engineering Manager building an organization в EPAM 29.10.2013 20:11

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

Відповісти

Підтримати

Володимир Бучач PHP Developer 29.10.2013 22:06

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

Відповісти

Підтримати

Oleksii Khorchev

Євген Козлов Front-end developer в SoftServe 30.10.2013 01:20

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

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

Відповісти

Підтримати

Володимир Бучач

Oleh Korotkov девелопер в шоке 30.10.2013 09:32

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

Відповісти

Підтримати

Євген Козлов

Євген Козлов Front-end developer в SoftServe 30.10.2013 09:45

Иногда есть такие сложные вопросы

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

Відповісти

Підтримати

Oleh Korotkov

Oleh Korotkov девелопер в шоке 30.10.2013 09:52

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

Відповісти

Підтримати

Євген Козлов

Junior Engineer 30.10.2013 12:32

то и с ошыбкой смогу разобратся.

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

Відповісти

Підтримати

Володимир Бучач

Володимир Бучач PHP Developer 30.10.2013 12:36

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

Відповісти

Підтримати

Junior Engineer

Junior Engineer 01.11.2013 11:40

Вывались один раз — пофиксил,

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

Відповісти

Підтримати

Володимир Бучач

Володимир Бучач PHP Developer 01.11.2013 11:48

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

Відповісти

Підтримати

Junior Engineer

Микола Федчик Dev Manager в OpenBet 01.11.2013 13:28

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

Відповісти

Підтримати

Володимир Бучач

Sergii Kudriavtsev Senior Software Developer в Lemonade 03.11.2013 00:50

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

Відповісти

Підтримати

Володимир Бучач

Сергей 29.10.2013 17:52

если абстрактный клас унаследовать от интерфейса

то есть эта фраза ничего не говорит?

также по немногу стараюсь узнать новое

Наверное стоит увеличить старания и узнавать побольше?

Відповісти

Підтримати

anton merzu 29.10.2013 15:10

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

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

Відповісти

Підтримати

Володимир Бучач PHP Developer 29.10.2013 15:34

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

Відповісти

Підтримати

anton merzu

anton merzu 29.10.2013 15:36

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

Відповісти

Підтримати

Володимир Бучач

anonymous 30.10.2013 12:29

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

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

Відповісти

Підтримати

Володимир Бучач

Дмитро 30.10.2013 12:45

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

Відповісти

Підтримати

anonymous

Євген Козлов Front-end developer в SoftServe 30.10.2013 12:56

а в чем разница?

Відповісти

Підтримати

Дмитро

Дмитро 30.10.2013 13:18

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

Відповісти

Підтримати

Євген Козлов

Сергей Анисимов 01.11.2013 11:00

не знает, что интерфейс должен быть реализован — это да

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

Відповісти

Підтримати

Дмитро

Дмитро 01.11.2013 11:12

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

Відповісти

Підтримати

Сергей Анисимов

anonymous 01.11.2013 11:30

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

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

Відповісти

Підтримати

Дмитро

Сергей Анисимов 01.11.2013 12:00

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

Відповісти

Підтримати

anonymous

anonymous 01.11.2013 11:31

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

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

Відповісти

Підтримати

Дмитро

Дмитро 01.11.2013 11:55

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

Відповісти

Підтримати

anonymous

Євген Козлов Front-end developer в SoftServe 01.11.2013 12:20

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

Відповісти

Підтримати

Дмитро

Сергей Анисимов 01.11.2013 12:25

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

Відповісти

Підтримати

Євген Козлов

Дмитро 01.11.2013 12:33

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

Відповісти

Підтримати

Сергей Анисимов

Сергей Анисимов 01.11.2013 13:02

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

Відповісти

Підтримати

Дмитро

Дмитро 01.11.2013 13:26

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

Відповісти

Підтримати

Сергей Анисимов

Сергей Анисимов 01.11.2013 13:30

спс за аргументированный ответ

Відповісти

Підтримати

Дмитро

Дмитро 01.11.2013 12:30

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

Відповісти

Підтримати

Євген Козлов

Євген Козлов Front-end developer в SoftServe 01.11.2013 12:40

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

Відповісти

Підтримати

Дмитро

Дмитро 01.11.2013 12:55

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

Відповісти

Підтримати

Євген Козлов

Євген Козлов Front-end developer в SoftServe 01.11.2013 13:02

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

Відповісти

Підтримати

Дмитро

Сергей Анисимов 01.11.2013 11:54

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

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

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

Відповісти

Підтримати

Дмитро

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

Найкращі коментарі пропустити

146 коментарів

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

Новини