Комментарии 28
У автомобиля может быть несколько владельцев. По крайней мере, для РФ это так.
Работаю с MSSQL, MySQL, ORACLE. Почему-то потенциальные работодатели считают, что перейти на работу с POSTGRE* просто нереально.
Кроме того, собеседующие часто забывают, что потенциальный работник тоже выбирает и анализирует работодателя.
Далеко не все задаются вопросом приватности персональных данных: а что делать если мы нашли два адреса по одному ФИО? Мы теперь точно знаем, что один из этих адресов принадлежит другому человеку, можем ли мы показать эту связку?
Ну и получается типичное "угадай, какое число я загадал". Апи это апи, а приватность это приватность. Человек может собаку съесть на проектировании апишек для сервисов типа Miro, но при этом ничего не знать про кухню персональных данных. Кроме того, даже если это кейс из вашей практики, то я просто уверен, что сначала и вы тут шишек набили. А кандидат почему-то должен ответить сразу правильно.
Ну и в целом фокусироваться на предметной области можно только если человек пришел из точно такой же области. Тогда для него знание нюансов - это маст хэв и показатель квалификации. Все остальные же ничем вам не обязаны.
Все, что далее написано, не является руководством к действию, а всего лишь мои личные наблюдения, основанные на собственном опыте.
Тема собеседований сложная и "не всегда" очевидно чем руководствуются компании при принятии решений, поэтому мнение людей ищущих сотрудников ценно и требует проработки. Спасибо за статью!
Извечно спорный вопрос - куда отнести предшествующий опыт, не относящийся к делу, в софт или хард-скилл? На мой взгляд, нет опыта, не относящегося к делу, так как наше настоящее — это результат работы в прошлом. Все же я предпочту называть это софт-скиллом, но не буду оспаривать эту позицию. Чудес не бывает, все имеет причинно-следственную связь
Тоже как то думал куда отнести. Остановился на том, что это софт. По сути это "бэкграунд": как и где человек формировался; устоявшиеся принципы, которые привели в текущую точку.
Первое правило собеседования:
Никогда не проводи собеседование в одиночку. Всегда должно присутствовать минимум 3 человека, например, 1 HR и 2 технических специалиста. По итогам каждый из них должен высказать своё мнение о кандидате. Если хотя бы 1 человек выступает против, то кандидату нужно отказать. Если всем трём кандидат понравился, то надо его брать на испытательный срок.
Я бы начинал не с технологии/фреймворка, которая больше всего нужна мне, а с той, где кандидат считает себя наиболее сильным. Так больше шансов получить предметную дискуссию
Если берем на проект, и там Rest и SQL-база, пусть кандидант явно или нет выберет начальную тему для проверки hard-скилов.
Также полезно вначале рассказать о своем проекте, и потом попросить кандидата в своем опыте выделить что-то похожее, и начать разговор в этой области
Бонусом вы будете проверять следуюшие софт скилы: как кандидат может рассказывать об известной ему теме (свой опыт он точно знает), описывать архитектуру разработанных решений, слушать и реагировать на инфу (если задавать вопросы с референсом на то,что собеседующий рассказал ранее)
Акцеет на то, что вот надо мне вот это - повышает риск, что промажете
И еще момент. Постановки задач в общем от собедующего часто выглядят для кандидата как идиотские. Объясню. Мне задают вопрос. Потом уточняют, потом дают вводные. Еще и еще.Потом говорят, ты не нашел правильное решение, или не оптимальное. Прикол в том, что часто собеседующий знает больше контекста и задав общий вопрос (плюс свой контекст), а кандидат видит только вопрос (ну и свой другой опыт). В итоге ты о сладком, а я о длинном :)
Момент с базой авто, и нарушением какой-то нормализации я лучше просто опущу. Яркий пример, который как раз это иллюстрирует :)
Очень странно и скомкано выглядит последний пункт про книги. Хотелось бы подробностей, почему вы считаете, что книги это лучший из возможных форматов получения знаний? Чем хуже курсы, статьи или видео?
Я не в коем случаи не принижаю пользы от статей или курсов. Я просто хотел подчеркнуть пользу книг. Мне кажется нельзя сравнивать книги со статьей. С курсами еще можно. Как правило в книгах гораздо глубже раскрывается тема, более того книги проходят сложную многоуровневую редакцию. Но тут конечно важно выбирать хороший книги. Я Вам очень рекомендую почитать книгу Designe pattern от редакции Head First. Я думаю, что после прочтения первой главы вы согласитесь со мной.
Мой вопрос возник именно отсюда. Со статьями согласен, процент не очень хороших статей достаточно велик, и модерация часто страдает. Но для себя я заметил, что намного лучше осваиваю материал, если смотрю видео на ютубе где все те же мысли из книг наглядно анимированы. По паттереам пытался читать знаменитую банду четырех, и ничего скучнее в жизни своей не видел (не значит, что книга плохая, это абсолютно субьективно, head first еще более-менее). Причем есть куча источников, где те же самые паттерны объяснены намного более наглядно и с отличными примерами, и все это не книги. И после этого довольно странно было бы на собесе получить минус карандашиком за то, что "не читаю книг".
Я с Вами полностью согласен на тему того что нельзя все мести одной метлой. Бывают и курсы бесполезные, и книги не информативные, и статьи очень информативные. Все что написано в этой статье всего лишь мое скромное субъективное мнение. Я очень не люблю читать книги, мне не нравиться этот процесс. Но когда я начал это делать я понял что это очень важно, что книги являются еще одним мощным дополнительным источником знаний.
Похожая ситуация с алгоритмами. Есть три лагеря: 1 - утверждает что практиковать алгоритмы ни к чему, но при этом, как правило эти люди не практикуют алгоритмы. 2- утверждают что это важно потому что сами решают. Ну тут как бы все понятно сами это делаете и выхваляете свое занятие. 3 - люди которые утверждали, что это лишние, потом начали практиковать алгоритмы и переобулись.
Вот с книгами похожая история. Сам по себе процессе изучения материала через книги - это уже не простая задача. Опять же, я не на чем не настаиваю - это всего лишь мое мнение. Возможно я в этом не прав.
Даже не знаю, что бы я подумал после такого интервью.
«мы нарушаем одну из форм нормализации БД» - по теории баз данных форма нормальная, а нормализацию нельзя нарушить, поскольку это процесс… приведения к одной из нормальных форм. Интервьюер не владеет теорией и терминологией? Или проверяет? В вопросе вы говорите об автомобилях, то есть объектах, тогда вводим user_id, и первую нормальную форму не нарушаем, поскольку в ней говориться о уникальных кортежах, user_id и автомобиль(объект) будет уникальных кортежем и связь один к многим. Но на рисунке у вас в таблице не автомобили, а модели, тогда связь будет многие ко многим, поскольку объект автомобиль урезается до объекта модель автомобиля, которая является только одной из характеристик автомобиля. Что думать?
А еще есть теория информационных процессов и систем или просто ООП. И все становиться еще не однозначнее.
Просили вернуть адрес – в единственном числе (first скажем), а оказалось, что вернуть надо массив. Вы уже там решите, какая у вас задача…
А чего у них в конторе с БД в которой нет уникальных идентификаторов, а ищется по ФИО, вообще не понятно, да еще они при этом хотят безопасность.
Если бы другой инфы не было, поставил бы конторе большой минус и не стал бы связываться.
Ознакомьтесь пожалуйста с нормализацией базы данных. И прочтите внимательнее статью. Там написано, что важно поговорить об этой задаче. Спросить у кандидата, как бы он решал эту задачу и почему. Конечно нельзя ожидать что человек за 5 минут найдет вам идеальное решение задачи которую вы уже обсуждали с 10 людьми. Тут важно посмотреть как кандидат рассуждает.
Касательно запроса адреса по ФИО, Вы опять не внимательно прочитали. Там написано "спроектировать АПИ" - при чем здесь БД? В БД данные могут храниться как угодно. И в этой задаче сохраняется такой же принцип как и в первой. Мы не ждем от кандидата идеального решение. Нам важно поговорить с ним на эту тему. Цепляться можно за любую задачу. Любую задачу можно критиковать и это тоже своего рода фильтр.
Ознакомьтесь пожалуйста с нормализацией базы данных.
Вот и поговорили, я получил отказ и стандартный фидбек «иди учи».
Вот ты сидишь с той стороны и гадаешь, что «экзаменатор» знает, что нет, а самое главное, что примет близко к сердцу. Вот, например, вам надо говорить, что в поле 'model', у вас еще, наверное, через пробел, намешана марка, еще кое где модификация, кое где исполнение, а где-то нет? Или вы это то же близко к сердцу воспримите? И как ваше хистори со всем этим строить.
И этот коварный вопрос про апи, поди угадай, какой вариант «экзаменатор» считает единственно верный? CRUD, добавить туда patch, сделать все на get – post, ошибки как возвращать, стандартные или предусмотреть какой то isError. Я разные варианты видел единственно верными, с иди учи, если не угадаешь. Но мне в общем все равно, я по любому могу. Вот сидишь в недоумении, что сказать, а где лучше помолчать.
И в общем мало вероятно, если от тебя требуют объект, вернуть массив, это как минимум надо заново согласовывать доку/спеку или хотя бы принимающую сторону извещать. И вы от меня ждете, что я начну разруливать не однозначности, а где то, другой экзаменатор, что предложу поменять ФИО на уникальный uid. Иди догадайся, что вы ждете…
И какое решение именно вы считаете если не идеальным, то близким к правильному.
Я именно об этом и пишу. Конечно я не жду, что кандидат услышав условия задачи за пять минут даст идеальный ответ. При том что я эту задачу уже 20 раз обсуждал с другими людьми. Тут интересно послушать кандидата. Вот у Вас интересное рассуждение на эту тему. Вы обратили внимание на то что модель криво записана. Я же там написал, что важно поговорить на эту тему. Если кандидат предложит добавить ключ в таблицу автомобили, то спроси почему так ? И в этом вопросе нет подвоха просто интересно узнать почему он так предложил. Есть ли у него еще какие то варианты. К примеру создать связывающую таблицу. Если кандидат не предложил такой вариант, то я сам предложу ему такой вариант. Потому что мне интересно услышать его мнение на этот счет.
Поймите, основная мысль которую я доношу в этой статье как раз и есть в том что нельзя ожидать однозначного ответа. Я же там написал что собеседование в стиле школьного экзамена не эффективно. Сколько раз в своей работе вы обдумывая решение проблемы меняли свои идеи? Наверняка много раз и это нормально. Нельзя ожидать что на собесе человек с первой минуты даст правильный ответ. Абсолютно нормально когда на собесе кандидат предлагает кривое решение. Это не значит, что он плохой специалист ему нужно подсказать что это решение не очень хорошее и вот если он не поймет вашу подсказку тогда можно делать какие то выводы.
Хотел бы обратить внимание, что софт-скиллы и психологию, всё-же надо ставить на первое место. При выборе склочного супер-спеца и чуть менее толкового, но более коммуникабельного бойца, лучше выбрать второго. Прокачать мозги можно, но вот говнистый характер у 40+ летнего программера вы уже не прокачаете. Проводил довольно много собесов, бывало, ошибался в кандидатах, но получил довольно хороший опыт. Могу сказать, что технически грамотный спец, но с плохими коммуникациями - это беда в проекте и шанс развала команды. Сейчас при собесах в первую очередь смотрю, как кандидат может повести себя в команде и как он может сработаться с командой. На что обращать внимание - как он отзывается о предыдущих командах/проектах/работодателях. Всё тоже самое будет с ним и в текущей команде, исключений не бывает.
Как проводить собеседование в ИТ