Здравствуйте, blacktea, Вы писали:
B>считай, что это как раз фильтр для твоего п.3, насколько сильно человек хочет работать у вас
Чот сразу вспомнилось: Работать в нашем банке — большая честь
Здравствуйте, avovana, Вы писали:
A>А теперь нужно оценить кандидата, что он: A>1. Будет хорошо выполнять свою работу A>2. Адекватный по общению A>3. Замотивирован A>4. Обладает нужной квалификацией A>Как это сделать?
Я собеседование делил на два этапа, первый этап — фильтрация тех, кто вообще абсолютно не умеет кодить (а таких, к сожалению, очень много). Давал пару очень простых задач (не олимпиадных) на кодирование в онлайн IDE.
После, давал тестовое задание, на выполнение которой обычно уходит примерно 2-3 часа и на следующем собесе мы обсуждали его решение. Заранее готовил разные вариации на тему, а что мы будем делать, если требования к этой задачке чуть-чуть изменятся в эту сторону. А что будет, если мы применим тут такой-то паттерн или подход? Представь себе, что у нас появился редкий баг, который сложно отловить, как будем действовать? Ну и все в таком роде.
ЗЫ: я заметил, что тут прям очень не любят тестовые задания, считай, что это как раз фильтр для твоего п.3, насколько сильно человек хочет работать у вас
Здравствуйте, kaa.python, Вы писали:
KP>А если неправильно угадал, то падает и весело говорит "угадайте где!"?
Он вываливает стектрейс в стиле "я не смог инициализировать X, потому что не смог инициализировать Y, ..., потому что не смог инициализировать K, потому что достал уже, вот почему". И удачи разбираться где и как ты накосячил в неявной конфигурации.
Здравствуйте, avovana, Вы писали:
A>Я также слышал что не каждый переваривает тестовые. Люди могут просто пролистывать дальше вакансии заметив тестовое.
А я наоборот люблю тестовые задания, когда можно дома сидя в комфорте с чашкой любимого чая поделать интересное задание. И не люблю олимпиадные задачки (причем, я сам бывший олимпиадщик), т.к. для меня это как лотерея, повезет или не повезет. Иногда стрессую и не могу решить даже простейшие задачки. Что самое смешное, сразу после собеса, после того как выдохнул, сразу всплывает решение задачки в голове
К чему это я, предлагая тестовые задачки с одной стороны я ищу близких к себе по духу людей. Плюс, как я писал выше, главная задача это инициировать предметное обсуждение и в ходе беседы лучше узнаешь человека, ход его мысли, сработаешься ты с ним или нет.
Здравствуйте, Умака Кумакаки, Вы писали:
Тё>>Чел позиционировал как синьер, инжектор не задизайнил (сразу сдался), и потом отклонил офер на мидла (на синьера не дотягивал).
УК>сейчас я бы хрен что на собеседовании написал,
Печально. Значит, до синьера не дотягиваешь.
Здравствуйте, Тёмчик, Вы писали:
Тё>Здравствуйте, kaa.python, Вы писали:
Тё>Т.е. ты против всего хорошего, aka loose coupling, polymorphism, extensibility Тё>и за все плохое, aka кусок связанного явными вызовами кала.
loose coupling не имеет ничего общего с неавной инициализацией, в то время как extensibility от неявной инициализации только страдает.
Да, считаю polymorphism изжившим себя подходом. А вообще я за простоту и поддерживаемость кода, как-то так, самое важное применительно к данной ситуации я выделил:
Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested.
Sparse is better than dense. Readability counts.
Special cases aren't special enough to break the rules. Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
Здравствуйте, avovana, Вы писали:
A>В ближайшем будущем, возможно, буду нанимать в свою команду. A>Хотел бы узнать о хороших паттернах, антипаттернах найма.
1. Определиться кого ты хочешь видеть. По пунктам — чтобы умел то и то.
Берешь задачи из бэклога и выписываешь — выделяешь из них суть, что надо сделать и какими знаниями обладать, чтобы успешно их решить
Можешь внести субъективные пункты — например, чтобы был таким же задротом, как ты, или был лесорубом с подвернутыми штанишками на самокате.
2. Соотнести это с зп фондом и должностью. Бесполезно искать синего за нищебродскую зп.
Также бесполезного нанимать человека, явно хотящего нового, на проект, где надо будет чинить баги. Это глупо. Лучше нанять джуна и испортить ему карьеру.
3. Смириться, что полностью на собесе ты человека не проверишь, именно для этого есть испытательный срок. Лучше составить его вдумчивый план.
Антипаттерны:
1. Не надо из себя строить экзаменатора(если только в реальности ты не такой же), особенно если собеседуешь не джунов.
2. Быть самим собой на собесе, чтобы не создавать иллюзий. Если ты ведешь себя в жизни, как чудак, то и на собесе задай порешать задачку на гомиков.
3. Не надо врать или умалчивать об условиях — иначе на испытательном тебя справедливо назовут.
Здравствуйте, kaa.python, Вы писали:
KP>А что такое IoC? Это интерфейс скормить, вместо реализации?
Интерфейс вместо реализации это примерно 1% всего дела. Гораздо интереснее когда и как создается, собственно, реализация. В случае Java Spring, он читает аннотации на полях классов и пытается угадать, какой конкретно экземпляр и какой имплементации интерфейса будет уместен для каждого поля. А потом создает и инициализирует эти зависимости. С учетом того что зависимости мало того что образуют граф, так еще и в этом графе могут быть циклы. Сдизайнить такое на пальцах, ну такое себе развлечение.
Здравствуйте, avovana, Вы писали:
A>Добрый день, дорогие форумчане!
A>В ближайшем будущем, возможно, буду нанимать в свою команду.
Нанимал достаточно много, по моему опыту, главное — три вещи:
— знание базовой теории алгоритмов: алгоритмическая сложность коллекций и кода, обход деревьев, рекурсия, для людей посильнее — сетевые протоколы, ОС, многопоточность
— сеанс онлайн-кодинга: что-то, связанное с проектированием нескольких классов и привязанное к реальной жизни. Например, логику турникета в метро, бронирования билетов на поезд, оплаты заказа.
— адекватность! Кандидат должен делать, что ему говорят (не бычить), понимать условие задачи (не тупить), проявить гибкость и умение выбирать компромисс (синдром ЕдинственноПравильногоРешения), уметь обосновывать свои решения
Хибернейты, спринги и прочие фреймворки такая мелочь — адекватный человек легко вольется в существующий настроенный проект и начнет штамповать код.
Здравствуйте, avovana, Вы писали:
A>Как выявить мотивацию?
Она как правило проста: люди идут работать работу на работе за деньги.
Идеальный вариант — нанять тех, кто деньги отработают.
Вьюноши же с горящими жопами глазами, болеющие за проект (tm) радостно заболеют другим проектом когда им наскучит твой.
Впрочем деньги хотят все из них, но кто то может делать что то полезное, а кто то не очень. Твоя задача как то понять кто из кандидатов может по-настоящему а кто умеет проходить собеседования. И тут серебряной пули нет.
Впрочем можно понять способен ли кандидат хотя бы инженерно мыслить, что является весьма важным критерием для того чтоб быть разработчиком а не stack-overflow-copypaster.
Я для такого даю простую (элементарную даже) техническую задачку, для которой не надо особой писанины, буквально псевдокод накидать в пару строк, но которую можно решить множеством способов. Эта задачка всего то повод поговорить и пообсуждать предлагаемые варианты решений и почему так, нюансы решений, возможности оптимизации и т.п.
Из такого разговора становится понятно как собеседник мыслит.
Ещё раз, поскольку эта тема тут обсасывалась сотни раз и имеет вероятность начать по новой — серебряной пули нет, смотри как делают другие и выбирай из их подходов то, что может сработать у тебя. Если не получается желаемое — пробуй другие варианты.
A>И можно ли её повысить при общение? С клоунским носом задорно рассказывая про проект.
А у тебя какая цель? Если нанять лохов джунов, которые за копьё на энтузиазме будут копать как умеют — то да.
Если же надо серьёзные люди, которые помогут реализовать задуманное — мотивация будет с бОльшего как раз финансовая. Интересность проекта это всего лишь бонусный поинт, который может привлечь тем, что этот проект копать будет веселее.
A>Или у человека есть текущий период времени жизни с текущей мотивацией, демотивацией, жизненными разрешенными, неразрешенными ситуациями и ты никак на это не повлияешь?
Такое тоже бывает.
Здравствуйте, Miroff, Вы писали:
M>Он вываливает стектрейс в стиле "я не смог инициализировать X, потому что не смог инициализировать Y, ..., потому что не смог инициализировать K, потому что достал уже, вот почему". И удачи разбираться где и как ты накосячил в неявной конфигурации.
Звучит так себе. Я вообще крайне против неявной конфигурации чего бы то ни было. Если лимитировать IoC только в рамках замены подобного кода (утащил отсюда)
public class TextEditor {
private SpellChecker checker;
public TextEditor() {
this.checker = new SpellChecker();
}
}
на такой
public class TextEditor {
private IocSpellChecker checker;
public TextEditor(IocSpellChecker checker) {
this.checker = checker;
}
}
то идея более чем здравая и активно используется и в C++, и в Go. Но вот делать неявную инициализацию конфигурации уже ведет к проблемам. Так же сам факт наличия неявной конфигурации говорит о том, что подобным подходом злоупотребляют на столько, что разрешить зависимости явно становится не возможным, иначе зачем она нужна?
Здравствуйте, Тёмчик, Вы писали:
Тё>Т.е. ты против всего хорошего, aka loose coupling, polymorphism, extensibility
Не, это ты, видимо, не понимаешь, что это все прекрасно делается без IoC-контейнеров. Которые, как правило, ничего кроме головной боли не добавляют.
Тё>и за все плохое, aka кусок связанного явными вызовами кала.
Кал получается, когда IoC-контейнеры начинают пихать во все дырытуда, где можно спокойно обойтись явным созданием зависимостей в main с последующим их явным пробросом по иерархии.
В ближайшем будущем, возможно, буду нанимать в свою команду.
Хотел бы узнать о хороших паттернах, антипаттернах найма.
Сам сталкивался с различными форматами собеседований.
Мечтал, чтобы люди посмотрели на мой гитхаб, где есть работающий коммерческий проект и много разных решений. И по нему уже пообщались.
Однако, никому это было не надо.
Встречал такие типы собеседований:
1) Поговорим по телефону про проект, условия, основные вопросы по языку
2) Посидим очно в офисе, поговорим, порешаем задачи
3) Проведем несколько этапов а-ля гугл
4) Дадим тестовое
Каждый из вариантов вызывал некоторое беспокойство/раздражение/тревогу, что я должен играть по их правилам.
Приходилось играть. Недавно, к примеру, устроился на новую работу так:
а) Выполнил домашнее тестовое
б) В офисе сделал 2 задачи
в) В офисе пообщался по специфичным для стека задачам.
Посещала мысль:
"Мне же понятно, что я выполняю свою работу на хорошем уровне. Почему я должен это доказывать?"
А теперь нужно оценить кандидата, что он:
1. Будет хорошо выполнять свою работу
2. Адекватный по общению
3. Замотивирован
4. Обладает нужной квалификацией
Как это сделать?
Должен ли я создавать какой-то образ компании/продавать вакансию?
Или просто уважительно общаться, рассказать про задачи, команду, проект, стек.
И мы либо сматчимся, либо нет?
А если сматчимся, быть может, это первое обманчивое впечатление?..
A>А теперь нужно оценить кандидата, что он: A>1. Будет хорошо выполнять свою работу A>2. Адекватный по общению A>3. Замотивирован A>4. Обладает нужной квалификацией A>Как это сделать?
Могу только сказать банальности:
1. Почитать книжки по психологим, определиться, какой психотип работника вам нужен под конкретные задачи, оценить псих.состояние команды, возраст и пол ее членов. У Вас лично должно быть четкое видение того, кого вы хотите нанять.
2. Искать чтением резюме, задавать уточняющие вопросы по почте. Можно составить шаблоны с вопросами, но главное не потерять видимость персонального письма.
3. Звать на собеседование понравившихся.
Первый этап можно делать совместно с hr.
Искать людей собеседованием всех подряд, кого подберёт hr по ключевым словам в резюме — заведомо потратить кучу времени впустую. Но если цель — показать руководству, как мало хороших программистов и нужно больше денег, то это самое то.
Здравствуйте, avovana, Вы писали:
A>Видел задорные менеджерские заметки, что чем разношерстней команда, тем лучше.
И чем же лучше? Как в том анекдоте — "чем грузины"?
Гемору по координации точно будет больше, а вот бонусы какие?
Разношёрстность команды по опыту, когда люди имели разнообразный опыт и всякое видели с разных сторон — хорошо.
Разношёрстность по отношению к качеству кода — плохо.
A>Что ошибка менеджера искать точно такого же как он. Не будет разных мнений.
Далеко не всегда разница во мнениях это что то хорошее, особенно когда стоит задача собрать команду, которая будет работать над одной задачей и иметь единую цель.
Здравствуйте, avovana, Вы писали:
A>Мечтал, чтобы люди посмотрели на мой гитхаб, где есть работающий коммерческий проект и много разных решений. И по нему уже пообщались.
Чтобы обсуждать Ваш большой гитхаб, нужно в нём разбираться. А это никому не интересно -- времени нет, да и желания.
Если только Вы не автор какой-то умопомрачительной и известной на всю отрасль штуковины. Но в этом случае наверное берут безо всяких собеседований.
Вот придёт к Вам 50 бывших бухгалтеров и менеджеров, у них гитхаб после курсов забит до отказа. Станете в каждый вчитываться?
A>А теперь нужно оценить кандидата, что он: A>1. Будет хорошо выполнять свою работу A>2. Адекватный по общению A>3. Замотивирован A>4. Обладает нужной квалификацией A>Как это сделать?
Так, ну 1 требует 4, поэтому остаётся только 3 требования.
Что такое адекватность и мотивация в Вашем понимании -- никто не знает. Уточните. А лучше наверное просто общайтесь с кандидатами и поймёте сами.
Здравствуйте, blacktea, Вы писали:
B>Я собеседование делил на два этапа, первый этап — фильтрация тех, кто вообще абсолютно не умеет кодить (а таких, к сожалению, очень много). Давал пару очень простых задач (не олимпиадных) на кодирование в онлайн IDE.
Скорее тех, кто не хочет решать твои задачи. Не надо свой синдром самозванца на других распространять.
Здравствуйте, blacktea, Вы писали:
B>Ну да, я же говорю, это еще и замечательный фильтр от таких вот персонажей, с такими я точно не сработаюсь, так что, все правильно.
Персонажей, которые не хотят прогибаться под очередные рога и копыта, которые возомнили себя гуглом?
Здравствуйте, IncremenTop, Вы писали:
B>>Ну да, я же говорю, это еще и замечательный фильтр от таких вот персонажей, с такими я точно не сработаюсь, так что, все правильно. IT>Персонажей, которые не хотят прогибаться под очередные рога и копыта, которые возомнили себя гуглом?
Вне зависимости от, тут он таки прав: надо подбирать в команду людей, с которыми таки сработаешься. Потому как делать в команде лебедьракощуку — себе дороже.
A>А теперь нужно оценить кандидата, что он: A>1. Будет хорошо выполнять свою работу A>2. Адекватный по общению A>3. Замотивирован A>4. Обладает нужной квалификацией A>Как это сделать?
Разговори кандидата и пусть расссказывает что, как и почему он делал на прошлой работе. Задавай уточняющие вопросы, чтобы рассказывал в деталях, что именно он делал, какие принимал решения и почему. За 15-20 мин поймешь, кто перед тобой и как он работает и что знает и умеет.
A>Должен ли я создавать какой-то образ компании/продавать вакансию?
Не должен.
A>Или просто уважительно общаться, рассказать про задачи, команду, проект, стек.
Это 5 мин вначале интервью, чтобы представится самому и представить контору.
A>Как-то смотрел видео для hr'ов. Увидел понятие "профиль кандидата".
У этих своя религия со своими догмами, священниками и т.п.
Хуже варианта, чем ударится в их религию ты выбрать не сможешь.
A>Похоже, мне предстоит составлять такие профили.
Но тем ни менее разумно после собеседования записать свои мысли и то что думаешь о том, кого прособеседовал. Это поможет выбрать кандидата из нескольких.
Здравствуйте, C0s, Вы писали:
C0s>сегодня утром я получил через линкед-ин приглашение вида "мы компания такая-то, не хотите ли проинтервьюировать нас, чтобы решить, есть ли пространство для возможного сотрудничества, мы постараемся вам понравиться" (не дословно, но примерно в этом духе). сижу теперь, размышляю, куда же всё катится.
Что только не придумают, лишь бы в первом же письме просто не написать название компании, адрес офиса и предполагаемый оклад.
Здравствуйте, Miroff, Вы писали:
M>Интерфейс вместо реализации это примерно 1% всего дела. Гораздо интереснее когда и как создается, собственно, реализация. В случае Java Spring, он читает аннотации на полях классов и пытается угадать, какой конкретно экземпляр и какой имплементации интерфейса будет уместен для каждого поля. А потом создает и инициализирует эти зависимости. С учетом того что зависимости мало того что образуют граф, так еще и в этом графе могут быть циклы. Сдизайнить такое на пальцах, ну такое себе развлечение.
А если неправильно угадал, то падает и весело говорит "угадайте где!"?
Здравствуйте, kaa.python, Вы писали:
KP>Звучит так себе. Я вообще крайне против неявной конфигурации чего бы то ни было. Если лимитировать IoC только в рамках замены подобного кода (утащил отсюда)
Спринг начинал с явной конфигурации в XML файлах. Получалось плохо, эти XML файлы становились еще той головной болью из-за того что корректность конфигурации толком не проверяется во время компиляции. Сейчас IDE умеют отлавливать простейшие ошибки, но только в самых примитивных случаях.
KP>то идея более чем здравая и активно используется и в C++, и в Go. Но вот делать неявную инициализацию конфигурации уже ведет к проблемам. Так же сам факт наличия неявной конфигурации говорит о том, что подобным подходом злоупотребляют на столько, что разрешить зависимости явно становится не возможным, иначе зачем она нужна?
Если ты делаешь явную инициализацию в коде ты просто смещаешь проблемы на уровень выше. Кто создаст экземпляр IocSpellChecker? Вызывающий код? Непосредственно main()? Какой-то глобальный registry/factory? В любом случае где-то в коде у тебя заведется куча бойлерплейта по инициализации сервисов. И тебе придется в этом месте руками тасовать вызовы чтобы обеспечить правильный порядок инициализации. А потом тебе придется протаскивать эти сервисы везде, где они требуются:
class ServiceRegistry {
ServiceRegistry() {
initializeApplicationPropertiesService()
if (applicationProperties.get("spellcheker.enabled")) {
initializeRealSpellChecker()
} else {
initializeDummySpellChecker()
}
}
}
class MainWindow {
MainWindow(ServiceRegistry registry) {
new TextField(registry.acquireSpellChecker())
}
}
Особенно весело становится, когда тебе требуется конфигурируемое в рантайме приложение. Скажем, спеллчекер может быть как встроенный, так и внешний интернет сервис, или эта фича может быть вообще отключена и менять это нужно без перезапуска приложения. Причем если внешний сервис оказывается недоступен, то должен срабатывать автоматический откат до dummy implementation.
Не то чтобы это все нельзя было сделать врукопашную явным способом, но в какой-то момент возня с инициализацией начинает занимать большую часть времени разработчика. Чтобы этот момент немного отсрочить и придумали спринг.
Здравствуйте, Miroff, Вы писали:
M>Если ты делаешь явную инициализацию в коде ты просто смещаешь проблемы на уровень выше. Кто создаст экземпляр IocSpellChecker? Вызывающий код? Непосредственно main()? Какой-то глобальный registry/factory?
Да, вызывающий код создаст. Да, непосредственно в main() создаст.
M>В любом случае где-то в коде у тебя заведется куча бойлерплейта по инициализации сервисов. И тебе придется в этом месте руками тасовать вызовы чтобы обеспечить правильный порядок инициализации. А потом тебе придется протаскивать эти сервисы везде, где они требуются:
А вот тут уже интереснее. А почему у тебя в коде "куча бойлерплейта по инициализации сервисов"? Может быть потому, что у тебя приложение слишком много задач выполняет? А может быть его тогда стоит на независимые куски попилить, вместо того что бы сложно конфигурировать? А куски будут на основании оговорённых протоколов общаться, и проблема с конфигурацией отпадёт.
M>Особенно весело становится, когда тебе требуется конфигурируемое в рантайме приложение. Скажем, спеллчекер может быть как встроенный, так и внешний интернет сервис, или эта фича может быть вообще отключена и менять это нужно без перезапуска приложения. Причем если внешний сервис оказывается недоступен, то должен срабатывать автоматический откат до dummy implementation.
Это более чем нормально, до тех пор пока приложение содержит в себе 2-3, ну может быть 5 таким образом конфигурируемых сервисов.
M>Не то чтобы это все нельзя было сделать врукопашную явным способом, но в какой-то момент возня с инициализацией начинает занимать большую часть времени разработчика. Чтобы этот момент немного отсрочить и придумали спринг.
Но есть и альтернатива — провести декомпозицию и упростить приложения.
Здравствуйте, vsb, Вы писали:
vsb>На самом деле ничего сложного, если не переизобретать спринг. vsb> ... vsb>Такой паттерн позволяет делать DI с произвольным графом зависимостей. afterPropertiesSet должен проверить все требуемые свойства. Паттерн абсолютно "тупой", можно руками делать, выключив мозг, можно через рефлекцию или кодогенерацию.
Более того, можно кидать конкретное исключение, если найден цикл зависимостей. Хотя на практике обычно IoC-авторы не заморачиваются и кидают инфу про исходный класс, а не про весь цикл. Далее включаешь дедукцию "а что ж недавно поменялось" и находишь причину.
Здравствуйте, Mr.Delphist, Вы писали:
MD>Более того, можно кидать конкретное исключение, если найден цикл зависимостей. Хотя на практике обычно IoC-авторы не заморачиваются и кидают инфу про исходный класс, а не про весь цикл. Далее включаешь дедукцию "а что ж недавно поменялось" и находишь причину.
Нет никаких проблем в цикле зависимостей. Проблема это когда зависимости инициализируются через конструктор. А так в моём примере два цикла зависимостей. Глупый запрет.
Здравствуйте, Lexey, Вы писали:
L>Не, это ты, видимо, не понимаешь, что это все прекрасно делается без IoC-контейнеров. Которые, как правило, ничего кроме головной боли не добавляют.
Просто ты не умеешь их готовить
Тё>>и за все плохое, aka кусок связанного явными вызовами кала.
L>Кал получается, когда IoC-контейнеры начинают пихать во все дырытуда, где можно спокойно обойтись явным созданием зависимостей в main с последующим их явным пробросом по иерархии.
Здравствуйте, kaa.python, Вы писали:
KP>loose coupling не имеет ничего общего с неавной инициализацией, в то время как extensibility от неявной инициализации только страдает.
IoC — про декларативное описание зависимостей. Что куда более явное, чем простыни говнокода ручной инициализации.
KP>Да, считаю polymorphism изжившим себя подходом.
Inheritance vs Composition. IoC- про composition.
KP>Любовь джавистов наплодить абстркций и конфигураций ради самого процесса, а не результата, мне всегда казалось странной
Результат — чистый, поддерживаемый, расширяемый код.
Здравствуйте, Тёмчик, Вы писали:
Тё>IoC — про декларативное описание зависимостей. Что куда более явное, чем простыни говнокода ручной инициализации.
Задумайся о том, откуда у тебя столько зависимостей, что тебе нужен аж целый фреймворк для их инициализации и декларативное описание? Это просто как бы красивый способ спрятать кривой дизайн, который был популярен во времена монолитных монстров. Я допускаю что в корпоративной Java и сейчас так пишут, конечно.
Тё> Inheritance vs Composition. IoC- про composition.
IoC про интерфейсы, вообще-то, но вот наследование и реализация интерфейса не совсем одно и то же. Да, это одно и то же в мире C++, но даже в Java это не так.
KP>>Любовь джавистов наплодить абстркций и конфигураций ради самого процесса, а не результата, мне всегда казалось странной Тё>Результат — чистый, поддерживаемый, расширяемый код.
Нет, в результате у тебя есть гора абстракций и вечно тормозящее приложение, а не "чистый, поддерживаемый, расширяемый код"
Здравствуйте, Тёмчик, Вы писали:
Тё>Т.е. ты против всего хорошего, aka loose coupling
О! А можно на примере показать, как DI помогает loose coupling? Пусть вот у нас есть уже упомянутый SpellChecker. Точнее нет, у нас их три:
class RealSpellChecker implements SpellChecker {
}
class CachingSpellChecker implements SpellChecker {
public CachinSpellChecker(SpellChecker peer, long cacheSize) {
}
}
class MetricsSpellChecker implements SpellChecker {
public MetricsSpellChecker(SpellChecker peer) {
}
int getCallCount() { return 1; }
int getGrammarErrorCount() { return 42; }
}
Где и как предлагается описывать, какой их них в кого вкладывается? В самих классах в виде аннотации Named? Там это loose coupling нарушается самым криминальным образом. Классы вместо независимых становятся привязаны к их месту в структуре приложения. В фабриках? Так ручная инициализация в main будет понятнее. В реальной жизни я еще могу иметь несколько экземпляров SpellChecker (разные языки) и вокруг них разные обертки.
Ну и вопрос со звездочкой. Изобразить на DI цепочку MetricsSpellChecker->CachinSpellChecker->MetricsSpellChecker->RealSpellChecker. Две обертки в MetricSpellChecker, на разных уровнях. Может я хочу эффективность кэша посчитать по-простому .
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Стоит описать вакансию, кого и какого уровня ты хочешь нанять.
Как-то смотрел видео для hr'ов. Увидел понятие "профиль кандидата".
Мысль была такая, что всегда хотят нанять человека, который супер синьор, всё умеет.
Что задача hr'а как раз уточнять что требуется, в каких количествах и на каком уровне.
Может оказаться, что вполне и middle справится и кучу всего на входе можно и не знать.
Похоже, мне предстоит составлять такие профили.
Здравствуйте, blacktea, Вы писали:
B>фильтрация тех, кто вообще абсолютно не умеет кодить (а таких, к сожалению, очень много). Давал пару очень простых задач (не олимпиадных) на кодирование в онлайн IDE.
Как эти очень многие абсолютно не кодят на прошлых местах и их последнем месте работы?
Здравствуйте, blacktea, Вы писали:
B>ЗЫ: я заметил, что тут прям очень не любят тестовые задания, считай, что это как раз фильтр для твоего п.3, насколько сильно человек хочет работать у вас
А теперь представь, что "hr бренда" нет. Компания небольшая.
Я также слышал что не каждый переваривает тестовые. Люди могут просто пролистывать дальше вакансии заметив тестовое.
Т.е., по идее, нужно расширить hr воронку. Но и в конце взять именно нужного. И не тратить много времени.
Здравствуйте, CreatorCray, Вы писали:
CC>Чот сразу вспомнилось: Работать в нашем банке — большая честь
Интересная запись) Как выявить мотивацию? Как ты понимал, что устраивается человек ради пунктов 1,2,3 и не из-за пунктов 4,5,6?..
И можно ли её повысить при общение? С клоунским носом задорно рассказывая про проект.
Или у человека есть текущий период времени жизни с текущей мотивацией, демотивацией, жизненными разрешенными, неразрешенными ситуациями и ты никак на это не повлияешь?
Здравствуйте, Тёмчик, Вы писали:
Тё>Как эти очень многие абсолютно не кодят на прошлых местах и их последнем месте работы?
Да, я там забыл упомянуть в исходном посте, что мы искали фронтендера уровня junior или middle. То есть, приходили люди с околонулевым или небольшим опытом. Думаю, для хороших миддлов и сеньеров такой фильтр скорее всего не нужен.
1) выставляете вакансию
всем кандидатам задаете вопрос когда готовы приступить
загоняете в foreach random на требуемое количество
отобранным даете оффер
через 3 месяца
если все ок, поиск завершен
с теми кто не проявил себя — прощаетесь, goto 1
Здравствуйте, avovana, Вы писали:
A>Как-то смотрел видео для hr'ов. Увидел понятие "профиль кандидата". A>Мысль была такая, что всегда хотят нанять человека, который супер синьор, всё умеет. A>Что задача hr'а как раз уточнять что требуется, в каких количествах и на каком уровне. A>Может оказаться, что вполне и middle справится и кучу всего на входе можно и не знать. A>Похоже, мне предстоит составлять такие профили.
Ничего не понял. Обычно есть Х вакансий, каждая из них предполагает определенный уровень и набор знаний кандидата. Иногда их бывает несколько и собеседуемый может планироваться на них. Но это все равно ограниченный набор. Так что тебе прежде всего стоит понять кого ты ищешь. Без этого смысла в технических собедедованиях немного.
Здравствуйте, tony_wonder, Вы писали:
_>Если только Вы не автор какой-то умопомрачительной и известной на всю отрасль штуковины. Но в этом случае наверное берут безо всяких собеседований.
Разишо если только компания пилит что то именно на этой штуковине.
Если что то хоть и известное но сбоку то пофигу.
Здравствуйте, CreatorCray, Вы писали:
CC>Впрочем можно понять способен ли кандидат хотя бы инженерно мыслить, что является весьма важным критерием для того чтоб быть разработчиком а не stack-overflow-copypaster. CC>Я для такого даю простую (элементарную даже) техническую задачку,
Из недавнего, после как кандидат рассказал про springboot и упомянул IoC, предложил на пальцах задизайнить инжектор, как бы он реализовал, какие структуры и т.п.
Чел позиционировал как синьер, инжектор не задизайнил (сразу сдался), и потом отклонил офер на мидла (на синьера не дотягивал).
Здравствуйте, Тёмчик, Вы писали:
Тё>Из недавнего, после как кандидат рассказал про springboot и упомянул IoC, предложил на пальцах задизайнить инжектор, как бы он реализовал, какие структуры и т.п. Тё>Чел позиционировал как синьер, инжектор не задизайнил (сразу сдался), и потом отклонил офер на мидла (на синьера не дотягивал).
аххаха, Тёмчик задаёт сеньёру вопросы для мидла, а потом удивляется что его нахрен посылают. Чувак, я дизайнил иок контейнеры вдоль и поперёк ещё в крестах(!) 15 лет назад, когда это было модно, а в крестах, вследствие отсутствия внятной поддержки рантаймом метаинфы ещё и молодёжно, но я тебя уверяю, что сейчас я бы хрен что на собеседовании написал, и скорее всего просто покрутил бы пальцем у виска в сторону собеседующего. Впрочем, я понимаю что тебе ничего не докажешь, т.к. ты Тёмчик.
Здравствуйте, tony_wonder, Вы писали:
A>А теперь нужно оценить кандидата, что он: A>1. Будет хорошо выполнять свою работу A>2. Адекватный по общению A>3. Замотивирован A>4. Обладает нужной квалификацией A>Как это сделать?
_>Так, ну 1 требует 4, поэтому остаётся только 3 требования.
Пункт 4 — необходимое (однако, ещё не достаточное) условие для пункта 1.
Так, например, обладание квалификацией — ещё не гарантия, что работник не наркоман/пьяница.
При этом, ИМХО, пункт 2 — скорее всего не выявит никаких отклонений. Если конечно же не брать крайние случаи.
Что касается мотивации, бывают случаи, что она не коррелирует со skill-set-ом кандидата.
Здравствуйте, Тёмчик, Вы писали:
Тё>Из недавнего, после как кандидат рассказал про springboot и упомянул IoC, предложил на пальцах задизайнить инжектор, как бы он реализовал, какие структуры и т.п. Тё>Чел позиционировал как синьер, инжектор не задизайнил (сразу сдался), и потом отклонил офер на мидла (на синьера не дотягивал).
А что такое IoC? Это интерфейс скормить, вместо реализации?
Здравствуйте, avovana, Вы писали:
A>В ближайшем будущем, возможно, буду нанимать в свою команду. A>Должен ли я создавать какой-то образ компании/продавать вакансию?
сегодня утром я получил через линкед-ин приглашение вида "мы компания такая-то, не хотите ли проинтервьюировать нас, чтобы решить, есть ли пространство для возможного сотрудничества, мы постараемся вам понравиться" (не дословно, но примерно в этом духе). сижу теперь, размышляю, куда же всё катится.
Здравствуйте, C0s, Вы писали:
C0s>сегодня утром я получил через линкед-ин приглашение вида "мы компания такая-то, не хотите ли проинтервьюировать нас, чтобы решить, есть ли пространство для возможного сотрудничества, мы постараемся вам понравиться" (не дословно, но примерно в этом духе). сижу теперь, размышляю, куда же всё катится.
Достаточно многие наёмщики сейчас примерно так пишут.
Здравствуйте, Vzhyk2, Вы писали:
A>>Похоже, мне предстоит составлять такие профили. V>Но тем ни менее разумно после собеседования записать свои мысли и то что думаешь о том, кого прособеседовал. Это поможет выбрать кандидата из нескольких.
Слышал, что после нескольких интервью, после вопросов кандидата и составления своего впечатления, сам лучше понимаешь кого тебе надо на позицию
Здравствуйте, CreatorCray, Вы писали:
CC>Вне зависимости от, тут он таки прав: надо подбирать в команду людей, с которыми таки сработаешься. Потому как делать в команде лебедьракощуку — себе дороже.
Видел задорные менеджерские заметки, что чем разношерстней команда, тем лучше.
Что ошибка менеджера искать точно такого же как он. Не будет разных мнений. Что плохо.
Здравствуйте, Miroff, Вы писали:
KP>>А что такое IoC? Это интерфейс скормить, вместо реализации?
M>Интерфейс вместо реализации это примерно 1% всего дела. Гораздо интереснее когда и как создается, собственно, реализация. В случае Java Spring, он читает аннотации на полях классов и пытается угадать, какой конкретно экземпляр и какой имплементации интерфейса будет уместен для каждого поля. А потом создает и инициализирует эти зависимости. С учетом того что зависимости мало того что образуют граф, так еще и в этом графе могут быть циклы. Сдизайнить такое на пальцах, ну такое себе развлечение.
На самом деле ничего сложного, если не переизобретать спринг.
var myClass1 = new MyClass1();
var myClass2 = new MyClass2();
myClass1.setMyClass1(myClass1);
myClass1.setMyClass2(myClass2);
myClass2.setMyClass1(myClass1);
myClass1.afterPropertiesSet();
myClass2.afterPropertiesSet();
Такой паттерн позволяет делать DI с произвольным графом зависимостей. afterPropertiesSet должен проверить все требуемые свойства. Паттерн абсолютно "тупой", можно руками делать, выключив мозг, можно через рефлекцию или кодогенерацию.
Здравствуйте, Mr.Delphist, Вы писали:
MD>Более того, можно кидать конкретное исключение, если найден цикл зависимостей.
Это стоит отдельного вопроса на засыпку. Если кандидат быстро рассказал про инжектор, и осталось время неиспользованное. Еще вопрос на засыпку- как инициализировать зависимости параллельно (а не цепочкой).
Здравствуйте, Ip Man, Вы писали:
IM>Кандидаты отлично мотивируются большими деньгами или их перспективой.
Еще хотелось бы видеть перспективу повышения каждый год.
Растёт экспертиза — растёт вознаграждение.
Слышал про случай, когда человек выбирал работу.
1ый вариант с бОльшими деньгами. Вроде бы, уже на собеседование понял, что с руководителем не сможет нормально сработаться.
2ой вариант с меньшими деньгами.
Он выбрал 1ый. Думал, что плохие отношения — это не страшно. По-моему, через пол года уволился. Не смог.
Возникли еще вопросы:
1. У кого-нибудь были такие кейсы?
2. Какая была у вас мотивация сменить работу?
а) Уходили из-за...
б) или стремились к...
в) ...
3. По каким критериям выбирали очередное предложение среди аналогичных?
4. Сколько лет работали на предыдущих местах?
5. Сколько считаете надо?
6. Ваша работа мечты? Где вы хорошо работаете и не собираетесь уходить? Как меня как-то спросили — "что бы тебя заякорило надолго в компании"?
Здравствуйте, blacktea, Вы писали:
B>После, давал тестовое задание, на выполнение которой обычно уходит примерно 2-3 часа и на следующем собесе мы обсуждали его решение. Заранее готовил разные вариации на тему, а что мы будем делать, если требования к этой задачке чуть-чуть изменятся в эту сторону. А что будет, если мы применим тут такой-то паттерн или подход? Представь себе, что у нас появился редкий баг, который сложно отловить, как будем действовать? Ну и все в таком роде.
Вы готовы рассказать это же о себе и своих недавних задачах? Показать пример кода, задачу, коммит?
Здравствуйте, Skorodum, Вы писали:
S>Вы готовы рассказать это же о себе и своих недавних задачах? Показать пример кода, задачу, коммит?
Если нет никаких препятствий в виде NDA, то в пределах разумного, почему бы и нет. Я примерно на такое как-то раз отвечал, но то был переход человека из другого отдела в наш.
