Рулетка под названием «собеседование»: мысли разработчика о найме

Молодой HR-менеджер приходит с пачкой резюме к директору:
— Очень много заявок, не знаю, как выбрать лучшего...
Директор большую часть пачки выбрасывает в мусорник:
— Не люблю неудачников!

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

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

Игнорирование резюме

Резюме — это возможность познакомиться с кандидатом заочно, подготовиться к собеседованию. Само по себе резюме много может сказать о кандидате, и если работодатель невнимательно относится к резюме, то фактически игнорирует то, как себя хотел представить собеседуемый. Почему это происходит мне тяжело сказать, но факт остается фактом. Часто резюме рассматривается просто как заявка и используется для получения контактных данных кандидата. Были случаи, когда интервьюер прямо заявлял, что резюме не читает, и все узнает на собеседовании.

Задания и задачи

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

Тип мышления кандидата. Мышление бывает быстрыми и медленными. У каждого из типов есть свои преимущества и недостатки. И при решении задач в реальном времени выигрывают те кандидаты, у кого преобладает быстрый тип мышления. Однако при решении сложных задач, требующих погружения в детали и логических построений медленный тип мышления имеет преимущества. Человек, проводящий собеседование, может даже не задумываться о том множестве вариантов и деталей, которые возникают в мозгу «медленного» кандидата. Со стороны задержка с ответом выглядит так, как будто кандидат тупит, и его привлекательность в глазах работодателя понижается.

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

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

Вопросы о мелких деталях

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

Таким образом, задавая вопросы о деталях, например, порядок параметров, передаваемых в функцию, вы фактически тестируете оперативную память кандидата, а не его квалификацию и умение думать. С другой стороны, это опять игра в рулетку, так как знания кандидата и интервьюера полностью не пересекаются. Если заданный вопрос попал в область знаний собеседующегося, то «бинго!», ну а если нет...

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

Soft skills

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

Умение учиться

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

Набор ценностей

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

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

Выводы

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

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

LinkedIn

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

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

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

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

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

116 комментариев

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

А я вижу это так:

На собеседовании человек испытывает стресс

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

Тип мышления кандидата.

Имеешь эффективный (не важно какой) тип — покажи его и его результат на интервью.

Формулировка задачи.

Клиент тоже бывает не изобилует словоблудием. Тоже этот навык развивается — оперирование смыслами в условиях нехватки информации.

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

Конечно, можно руководствоваться и другими принципами — если человек где-то работал N лет и его там держали — значит приносил пользу.

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

Девушку случайно не Мария зовут?

...эту девушку звали Альберт Эйнштейн

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

Способ только один — посмотреть на работу того человека в течении 3-х месяцев или дольше.
Всё остальное фантазии и предположения и ничего более.

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

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

Оба комментария выше make perfect sense.
У себя хотим попробовать вариант тест-драйва — посадить соискателя на месте так сказать на пол дня или день, дать простое задание, посмотреть как делает. Время оплачивается. По идее должно позволить без обязательств и длительного онбординга позволить кандидату «рассмотреть» нас, а нам — его.

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

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

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

Вот посему выгоднее взять на испытательный, если на собеседовании подошел с большего. А если не справляется, то и через 3 дня уволить можно без проблем. Или вы с ним сразу будете контракт со штрафными вам санкциями сразу на 5 лет подписывать?

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

То что рулетка — это давно известно. На собеседовании решение об отказе или найме принимается в первые 3 минуты общения с тобой и исключительно эмоционально и никак более.
Все остальные часы — это ИБД и ничего более (иногда еще вариант сбросить твои запросы по зарплате, но это редко).

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

Чтобы понять, как ты работаешь и что умеешь, нужно хотя бы 3 месяца с тобой поработать.

Браво!
Согласен по всем пунктам.
Отличный материал.

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

Всі ллють воду та булщитять про очевидні речі, і ніхто не дає анекдотичних прикладів.

Більше людяності kurwa matj, на всю портянку одна тухла історія про дівчинку якій ніхто не розказав що бізнесу треба продукт видавати а не код.

Дізлайк, відписка.

С очень многими вещеми не согласен категорически как человек, проведший более сотни собеседований. Автор ударяется в перфекционизм и рассуждает на тему «как можно было бы», не думая о том, что культура проведения интервью в Украине сильно отличается от культуры проведения интервью в США.
Ключевой момент: у нас на интервью отводится 1.5..2 часа максимум, а в идеале — хорошо бы уложиться в полчаса-час.
В гуглах, фейсбуках и т.д. на собес отводится день + несколько прескринингов до этого.
Соответственно, разные задачи.
Там: узнать как можно больше о кандидате: в какую команду его лучше определить, сможет ли он влиться в корпоративную культуру ну и т.д.
Тут: понять квалификацию кандидата за отведенное время. Да, хорошо бы выяснить его мотивацию, софт-скиллы и т.д., может быть даже сходить с ним на обед, чтобы уменьшить стресс — но на это попросту нет времени.

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

Фразу «нет времени» я обычно перевожу как, например «не очень важно». В ситуации когда нужно «перепродать» человека заказчику, так и есть, главное, что это middle одна штука. Так что Вы абсолютно правы!

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

Я проходил как-то собеседование Intellias, скажу, что было много ошибок, которые здесь описал автор :)

У мене теж склалося таке враження :)
Описав свій досвід: jobs.dou.ua/...​/intellias/reviews/#38892

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

Согласен по данной статье.

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

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

Можно задавать вопросы на понимание и соображалку. Например, в С++ чтобы класс В использовал функционал класса А, есть (как минимум) следующие варианты (забудем про шаблоны):
* В наследуется от А
* В содержит А по значению
* В содержит А по ссылке
* В содержит А по указателю
Какая на практике разница между этими вариантами? Какой из них когда лучше использовать?

Да, у кого-то хуже с теорией — тогда можно расспросить о проектах, предложить практические задачки. Например: есть телефонная трубка (на старом ARM), на ней меню с иконками. Если очень быстро нажимать кнопку прокрутки меню несколько секунд, а потом зайти в телефонную книгу — прошивка падает. Как отлаживать проблему.

Какая на практике разница между этими вариантами? Какой из них когда лучше использовать?

ты ещё забыл глобальную переменную синглотон и dependency injection ))

Ага, а кому после этого такой код читать?

а угадай ))

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

... пишут значит функцию

объект-модель.ВернутьСписокОбъектов()

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

объект-модель.ВернутьОбъектПоИмени(имя)

— которая соотв. возвращает объект уже по имени уже из списка... стоп. Но ведь объект-список у нас уже есть так почему же ж это функция не его но #внезапно объекта-модели у которой ВернутьСписокОбъектов() _уже_ есть!?

Не знаю какое «понимание соображалку» ты имеешь в виду лично я крайне редко встречал за последних лет 5 2 раза... нет точно 3 раза и двое из них были не программисты но вполне перспективные ребята пониманию и соображалке которых я реально сильно удивился и реально респект просто потому что в работе реально профитЪ и просто приятно реально приятно иметь дело с реально умными людьми с реально пониманием и соображалкой.

Всё остальное ни разу от слова вообще.

ЗЫ: ок был ещё +1 индус тоже неплохой парень к.м.к.

Меня достает то, что с ООП часто дольше тупишь, как правильнее сделать, чем кодишь. Поэтому пускай себе будут оба метода, если интерфейс еще не раздулся до безобразия. Потом можно отрефакторить.

понимаешь ли какая проблема ООП имеет крайнюю ценность именно в мышлении уже структурированном не проблема сделать по-бустрому так тоже можно и даже нужно проблема _не_ понимать а дело именно в _непонимании_ вот конкретно на ту тему я думал там проект окончательно развалится в обычный говнокод только к лету а он #внезапно сполз или точнее провалился туда уже буквально за пару недель просто говнокодеры таки начали кодить до того получилась одна фишка которая от говнокода их ужерживала фишка кончилась я таки успел заметить и сказать «оп-па такими темпами мы к лету уже...» а оно оп-па и стало сильно быстрее так ))

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

)))
www.laputan.org/mud
Ну и я не совсем верю в ООП — скорее в паттерны, а они на уровне модулей, то есть — выше.

полиморфизм наследование агрегация и есть «паттерны ооп» ))

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

большую часть паттернов можно успешно использовать в роли антипаттернов)

можно и гвозди лбом забивать :) сути это не меняет

если у вас всегда получается одна и та же схема — это очень скучная область

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

и из-за этого существуют 100+ паттернов)))

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

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

ОК, мне приходилось видеть следующие системы:
* Трубка радиотелефона с несколькими килобайтами оперативки и цветным экраном
* База радиотелефона с 2 киловордами (нет побайтовой адресации), поддержкой 6 трубок и линии
* Обработка видеопотока с данными о глубине с целью распознавания людей на нем
* Высоконагруженный поисковый движок по базе данных с постобработкой выдачи
* Движок браузера
Их можно свести к одному и тому же?
Каждая из них может быть написана без экспериментов и сюрпризов?
Креатив вреден? Предложи для них общее решение?

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

уже решалась и имеет правильные и неправильные решения

под NDA какой-то крутой забугорной конторы)

найдется похожая задача из другой области

предложишь, как именно искать похржую?

не значит что будет какой-то креатив, всегда есть вариант на собирание «телевизора» без инструкции

за это умение в ИТ и платят

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

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

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

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

ИМО — обучение это когда ищешь, как, а креатив — когда придумываешь, как. Часто информации нет, так как узкая, закрытая или новая область. Тогда нужно придумывать.

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

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

Вот я 8 лет назад делал радиотелефонную базу на С, предварительно все распланировав (по водопаду), сейчас — на недо-С++ наскоком, и какой из них лучше — так и не понял. В чем-то на С быстрее, в чем-то С++ окупается.

Есть 2 заскока: у С функции с 100500 параметров на 100500 строк кода,
у С++ безумие с ООП абстракциями, наследованиями и инкапсуляциями и т.п.

Оба одинаково вредны.
Всё упирается в того, кто код пишет.

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

а я — не избегаю. не привык)
и автотестов нету)

а я — не избегаю. не привык)

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

и автотестов нету)

Это че за хрень?

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

У меня size matters

Это че за хрень?

Как раз для алгоритмов оно полезно — проверить, что все считается, как хотели, или как раньше. А для логики — ставим 100500 ассертов и отдаем помучать тестировщику.

У меня size matters

Это че?

Как раз для алгоритмов оно полезно — проверить, что все считается, как хотели, или как раньше. А для логики — ставим 100500 ассертов и отдаем помучать тестировщику.

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

Это че?

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

А вот я ассерты не люблю, не зашли они мне

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

Ассерты хороши

Но они же по дефолту только в дебаге.

Ну типа большую прогу в железку пихать дорого (флеша мало).

Там где мало большую ты и не запихаешь.

Но они же по дефолту только в дебаге.

обычно свой ассерт пишется, и включаешь его в релизе тоже wiki.c2.com/?OffensiveProgramming

Там где мало большую ты и не запихаешь.

Вот если использовать много темплейтов, то в маленькую не влезет. Народ говорил, что когда выпилили C++ STL и исключения из проги, управляющей настройками роутера, прошивка уменьшилась на 3 МБ, кажется. Для сравнения, ядро линукса там занимает 5 МБ. Что-то такое, может, неточно, но порядок видно.

что когда выпилили C++ STL и исключения из проги

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

обычно свой ассерт пишется

А лень?

А лень?

#define ASSERT(x) if(!(x)) assert_fail(#x, __FILE__, __LINE__);

void assert_fail(const char* description, const char* file, unsigned line) {
// Strip path stackoverflow.com/...​ile-macro-shows-full-path
const char* const namestart = strrchr(file, ’/’);
if(namestart && *(namestart + 1))
file = namestart + 1;

vsyslog(0, „ASSERT (%s) at %s:%d”, description, file, line);
abort();
}

Якщо просити виконати неоплачуване тестове завдання, то відмовиться, думаю, переважна більшість Senior-спеціалістів.
Оплачуване? У моїй практиці не було жодної компанії, яка просила б виконати тестове і була б згодна його оплатити. Щоправда, був випадок, коли компанія організувала workshop на пару днів й оплатила переліт у Київ, назад і проживання в готелі. Але це було ще і знайомство з потенційним замовником.

Думаю, питання на співбесіді — це не завжди погано. Важливо, як інтерпретувати відповіді кандидата. По кожній області з тих, які потрібні у вакансії і з якими працював кандидат, я задаю декілька базових питань (на які нереально не відповісти, якщо з тим працювали) і декілька на глибину досвіду. Але не очікую, що дадуть відповідь на всі питання, що перевіряють глибину досвіду. Достатньо на хоч якісь. Ну і на всі або майже всі з базових.

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

33 раза: ХА-ХА-ХА!!!
Практика по iOS стриму показывает что спрашивают всю херню миру о которой только слышал лид. Однако несколько раз на собеседованиях я просил показать 2-3 проекта как пример того что компания делает. Ииииии, наберите воздуха поглубже (как говорил один принявший ислам северный йюморыст). А не было в тех проектах ничего и близкого, о чем спрашивали эти господа (Custom UI animations, CoreData, жесткая многопоточность, tests coverage). Стандартные «тонкие» мобильные клиенты, запрос-обработка действий юзера-ответ. На вопрос, а к чему тогда было «вот это вот все», предпочитали уходить от ответа.

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

Я сомневаюсь, что с такими товарищами можно сварить нормальную кашу.

нужен топор

(недословный пересказ F.A.Q. по партнерке какого-то букшопа)
«некоторые люди настолько не любят идею, что на их рефералах кто-то заработает комиссию, что все ссылки, которые могут быть партнерскими, копируют в буфер обмена а потом открывают в приватном окне браузера»

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

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

Вы упустили слово «чрезмерный» ;) Лично я за то, чтобы перфекционизм был. Но не следует забывать и про другие факторы. Когда необходимо в срок решить задачу, а вместо этого наводится «красота» (а для каждого красота может быть своя), то возникает конфликт. Именно о такой ситуации я и написал. Как писал Парацельс: «Всё есть яд и всё есть лекарство; тем или иным его делает только доза»

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

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

Перфекционизм — зло. Из-за него проекты не уходят в продакшн.

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

Лучше переписать, чем умереть не родившись

Та ну... До нього ще дожити треба)

Якщо стратегія — чимскоріш здать і забуть, то я згідний. Але коли мова йде про роботу, а не халтуру, то все сильно міняється.

Рефакторинг и переписывание с нуля это совсем не одно и тоже, особенно когда переписывает уже не ты, и даже не твоя компания)

А я особливо люблю такі проекти — коли перша команда наеджайлила по повній і здриснула, а клієнт залишився з нежиттєздатним франкенштейном на руках.

По-перше, при рефакторинзі дуже простий та очевидний КРІ — було/стало. А по-друге, клієнт вже розуміє, що дешева рибка — погана юшка.

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

Ничего полезного в этом нет, потому что не существует ничего идеального.

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

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

Підтверджую, трапляються рекрутери, яких «умом не понять».

меня вот тоже недавно так нашли, сами написали — а потом на интервью первый вопрос был «почему вы хотите работать именно у нас?» -_-

Або ще так. Пропонують вакансію. Пишеш, що влаштовує і теперішнє місце роботи. Переконують провести ні до чого не зобов’язуючий зідзвон, на якому розкажуть про компанію і вакансію. І під час нього питають: «А чому Ви розглядаєте варіант зміни місця роботи?» )))

Хорошая статья, что для ДОУ большая редкость.
Однако оставляет вопросы. Как например тугодума от перфекциониста отличать? Как за час проверить обучаемость?

Обучаемость можно проверить задав вопрос типа: На каком из последних проектов пришлось учить что то с нуля, и что из этого вышло?

А если мне за 10 лет не пришлось?)))

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

Денис,обучаемость,как компетенция, не всегда может быть оценена сугубо по профильн.скиллам. Субъективно: вижу,что Вы периодически выступаете как ментор/наставничество/+ тайтл лида-это всё подразумевает,что по умолчанию Вы уже самообучаетесь.

Уважаемая тезка, понимаете в чем проблема — тут кагбэ тоже две разные компетенции:
— Человек постоянно вдумчиво читает фундаментальные книги и растет как спец;
— человек по диагонали прочитал две главы из руководства пользователя и уже через два часа педалит код;

Понимаю.Давайте конкретизируем,если Вы не против?Есть тайтл лида (Денис).Рабочих компетенций можно не более,чем 4-5 оценить в ходе интервью.Я могу предположить,что обучаемость-не будет Отдельно выведенной основной компетенцией для лида/ при оценке собственная эффективности параллельно прощупают и обучаемость

обучаемость-не будет основной компетенцией для лида.

Не соглашусь. Если речь идет о более-менее нетипичном и объемном проекте — 100% придется на ходу изучать ряд новых технологий и знакомится с терминологией клиентов и смежников. И именно лид это дело должен организовать и возглавить.

Я выше дописала,её/обучаемость/ могут прощупать в блоке компетенции лида/ собственная эффективность/

Принимает ли гинеколог пациентов на дому? Нет? Тогда «Вы нам не подходите»!!!

Хорошими гинекологами не разбрасываются)

>

Как например тугодума от перфекциониста отличать?

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

и заявленное у всех «хожу в спортзал»

и он присядет 4 подхода по 12?

К сожалению у меня нет на этот вопрос однозначного ответа :( Я спрашиваю как человек учится, какие книги читает. Спрашиваю про конференции, курсы и уже по деталям ответа пытаюсь составить мнение. Тестовое задание помогает понять тип мышления и знания... Но все равно допустить ошибку очень легко. Такие ошибки и подтолкнули меня написать эту статью.

Спрашиваю про конференции

Сподіваюся, в рамках тесту на виявлення бєздєльніков? )

Может перфекциониста отличить если давать короткие задачи на пару минут, которые должны иметь несколько решений, некоторые из решений пометить как перфектные.
Навскидку
Есть массив первых n натуральных чисел, посчитать их сумму

Кто-то сделает циклом for суммирование
Кто-то вызовет какую-нибудь библиотечную функцию arr.Sum() к примеру
Перaекционист выдасn n * ( n + 1 ) / 2

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

Есть массив первых n натуральных чисел, посчитать их сумму

Кто-то сделает циклом for суммирование
Кто-то вызовет какую-нибудь библиотечную функцию arr.Sum() к примеру
Перaекционист выдасn n * ( n + 1 ) / 2

а математик спитає, чи вважаєте Ви 0 натуральним числом

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

Это не перфекционист, а понторез, написать то, что будет доступно не всем, и близко не идеальное решение

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

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

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

В итоге нам пришлось расстаться...

We know that feel, bro!

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

Ще б послухати, що ж то за задача така була. Fizz-Buzz, чи шо? )

Про круглые люки или еще подобная ерунда, которая на практике не нужна.

Работа со строками в С без библиотеки. На 10 строчек кода.

ты злой ((

ЗЫ: один из свежих кодов на ревью пишут что-то в массив потом ищут по индексу конец соотв. \0 terminated ну ок х.з. зачем это может понадобиться читаю дальше а дальше делают типа a[last]=’X’; a[last+1]=’\0′; сирёзный натуральный код люди не осознают массив как строку т.е. то что там какой-то ноль они знают а что это как строка уже нет и соотв. перейти на уровень strcat уже недостижимо.

ЗЫ: даже больше того конкретно по сишным строкам люди в половине случаев не могут осознать «логическую тождественность» «строками си» и «строками си++ std::string» но дальше пошло хуже потому как пришёл си++17 а с ним string_view и теперь в большей половине случаев люди пытаются этот самый string_view либо обрезать нулём либо в более легчей но тоже другой большей половине случаев сперва обрезать «строку си» нулём до «строки си» соотв. с тем чтобы только затем сделать из ней «си++ string_view» посчить концепцию «участка строки от А до Б» людЯм уже не удаётся.

ЗЫ: я сам удивлялся на одном из «митингов» «обсуждение» заняло в общей сумме что-то больше 2-х часов пока до меня наконец дошло что именно вообще «обсуждают» и даже после того как я прекратил споры «экспертным мнением» с одной стороны всё равно пытались оспорить )) а с другой стороны на то чтобы планомерно прекратить писать криво ушло >2 месяца.

Задачі покажуть тільки вміння людини розв’язувати задачі і нічого не кажуть про те як вона буде в роботі.

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

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