Собеседования⁠⁠

Это ваш код или кандидата? Это же кусок говна.

но вот вы таких и ищете?

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

Вот я и пытаюсь донести до ТС.

Что знать конкретное, не значит уметь решать задачи :))

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

ваши решения на проекте правильные

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

А без гула вообще не выдам никакое решение.

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

При этом срок жизни проекта полтара - два года, работа в одной компании 3-5 лет. Тоесть за 10 лет у вас пяток проектов и знание 2-3 стеков технологий. Совпадение вопросов собеседования на новом месте с вашим опытом будет процентов 20.

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

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

Вы ведёте кандидата? Что я имею ввиду: когда я провожу собеседование то ставлю задачу себе не получить решение, а понять как мыслит. То есть слушаю его, если нужно то подсказываю, конечно не всем и не всегда, но если видно что человек нервничает то можно и подсказать. Пол часа норм, как по мне, у нас задачи были проще, но и времени на 15-20 минут всего.

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

Поэтому я стараюсь избегать существованиея иерархии классов, которые не являются абстрактными.

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

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

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

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

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

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

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

Найм строится по чеклисту, ответил на 80% вопросов - берём. Пусть даже это джун, тупо зазубривший базу, но не имеющий практического понимания применения солид

А вообще интересно бы понять вилку, может там предлагают 150 и ждут мидла с 6 годами опыта

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

Having оператор для фильтрации агрегированных функций или групп.
Я очень хорошо знаю sql, но несколько теряюсь, когда на собеседованиях просят рассказать про какую-нибудь супер-мега-редкую хрень и смотрят хитро - типа знаешь или нет. Вроде "а вы ведь знаете, что такое setseed?" Знаю. Потому что в универе базы данных преподаю, но нахера вам на постоянной основе нужна функция установки начального числа в рэндоме - понятия не имею. Мало того, я вообще сомневаюсь, что существуют некие люди, которые наизусть знают все встроенные функции и операторы всех СУБД. Зачем? Все это обновляется, а искать и читать документацию я умею.

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

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

Почитал, любопытное.

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

- лень и отсутствие мотивации (проводить 1-1, понять статус ситуацию, его цели и обсудить проблему с ним самим)

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

Вы как-то пытались решить? Что пробовали? Правда интересно, не подъебываю. В вашем посте нет ничего о том как вы это пробовали решить. Или вы тогда не были тимлидом?

Два дня назад собеседовал кандидата. Общие рассуждения о сферических конях - легко.

Простейшие примеры в коде - тупик тлен и безысходность.

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

Разумный подход двигаться от простого к сложному. Простое не прошли - не мучаем себя, следующий. У меня нет задачи принять всех косноязычных и убогих, которые ни код не напишут, ни книжку не могут открыть и к интервью подготовиться, ни пример кода разобрать. Зачем мне такие? С ними же работать а не воспитывать их.

Пусть идут в конторы где презирают теорию, где главное как-то написать работающий код и не вникать в детали, где солид это какая-то хуета оторванная от жизни. Культура разработки в разных конторах разная, каждый себе гнездо найдёт.

Опять же задачи везде разные.

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

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

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

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

throw exception ("error description") в разных местах?

Насколько глубокое наследование используете в своих классах?

Прикольно. Если не секрет, какие были вопросы по языку?

Я С++ разработчик и порой вопросы на собесах попадаются типа:

Что такое виртуальное наследование?

Или

Что будет с аллокацией памяти при new A; если конструктор выкинет исключение?

Или мой любимый:

Чем отличается make_shared от конструктора shared_ptr?

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

Понимаю, что у вас скорее всего другой язык, вряд ли вы backend на С++ фигачите, но все-таки интересно.

Бодишоп? Или что-то вроде accenture?

"Половина из них уже в нашей фирме" не могу понять - ты из яндекса, амазона или гугла?

Импортозамещение ПО. Кадров свободных нет.

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

А есть выбор?

Ну так я главный синьор:).

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

Из моего опыта собеседования Джуна:

- Почему ты в цикле использовал int а не например byte?

- эм...ну обычно используют int. В учебниках так

- ок. А чем int отличается от byte?

- эм... ну... я не знаю

А потом пришла его мама, и орала что мы не взяли сыночка потому что он не русский. :)

А сколько времени вы даёте на решение?

+++++:))

Если изучал все языки по немногу.

А писал большое на одном.

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

Это как в любой сфере. Знать хорошо обзорно. А быть докой в одном.

А ТС со своим Солидом всех долбит :)))

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

А не искать конкретно кодера под Солид :))

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

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

Вот Solid это для меня, да и для многих.

Это программа, а не язык :))

Cad/Cam.

Так что думаю так многие на собеседовании и понимали.

Надо ставить и объяснить конкретно, а не хрен пойми что.

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

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

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

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

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

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

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

Тоже склоняюсь, что дело в ЗП.

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

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

Или я вас не так понял?

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

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

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

Я тоже не всегда отвечаю на вопросы по базам. Просто потому, что расхожусь во мнении с интервьюером. И на вопрос, что такое оценка цели по smart без гугла не отвечу, хоть и знаю, про что это.

Ты все праздники без гугления знаешь со всеми переносами выходных?

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

Если вы и с соискателями так же общаетесь, то к вам не надо идти.

Комментарий удален. Причина: Провокации и грубое общение

Вы хоть представляете насколько объемная это была бы работа? Чтобы детально с примерами объяснить недостатки и изъяны. Привести примеры.

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

Научил меня на вопрос "почему?" не отвечать "потому, что". Сложно объяснить кратко. У объективной реальности есть координаты, в которых мы можем попробовать ее оценить. У кода это нефункциональные характеристики. Я не стану использовать что-то "потому, что" это похоже на описание некоего паттерна или принципа или чего-то мнения в интернете. Всегда лишь код и ситуация на проекте могут быть мерила и того, как надо поступить.

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

Да все поняли, что ты очередной мудак

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

Я вот 10+ лет в программировании.

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

Вопросы по SQL? Меня недавно спросили что такое having, я ответил "не помню, применял его последний раз примерно 6 лет назад, что-то про группировку". Если у вас реальные бизнесовые задачи, тем более под нагрузкой, а не решение задачек по SQL, то с большой вероятностью, его применение будет скорее во вред, я уже молчу про дальнейшее сопровождение кода. Для аналитики полезно, но такие задачи встречаю редко.

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

Наследование, инкапсуляция и полиморфизм? Мало кто как молитву его повторяют, чтобы помнить всегда. Да применяю. Но я не лектор в институте чтобы сразу и просто это объяснить, у меня другие сильные стороны, и они не в объяснении.

Индексы? Я знаю про b-tree, и что есть другие. Знаю как правильно их создавать чтобы они использовались. Знаю как проверить. Но абстрактные вопросы для меня сложны.

Тестовое задание? Без гугления и браузере?

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

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

Сумбурно как-то получилось, но надеюсь смог донести мысль.

Мне лень детально пояснять. На Пикабу с телефона только сижу, тем более долго печатать.

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