Комментарии 187
Я не понимаю, а зачем вы это делаете?
Зачем делаете что? Выявляете какими навыками кандидат обладает а какими нет?
парень работает на ровно такой же должности, решает те же задачи, что и вы, на вашем стеке
На словах может и такие же, но зачастую выясняется, что человек не имеет не то что опыта, а элементарного представления о каких-то аспектах, которые важны конкретно в вашей компании. Иногда даже порассуждать в нужном направлении неспособен.
Зачем?
Чтобы не тратить в дальнейшем на него ресурсы компании и других разработчиков, это же очевидно!
Согласен. Меня коллеги тоже спрашивали, зачем такие (сложные?) вопросы на собеседовании. А идея некоторых вопросов как раз в том, чтобы услышать свободное рассуждение, пусть даже правильный ответ кандидату неизвестен. А когда он молчит, как пень, какой из него, к чёрту, тестировщик (например)?
Меня коллеги тоже спрашивали, зачем такие (сложные?) вопросы на собеседовании
У меня тимлид однажды вернулся с собеседования (собеседовал он) явно впечатлённым. Рассказал, что кандидат на позицию девопса в ответ на вопрос о внутреннем взаимодействии компонентов кубера сказал «А чо вопрос-то такой душный?»
зачем допрашивать человека, который уже работает на такой же позиции на вашем стеке
В этом предложении все предпосылки ложные:
собеседование — не допрос
у нас нет доказательств, что кандидат работает вообще или работает с нужным стеком
нет доказательств, что выполняемые кандидатом функции на его текущем месте работы действительно совпадают с нашими ожиданиями
Для этого и проводится собеседование, чтобы убедиться, что кандидат действительно соответствует своему резюме.
А вы заслуженно? Может у вас есть какая то лицензия на экспертное мнение?
Это уже переход на личности, но, положим, несколько лет работы в компании, пройденные с положительными оценками performance review, положительные отзывы коллег, закрытые задачи, качество кода и проектируемых решений, и т. д., и т. д. могут считаться критериями заслуженности?
Не нужно быть экспертом, чтобы понять, сможет ли человек усилить команду, имеет ли потенциал дорасти до ее уровня, или всей остальной команде придется тащить его и его обязанности.
К построению команды, или найму, допрос кандидатов имеет мало отношения, потому что сильно связан с личностью и настроением интервьюера
Если в компании интервью стандартизированы, направлены на выявление необходимых софт и хард скиллов то что не так? Никто не ожидает что кандидат будет знать какие-то точные заранее заученные определения или в сессии лайв-кодинга напишет очередной мозговыворачивающий алгоритм, но он точно должен показать умение рассуждать в поисках решения и доносить эти рассуждения до интервьюера.
PS Тем не менее, если вы такой противник собеседований, можете запустить свой стартап и брать любого, кто красиво наплетет про себя и свой опыт. Судя по всему, нужно придерживаться именно такой стратегии найма?
вы ничего не путаете?
УПК РФ Статья 194. Проверка показаний на месте
Так, стоп. Разве вы только что не спрашивали зачем задавать вопросы на собеседовании, заявляя о их бессмысленности? А сейчас говорите что работает схема с реальными вопросами.
Уже как-то писал на хабре байку про человека умевшего в резюме и собеседование, но не умевшего в реальный код. Успел поработать в куче интересных мест, в одном Сбертехе полгода продержался. Что-то мне говорит, чтьо у него в резюме были не все его 20-40 обманутых работодателей.
Как связано описание условий допустимости допроса по УПК РФ с вопросом о том является ли собеседование допросом? Это как на вопрос "лошадь это машина?" отвечать цитатами из пдд
А зачем вообще собеседовать кого-то раз он уже работает на такой же позиции? Ну давайте просто так брать сразу, зачем время тратить.
Критерии вопроса: зачем допрашивать человека, который уже работает на такой же позиции на вашем стеке
Вот вы не поверите, у меня был случай в карьере, когда меня поставили ведущим разработчиком, вместо коллеги, но продукт, который я когда то начинал разрабатывать (пришлось от него отвлечься, потому что моя помощь срочно потребовалось на другом продукте) и, когда я вернулся, спустя три месяца, то увидел, что главный модуль, который приносит системе больше всего денег превратился просто в фарш.
Человек ни паттернов не знал, ни наследование не использовал. Любое изменение логики у него было тупо `if`. Юнит тесты? Это что вообще такое?.
В общем, я тоже за душные вопросы:)
Практика показывает, что можно успешно парить мозги полгода-год, прежде, чем коллеги поймут, что ты полный ноль. То есть, меняя работу раз в полгода-год, можно долго оставаться неразоблачённым
За полгода можно неплохо изучить предметную область и получить опыт. Если чел за полгода не смог - да, он полный ноль. Но если у руководителя на это умозаключение ушло полгода - как его охарактеризовать? ;)
Руководитель же тратит не свои деньги. Бывает так, что нужно на кого-то свалить всех собак. Тогда получается win-win.
У нас не так просто дешево уволить чела, который не только знает, но у умеет в КЗоТ. Кроме того, пропарить мозги с месяц-два не так и сложно. Особенно если есть бардак с техникой/правами доступа. Я в паре контор без компа месяц сидел на з/п выше рынка.
Я в паре контор без компа месяц сидел на з/п выше рынка.
Ну так если контора готова платить деньги только за то что чел в офисе присутствует, при чем тут нагугленные/выученные ответы?
Я про то, что ситуация с бардаком обеспечения новых сотрудников, одно время была во всех крупных банках и (части?) технологических компаний.
В это время главное было устроится на работу и, при известной наглости, можно было и в офисе то не появляться (я возьму распечатку и поизучаю дома, хорошо?), какие-то технические скилы нужны были только на собеседовании )
То есть, меняя работу раз в полгода-год, можно долго оставаться неразоблачённым
Так, собственно, наступившее (если) разоблачение - чем оно грозит? Ничем. Специалист по прохождению собеседований, а не по выполнению работ на вакансиях, на которые собеседуется, все так же пойдет собеседоваться дальше и все так же работать то ли до разоблачения, то ли до любой другой причины увольнения.
Ну х.з. У меня вполне была ситуация, что я стучался на вакансию, а мне HR отвечал: "Они тебя знают, почему-то работать с тобой не хотят."
До сих пор интересно почему.
И обратная ситуация была. Начал общаться с ребятами, выяснил кто у них лид и сказал "Не не. Давайте без меня. Спасибо."
На днях двух коллег уволили, потому что они на две студии работали. Руководители студий друг друга знают и просто в процессе общения выяснили что у них одни и теже люди работают.
Да и сам в похожей ситуации был. Работал парт тайм, руководству не понравилось моё отношение к работу. Оно тайком на меня наехало в общем приватном чате "больших шишек". У руководства на основной работе ко мне вопросы появились. Вопросы отпали, когда ситуацию объяснил. Но лживое сообщение обо мне в "приватном общем чате больших шишек" никуда не делось.
Рынок конечно огромный. Но всё равно все друг друга знают. И если просто творить фигню на низшем уровне какое-то время и получится, то потом есть риск что о тебе начнут говорить хотя бы в формате
-"О, у меня такой кадр работал! Четыре месяца нас за нос водил."
-"Серьезно, так он и у нас работал тоже!"
-"Давай у коллег спроспим!"
И вот уже все знают что ты за человек.
У нас нельзя уволить челика за некомпетентность и написать это в его трудовой книжке. Что впрочем хорошо, потому что и работодатели разные бывают.
Легко. Вот с такой вот записью:
Трудовой договор расторгнут в связи с несоответствием работника занимаемой должности вследствие недостаточной квалификации, подтвержденной результатами аттестации, пункт 3 части первой статьи 81 Трудового кодекса Российской Федерации.
Вы когда-нибудь увольняли человека, который этого не хочет? Вы сначала докажите его несоответствие согласно его должностной инструкции, проведите аккредитацию подтверждённую согласно этой же должностной инструкции, чтобы ее потом никто не оспорил. А если не получится, то он потом помимо компании еще и лично вас засудит как предвзятого руководителя, который мешает ему реализовываться в жизни.
Так можно и лидом стать :)
Берите выше. Я однажды работал в гос. конторе, где у нас в департаменте, главный фронтенд архитектор был на уровне стажера по профилю. Мне хватило 10 минут по чисто техническим вопросам инструментария нашего, чтобы это понять (я тогда будучи крепким джуном, мощно с этого прифигел). И все вокруг понимали это также, и многие даже докладывали руководству, особенно подгорали сеньор фронты с него и бекенд архитекторы, которых он дергал на бесполезные совещания по пол дня (и это еще времена офлайн, угу). Результат? А никакой. Он за полтора года сделал копипастеный стайл гайд в pdf (если вообще не украл), получая при этом зарплату, как 20 стажеров на его место в те годы. Потом ушел с золотым парашютом покарять просторы других компаний, где на проверке работы сотрудников "собаку съели". Зато он очень хорошо "Разводил воду" на митапах, собирал их столько, сколько мог, результат был нулевой. Обсуждали всю дорогу такие абстракции, какие только можно представить, без конкретики, и это же он в уши руководству лил с умным видом
А кстати, вот зачем спрашивают модель OSI , ну вот какое практическое применение этой вызубренной последовательности?
Требовать, чтобы человек как заклинание мог выдохнуть "...канальный-сетевой-транспортный..." по-моему нет никакого смысла. Зато есть смысл послушать, как кандидат станет рассказывать про эту матрёшку: какие данные заворачивают внутрь других пакетов и кадров, и зачем так делать.
Скрытый текст
• Вот тут у нас есть поток сознания импульсов с линии связи, по определенным правилам они демодулируются и превращаются в биты. А еще можем отловить ошибку, когда передачи от разных узлов накладываются друг на друга.
• А здесь биты собрали в кадр. Добавили проверку на ошибки. И еще научились отличать узлы друг от друга на аппаратном уровне - можем указать, в какую железку должны попасть отправленные данные.
• Тут придумали как достучаться до узла, который находится где-то в гребенях и не может нас слышать напрямую. Как оптимальнее всего использовать промежуточные узлы. Кстати, когда нужный узел не в нашей локальной сети, его аппаратный (MAC) адрес для нас бесполезен, поэтому добавили логические IP адреса.
• А здесь решили проблему, когда на одном узле живут web сервер, файлопомойка, и почта до кучи. Чтобы сервисы не передрались между собой за входящий сетевой пакет, добавили в него специальное поле, однозначно указывающее адресата/протокол.
Кстати, о протоколах: можем либо снизить накладные расходы на обмен данными, либо гарантировать их доставку.
• Здесь мы уже можем передавать нужные пользователю данные. Иногда как есть, прямо текстом или бинарными блоками. Иногда внутри более сложных протоколов.
Почему этот уровень абстракции решили разбить именно на три слоя, я никогда не понимал. Скорее всего потому что число 7 красивое.
Но это понимание нужно для работы далеко не всем. Если интервьюер спрашивает про OSI не к месту, то хз, может быть он сам когда-то с трудом выучил все семь названий, и теперь ему хочется всем это показать.
Ну для тех кто работает с сетевыми протоколами/железячниками/сетевикам (но не тем которые которые копают канаву под кабель) наверно нужно, а вот для остальных...
затем что на канальном ethernet например у тебя 1,5к а в транспортном tcp буфер 64к окно и если у тебя есть rtt пинг задержка ты сможешь посчитать пропускную способность. а когда манагер хочет больше чем может твоя сеть, ты сможешь это доказать математически.
мораль сей басни в чем?
у кандидата хотя бы скилл гугла прокачан, а некоторые на zoom созвон со скрипом с третьей попытки подключаются
, а некоторые на zoom созвон со скрипом с третьей попытки подключаются
Это вообще о скиллах не говорит совсем ничего. зум хоть и стабильная софтина, но помнится бывали у него глюки с пустого места...и обычно они внезапные, у меня частенько микрофон отваливался...и приходилось судрожно перебирать с чего подключится, обычно стабильнее всего с телефона заходить.
Мне застрелиться теперь, если я никогда вообще вашим зумом не пользовался :)?
Или может забыть 20+ лет опыта в коммерческой разработке :)?
Нет, если вам нужен тот, кто отлично умеет зум включать, то вы на верном пути. Я-то думал работу надо работать, а оказывается вон оно что ...
Есть проекты, на которые не подходят инженеры, которые не могут находить решения для новых задач, а только повторяют заученный опыт. Отсюда, к слову, и алгосекции в собесах бигтеха.
Это в алгосекциях то новые задачи? Как раз наоборот, стандартный литкодовский набор, кочующий по конторам. В Яндекс помню проходил алго, задачку решил, время осталось, говорят, "попробуем ещё одну?". Пробуем. Озвучили. Я честно сказал, что эту задачу решал на литкоде, поэтому решение знаю. Решили не решать :) Прошел.
Он кочует по конторам, сотрудники которых не понимают зачем алгосекция нужна(карго-культ). В фаанге, и в частности гугле, если на собесе видят что задача вам знакома и вылегко ее решаете, то собеседующий будет менять и дополнять условия до тех пор, пока вы опять не попадете в ситуацию когда вам надо придумывать решение. Делается это потому, что гугл работает не как потоковое производство, где вам надо взять джиру, требования и собрать решение из существующих библиотек, фреймворков и стек оверфлоу. Гораздо в большей степени там приходится решать задачи, которых никто до этого не решал и по-этому 20+ лет в коммерческой разработке имеют меньше ценности, чем умение быстро соображать.
Технологии слишком часто меняются.
Соображать быстро зачастую приоритетнее 20+ опыта на одной технологии.
гугл работает не как потоковое производство, где вам надо взять джиру, требования и собрать решение из существующих библиотек, фреймворков и стек оверфлоу. Гораздо в большей степени там приходится решать задачи, которых никто до этого не решал
Если вы имели ввиду не абстрактный гугл, а конкретную компанию, то это излишне романтическое представление о процессах внутри.
А потом эти гении-алгоритмщики не осиливают сами себя кинуть в вайт-лист (а, простите, allow-list, это важно, мы же про гугл говорим) и крайне важные письма от самого гугла улетают в спам gmail'а:
Я не знаю что там за рубежом с FAANG, но российские HR'ы от яндексоидов тех же только грустно вздыхают.
Во-первых "они", как все люди, совершают ошибки. Во-вторых речь идет не про "гениев", а про то, что есть люди с разными навыками. Кто-то может хорошо собрать нужное решение из готовых частей, зная что и с чем соединять и будет таким образом развивать и поддерживать продукт, составляющий основу бизнеса, а кто-то может быстро придумать и реализовать какую-то новую идею, которая возможно принесет компании прибыль. А может не принесет и проект закроют, как это частно бывают в бигтехе. Это разные модели бизнеса, требующие разных качеств от людей и естественно разных процессов к найму. Естественно когда люди мешают одно с другим, то и возникают вопросы типа "зачем на собесе эти идиотские литкод задачи не имеющие отношения к реальной работе, лучше бы спросили как кластер кафки настроить и JWT авторизацию сделать на бэке"
И причем тут умение быстро решить проблемы с зумом ? Для девопса еще куда ни шло, но разработчик совершенно не должен уметь отлично разбираться в решении подобных проблем.
Он их решил. С третьего раза. Чего вам еще надо ?
Что значит "должен"? Никто никому ничего не должен до подписания контракта, просто есть проекты на которые не подходят люди, которым когнитивные способности не позволяют быстро разобраться даже в такой примитивной вещи, как программа для видеозвонков. Зато такой человек может отлично подходить на проекте, где надо формочки с гридами сотнями клепать с помощью ORM и очередного MVC фреймворка.
Оо, подъехали байки про когнитивные способности :).
В целом я за людей, которым отказали после того, как у них возникли проблемы с зумом рад. Плохо работать когда в начальстве идиоты.
Если бы вы были хотя бы на 3% тем самым девопсом и имели хоть какой-то опыт вообще, вы бы знали, что грабли могут быть спрятаны совершенно где угодно. И понимали, что не бывает "примитивного софта, который гарантированно работает". С любой, даже самой простой программой могут возникнуть проблемы. И они ничего не говорят о чьих то когнитивных способностях, кроме, простите ваших :).
ЗЫ. Из несвежего: по каким-то неведомым причинам отвалился таскбар у w8. Т.е. однажды утром он пропал. Его больше нету. Вообще. Нет ни кнопки пуск, ни поиска, ничего. И когнитивные способности нескольких сеньеров и архитекторов не смогли его вернуть быстро. Только долго. И нет, гугл в тот момент никаких адекватных решений не предлагал.
Так что можете продолжать гордится умением запуска зума в идеальных условиях. Но без тех людей, которые при случае в состоянии этот зум пропатчить, чтобы он работал в неидеальных :)
Не сразу понял, что собеседование велось телеприсутствием. В офисе за столом такое бы вряд ли прошло.
А сколько лет назад, вы в офисе собеседовались в последний раз?
В 2008ом, но фирма была местная
После этого в 2024, но фирма была Московская (тут удалённо происходило)
2 дня назад и неделю назад
Оо серьезно? Куда? В мск?
лет 10 все собесы онлайн.
Серьезно. Ну компании называть не буду, но очень приличные. В мск.
Так как раз по теме - чем больше будет читеров - тем больший процент собеседований будет вживую. А дальше рыночек помешает - пойдут люди или нет.
ОНИ услышали вас.
Собес онлайн, пришли втроем - гендир, финдир и главбух.
Зачем так усложнять, для опытного технического интервьюера, задать пачку вопросов которые не гуглятся, не представляет особой сложности.
Согласен с вами, но есть проблема - интервьюеры не в состоянии придумать такие вопросы)))
Сейчас есть Chat GPT, которому скорей всего не будет сложно ответить на такой вопрос. Можно попробовать наоборот (если есть подозрение, что кандидат использует AI для ответов), задать какой-нибудь очень сложный вопрос, который кандидат маловероятно, что знает.
задать пачку вопросов которые не гуглятся, не представляет особой сложности
Любопытства ради, можете привести примеры таких вопросов
задать какой-нибудь очень сложный вопрос, который кандидат маловероятно, что знает
А такой ответ подойдет: не знаю, но смогу разобраться в течении пары часов?
Легко:
1. Можно попросить назвать операции соединений sql ну или иногда их принято еще называть стратегии join`ов (не типы), человек который знает поймет сразу о чем вопрос
2.Очень часто заметил что ai сыпется на вопросе про final классов и методов для php - кандидат который его использует, начинает рассказывать про finnaly(троих таких видел уже) ))
3.Можно привести практический пример инициализации проперти в форм реквесте в ларавеле, после чего там везде начинают приходить null значения (ai на этот вопрос ответить не может)
Как-то раз у меня на собеседовании во время лайв-кодинга кандидат ловко написал требуемый код, но в нём были небольшие ошибки. Я сказал кандидату, что вижу ошибки в таких-то местах, и попросил исправить. В этот момент кандидат поплыл, было такое ощущение, что он вообще не понимает, что его код делает, и как работает язык программирование.
чо дизов то накидали на статью '-'
Так подобные кандидаты и накидали. Сейчас все задротят собесы, но действительными знаниями не запасаются. Не давно, на просторах одного IT сообщества, вычитал одну историю, как одного подобного "читера", который ловко с чатом ГПТ прошел собес, взяли на мидл+ , а через месяц его уволили, так как ахинею он знатную писал, которую даже джун бы осудил.
А зачем нужны "действительные знания" если их не проверяют? Скилл прохождения собесов и скилл работу работать сейчас находятся в перпендикулярных областях. Рынок ССЗБ
так вот же, в данной статье, тимлид говорит - проверяю, а мне в ответ врут...
опытный специалист легко может оценить знания кандидата в своей области, если не может, видимо, он и сам не особо...
так он и оценил - слабенько, потом начал подозревать почему слабенько, потом проверил подозрения и таки да, они оправдались, кандидат действительно не знает, а подглядывает в гугл... тоесть это даже не слабенько, а - нифига не знает, но умеет гуглить....
а ниже пошли комменты с предложением брать потому, что:
- другие и гуглить не могут
- эти собесы ненужные и там не спрашивают действительно нужные знания
- да какая разница, сам знает или нагуглил (хотя разница огромна, возьмите экскаваторщика, нагуглить что значит каждый из рычагов-педалей легко, но толку в первое время от такого "специалиста" никакого, вред один)
Если вопросы, которые возникают по работе, так легко гуглятся - зачем требовать знать их наизусть?
вспомните школьную математику. упростить выражение. нагуглить формулу квадрата/куба суммы - легко, однако нужно еще знать что тебе нужно гуглить, если ты ее не знаешь - ты не видишь закономерности в двух квадратах и двойном произведении между ними, а если знаешь - в голове щелкает и ты знаешь куда копать, пусть даже там вокруг есть мусор, который нужно будет вынести за скобки или еще что...
если что-то есть в гугле, но нет в голове - работодатель будет оплачивать не только время на решение, но и время на ваше обучение, которое вам понадобится на освоение нагугленного. Если разобраться в нагугленном занимает столько же времени сколько применить использованное к текущей задаче то половину оплаченного времени улетает на обучение сотрудника, половину на решение задачи. В случае сложных вопросов - время на понимание нагугленного резко вырастает и вот уже 70% времени уходит на обучение, а 30 на решение задачи.
Именно в этом соль грейдов, знаний и прочего... Вполне допускаю, что некий школьник умеет гуглить лучше архитектора со стажем, знает все скобочки/слова для корректировки запросов и тд и обоим придется гуглить характеристики некоего новомодного композитного бетона... Но мост/дом строить школьнику нельзя поручать.
Затем что истинный вопрос X, на который хочется ответ - "будет ли группе разработки хорошо, если этот человек проработает в ней полгода". Самый очевидный способ ответа требует полгода.
Поэтому все пытаются найти такой индикатор Y, который а) вычислим за разумное время и б) коррелирует с X. Поскольку задача примерно одна и та же, разные агенты приходят к очень похожим индикаторам.
А дальше приходит Гудхарт и говорит "а хрен, в окружении где многие оптимизируют Y, он больше не коррелирует с X". Люди пытаются решать проблему, в первую очередь поиском какого-то волшебного индикатора который бы был устойчив к этому эффекту, "истинного имени" X. Как ни странно, это не получается.
(Как известно людям, соприкасающимся со вступительными экзаменами, более-менее универсальный способ - задавать простые, коррелирующие с желаемой характеристикой, но при этом неожиданные вопросы. Но массовый рынок неизбежно трактует "неожиданный вопрос" как "вопрос из сборника неожиданных вопросов".)
Ну тут немного больше люди хотят от статьи, чем на дзене. Показалось, подозреваю, невербально убедился - хочется больше деталей. Опять же в первой выдаче гугла все было по делу?
ЗЫ. Я на собеседовании часто смотрю мимо камеры, если запускаю созвон на доп мониторе, где тупо лучше видно, особенно, когда кодинговая часть идёт.
за телеграм в конце думаю. Ну и в прицнипе проблема известная, зачем в сотый раз это постить?
Вообще мне кажется, если давать образец кода и обсуждать его - такой вариант предполчитетельнее - то фиг тут чего спросишь у чатжпт и будет понятно как человек разбирается а не судорожно пишет под надзором.
К сожалению, нет. Мы проверяли - chat gpt выдает в некоторых случаях очень хорошие ответы, что с кодом не так.
Попробую предположить - за то, что в статье открыта Америка и в конце ссылка на телеграм-канал. Т.е. ценность для аудитории сомнительна.
А о чем была эта статья?
"Я проводил интервью и мне попался кандидат, который гуглил ответы на вопросы. А теперь подпишитесь на мой канал...."
ля педики карму в 0 спустили ни за шо
На собеседовании читерить глупо, а вот чтобы проходить HR AI и прочие фильтры - похоже сейчас это вообще просто необходимо.
Ну почему же, я вот довольно часто собесы провожу, и встречаются персонажи я их для себя называю "тревелер", которые ходят по компания после каких нибудь курсов на ютубе и довольно хорошо с первого взгляда тащат технические собесы, устраиваются в компанию и просто пару месяцев если не спалят сидят на зп (в некоторых компаниях так можно проработать довольно долго), правда если ты много собесов провел, их не сложно вычислить, и кстати заметил интересный нюанс, чаще всего такие персонажи просят зп порядком выше по рынку)
А есть ли тут вообще проблема, если он таким же образом сможет решать все рабочие задачи?
есть.
топорно повторять за гуглом \ стэковерфлоу не понимая, что ты вообще делаешь, и рассуждать, строить логические цепочки и вдумчиво разбираться - это разные скиллы
Конечно, это огромная проблема, если потенциальный коллега прямо врёт, мне бы не хотелось с таким работать.
Так решать рабочие он не сможет, в гугле ответов на рабочие нету.
Для начала решения рабочей задачи человеку может и неделя и месяц понадобится, чтобы вникнуть во всё. На собеседовании предлагают какой-то рафинированный вопрос, в который можно вникнуть за пять минут. Но вникнуть кандидат не может, может только у гугла спросить.
Это уже не говоря о том, что работать с людьми, которые сходу врут - такое себе
Эм, а не лучше ии привлечь для таких задач
Проблема в чем?
Тоже не понимаю. Если человека взяли на работу и он с ней справляется, какая разница что там было на собеседовании. А если не взяли, как вы можете судить вообще, даже если он куда-то подглядывает.
если не понимаете - расскажу :
проблема в том что такие вот джуны потом ради одной функции тащат 500-метровые фреймворки, топорно их друг с другом стыкуют и изолентой приматывают, а потом всё глючит, тормозит, жрёт 64+ Гб ОЗУ и все 24 ядра ксеона, падает каждые 3 минуты и имеет миллиард дыр и багов.
ради одной функции тащат 500-метровые фреймворки
Вот, ни разу такого вживую не видел. Зато "собственный логгер", "собственный ORM" и прочая подобная куета это, считай, "must have" на любом проекте, не говоря уже о двенадцатиуровневых обертках вокруг любого метода сложности хотя бы string.Trim(). Был как-то у меня в проекте замечательный метод-расширение:
public static bool IsNull(this object obj) => obj == null;
И не дай бог тебе было вместо него написать где-то:
if(foo == null)
{
// ....
}
Автор метода IsNull(), заметив в коде такое, тут же вычислял злодея по логам в Git и с налитыми кровью глазами несся через весь офис чтобы его покарать и заставить исправить код на своё детище.
Автор метода
IsNull()
техлид ?
Кстати, может иметь смысл, если у вас в проекте встречается перегруженный оператор ==.
Не - вполне резонный код - а вдруг кому в голову взбрендит сделать перезагрузку оператора сравления с null (привет, Unity!)) - этот экстеншн метод вызовет pure С# проверку (хотя и obj is null - сделает то же самое)
Можно пример?
проблема в том что такие вот джуны потом ради одной функции тащат 500-метровые фреймворки, топорно их друг с другом стыкуют и изолентой приматывают, а потом всё глючит, тормозит, жрёт 64+ Гб ОЗУ и все 24 ядра ксеона, падает каждые 3 минуты и имеет миллиард дыр и багов.
А куда в этот момент смотрят мидлы и сеньоры?
Видел такого лет десять назад. Сказали на страницу календарь прикрутить - пошёл на stackoverflow, скопипастил вполне рабочий ответ со скриптами подключения jQuery + jQuery UI.
Потом сказали ещё какой-то виджет прикрутить - опять сходил на stackoverflow и скопипастил. Опять со скриптами подключения фреймворка и библиотеки виджетов.
И в третий раз он тоже пошёл на stackoverflow и принёс копипасту. Только на этот раз ему попался ответ с использованием не jQuery, а Prototype. Первые три jQuery (один уже был на странице, но герой его просто не заметил, и два скопипащенных) ещё как-то уживались вместе. Но jQuery + Prototype уже не смог. И когда герой пришёл с вопросом "а почему у меня перестало работать" и показал исходник свей странички - я ужаснулся.
Ха! Вот скоро ИИ допилят до состояния, когда он будет правильно понимать вопросы голосом, потом голосом на них же отвечать, выдавая реалистичное видео шевелящего губами кандидата. Что тогда будем делать?
Тест Войта-Кампфа на собеседованиях проводить
Его и нанимайте тогда.
Ха! Приходи к нам в оффис, дорогой, там собес и проведем! Мне кажется - самый очевидный итог. Проиграют от этого, конечно, люди не из столиц.
Это тоже не панацея
В креэйторы подадимся.
Гораздо лучше выявить такое "читерство" на собесе, чем потом в ожидании фичи кормиться завтраками пока чатгпт сгенерит как отсортировать массив...
Зачем запоминать наизусть то, что на первой странице гугла?
Если человек действительно работает в некоторой области, а не нахватался по верхам, то он не целенаправленно запоминает ответы на конкретные вопросы, а понимает суть и может сформулировать ответ своими словами. Или, если это какие-то табличные значения - запоминает их просто потому, что часто ими пользуется.
Не понял, а зачем вбок смотреть, почему нельзя в экран спереди смотреть?
У нас такой работает, к сожалению..=( на собесе ему подсказывали, подозреваю скрытый наушник, а самое фиговое пока был испытательный он нормально закрывал задачи, вероятно кто-то писал код за него, а вот после испытательного, джун джуном, говнокод + код из chat gpt..🤦
Самый прикол чел получает больше меня, я за него переписываю и хз как его уволить. Лично я для себя выводы сделал когда увидел как бэк с уровнем мидл не может зайти в докер контейнер через терминал.
А зачем беку уровня мидл ходить в докер контейнер через терминал?
Всякое может быть. Отладить что-то, проверить окружение и т.п.
А вот зайти в sh внутри докера весьма простая задача, и не уметь это не характерно для мидла.
Хмм. а у вас прямо никогда не возникало ситуации когда вроде бы все покрыто тестами, но код работает не так и его надо отлаживать на тестовом контуре? Да и не все можно тестами покрыть.
Я считаю что разраб, начиная с определенного уровня (миддла уж точно) должен иметь доступ к тестовому контуру полноценный, чтоб уметь если есть проблема - посомтерть логи и вывод в консоль а не через цепочку тестировщиков каждый раз это делать.
Например чтобы запусти интеграционные тесты.
Беку это не надо делать на своем коде? Или это слишком круто для мидла? Или вы будете их запускать с локальной машины, читай на другом окружении?
Вы их вручную запускаете?
Да, и вручную тоже, например при написании этих самых тестов. А вы их отлаживаете прямо на CI/CD или с первого раза пишете правильно и без ошибок?
Зачем запускать их вручную из контейнера? Если у вас есть CI/CD, то и команда для запуска есть. Или у вас как-то по-другому?
Я сеньором лет N был до того, как первый раз потребовалось зайти в докер контейнер через терминал. И если бы мне не показали куда ткнуть, тоже не зашёл бы. А я как бы через терминал до этого несколько лет работал screen/vim.
Спасибо за фидбек, мы все же смотрим на разработку через призму своего опыта. Видимо от сферы деятельности компании зависит, работал в двух компаниях, в основном разработка и интеграция микросервисов на основе нейронных сетей, при локальной разработке и отладке с докером приходилось делать всякое, дальше уже задача девопса, но локально должно собираться и работать.Докер это всего лишь пример, из той же серии как способность полноценно пользоваться терминалом, банально данные отфильтровать через grep, или ssh тонель прокинуть и т.д., привык воспринимать это как что-то базовое, то что все умеют.
Специально зарегался на хабр,чтобы оставить комментарий под этой статьёй.
Не знаю как там у ИТ-шников,может оно и стоит того такие собесы. Но меня как ИБшника максимально бесят подобные челики как автор. Я сам бумажный безопасник, разрабатываю различные орд и внд по ИБ. Работал как на стороне заказчика,так и на стороне интегратора.
Не понимаю челиков на собесе, которые начинают спрашивать меня какие то точечные вопросы по знанию какого-то конкретного нормативного акта. Ребят,вы в серьез считаете,что у меня голова дом советов и я должен знать все наизусть? Эти документы открытые и если мне нужна будет эта информация я знаю где ее искать,общие верхнеуровневые моменты я вам и так скажу. Особенно забавляют душные типки, которые начинают гонять вопросы по нормативке с которой ты вообще не работал и у тебя об этом указано в резюме или сразу озвучиваешь ,с какими направлениями работал,а какими нет. Так и хочется сразу отключится от вкс,или на моем фоне таким образом пытаетесь себе цену набить, мол какие вы умные все знаете . Также бесят собесы где приглашают кучу людей и они по кругу начинают тебя как на экзамене гонять. Особенно часто такая хрень в гос организациях.
Алло, просмотрите на мой опыт работы,на компании в которых я работал и на перечень работ ,что я выполнял,в резюме все написано, если не верите можете позвонить бывшим работодателям и уточнить что я делал.
Из 10 собеседований минимум 7 таких душных и неадекватных.
Ну и да,эра когда работодатель выбирает "раба" закончилась. Теперь специалисты выбирают вас,имхо. Наболело.
Я начал с обычных (не точных и душных) вопросов, но увидел, что есть некоторый лаг при ответах. Заподозрил, что кандидат подсматривает. Вопросы были открытые, с возможностью диалога. Но на прямой мой вопрос не подсматриваете ли вы куда-то кандидат соврал. И уже после этого перешел на гуглящиеся вопросы.
Я не хотел бы работать с человеком, который врет с самого начала. А Вы?
Ну про вашую ситуацию ничего не могу сказать, возможно вы были правы. Я просто высказал мнение о том как приходят у меня собеседования и что мне не нравится в этом. Первые 3 собеседования я тоже честно старался отвечать сам ,но после таких вот экзаменов я понял - а для кого я соблюдаю эту честность и самое главное смысл? Работодатель сам откликнулся,мой опыт и знания соответствуют должности, я уверен что справлюсь с задачами, которые он мне поставит. После осознания этой мысли по возможности тоже стал пользоваться Гуглом прям во время собеседования,когда спрашивали что то очень конкретное. Самое смешное что даже используя гугл и правильно отвечая на вопросы работодателя почему то все равно иногда это не устраивает и ты тупо не проходишь собеседование. Ты ещё не попал в организацию работать,а уже перегорел на собесах. "Класс"
Лютейше плюсую. А еще забавляет, когда тебя собеседует твой будущий коллега или подчиненный. Это вообще как? Я ж его выпилю в первую очередь, за такое "собеседование". Вы прям в точку попали, когда сказали, что они так себе цену набить. Смысла в этих точечных вопросах, на которые есть ответы на 1 странице гугла, нету.
Нормальный разработчик во время работы постоянно держит кучу вкладок с "гуглением", сверится в решениями, велосипедами, и вообще. Но на собесах надо все в голове, сцуко, держать... нет ничего глупее, чем вот эти вот собесы. Еще и с лайкодингом. Так и хочется сказать, вам таки шашечки или ехать?
Забавно было когда в ходе собеса (испытуемый был в очках) в отражении очков было видно как он судорожно гуглит ответы
А у меня был положительный опыт. Надо было придумать задачек по SQL и кроме банальных уровня "по таблице продаж, найти кастомеров, которые покупают самые популярные товары в разрезе месяца" придумал задачку со звёздочкой, которая показалась мне довольно сложной (выше ожиданий). Я её давал на дом - типа попробовать. За всё время мне её решили человек 5, при этом двоим явно написали более опытные люди. А один догадался спросить на SO и принёс мне ответ. Поскольку человек был уже принят, и эта задачка со звёздочкой ничего не решала, я даже не расстроился. С другой стороны, человек смог описать задачу, понять решение, объяснить его мне. Так что я посчитал, что гугл - тоже инструмент.
А можете озвучить сложную задачку? Стало интересно
Ну давайте уточним, она сложная в нашем мире, мы не программисты, но в целом позволяет оценить понимание SQL.
Дано - две таблицы. Orders и boxes. В первой указаны номера ордеров и количество айтемов в каждом заказе. Во второй - номера коробок и количество айтемов в каждой коробке.
Необъодимо одним запросом вернуть пары ордер-коробка-количество в порядке ордеров.
То есть при выполнении ордеров - из какой коробки мы какие ордера выполняем.
Пример:
Ордера:
Ордер1-5шт
Ордер2-7шт
Ордер3-2шт
Коробки
Коробка1-2шт
Коробка2-5шт
Коробка3-2шт
...
Получить.
Ордер1-Коробка1-2шт
Ордер1-Коробка2-3шт
Ордер2-Коробка2-2шт
Ордер2-Коробка3-2шт
Почему это в читаемом? Почему под статьей 50 комментариев?
У меня самый скучный собес в жизни разворачивался интереснее. Не описано ни что смутило в кандидате, ни вопрос, ни ответ из гугла. Какой опыт получен? Смотреть глазами на кандидата и гуглить? К чему в статье наложено про 2-летнюю давность истории и английский, никакой ретроспективы в статье нет.
И в конце как вишенка какой-то джуновский не подкрепленными выводами про GPT, про полтора года, про рынок. С такими авторскими задатками вы испортите нам всем датасет для ChatGPT и мы не сможем вас заменить.
Забавно) Я вот думаю, ну ответ по гуглу ладно, не катит. А если кандидат настолько хорошо освоил ChatGPT, что тот ему все тестовые помог пройти и на вопросы ответить. Не значит ли это, что и рабочие задачи этот кандидат с помощью ChatGPT успешно решит?
К сожалению, нет. Ну т.е. в общем случае не значит.
По мне так ключевым навыком в разработке является декомпозиция, уменьшение связности и сложности, тестируемость, все это ChatGPT пока не умеет.
На уровне кода уже все неплохо. Буквально на этой неделе писал оператор для rxjs с вычурной логикой. Сгенерированный код заработал с первого раза, но линтер ругнулся на цикломатическую сложность. Я попросил улучшить читабельность. Он разбил на функции, дав им логичные имена, но проблемы со сложностью не решил. Тогда сказал ему переписать код в стиле ООП. Он вынес логику в отдельный класс-контроллер, правильно выделил конструктор, public и private методы. Снаружи сделал функцию-адаптер для интеграции с rxjs. Затем мы с ним добавили типы, документацию и юнит тесты. Результат всех устроил и он получился быстрее, чем кодить самому, несмотря не некоторые проблемы. Основная была в том, что Copilot часто ошибается при редактировании существующего кода, вставляя результат не в том месте. Но это больше выглядит как баг плагина для VSCode.
Тут есть такой тонкий момент. Первое, вставить все это в существующий проект, параллельно сделав рефакторинг, не знаю, мне кажется в такой контекст он еще не умеет. Второе, вы должны были таки знать что спрашивать и понимать где и что он сделал не так. Я тоже использую GPT для написания кода. Поскольку я не разработчик, помогает очень сильно, поскольку если ты не используешь конструкции языка постоянно ты их просто не помнишь, плюс не все решения тебе сразу приходят в голову, даже у меня, код пробегает целый набор итерации, пока получится приемлемым, а потом проходит ручную правку, а я понимаю, что надо спрашивать. Плюс часто бывает, что он упирается в какое-то решение и выбить из некого этот контекст получается не с первого раза.
По мне так GPT скорее развитие идеи "автокомплита" чем отдельный разработчик, безусловно он несколько снизит требования к знаниям конструкций языка( как собственно говоря и автокомплит ) и возможно повысит производительность. Но как мне кажется, производительно именно в этой части у квалифицированных разработчиков и так достаточно высокая. Во всяком случае то что я наблюдаю, создание запросов к GPT плюс итерации, плюс правка, может быть дольше чем написать руками если ты пишешь реально быстро.
Я печатаю всеми пальцами вслепую. А вот соображаю гораздо медленнее, если это не что-то совсем банальное. Copilot часто быстрее. По сути, технологии всего лет пять, а в массах и того меньше. При этом не видно признаков, что они уперлись в потолок. Наоборот, прогресс от месяца к месяцу видно невооружённым глазом.
А зачем на собеседовании спрашивать всякие примитивные вещи, которые можно вот так с ходу найти в гугле? Это же пустая трата времени. Можно же задавать вопросы, по которым сразу будет виден уровень разработчика. Что-то вроде того, как бы ты делал вот такую задачу на вот таком стеке. Ну или там расскажи своими словами пример, как бы ты писал кастомный хук на реакте. Или там сколько таблиц в базе данных нужно, чтобы хранить список юзеров с указанием их образования.
Может конечно я отстал от жизни и чего-то не понимаю. Но в те времена укромные, теперь почти былинные, когда я был студентом (а было это ещё во времена господства 286-х процессоров) в том ВУЗе, где я грыз азы программистской науки, на всех экзаменах по программированию на первой парте лежали учебники, по которым читался курс. И любой экзаменующийся мог в любое время присесть за первую парту, полистать эти учебники и сделать из них выписки. И наши преподы нам так говорили: "Невозможно всё знать, невозможно всё помнить. Каждый инженер - в том числе инженер-программист - должен владеть тремя навыками:
Знать и понимать базовые принципы того чем он занимается
Уметь быстро находить информацию необходимую для решения актуальной задачи.
Уметь анализировать найденную информацию и понимать как эту информацию использовать для решения актуальной задачи."
Давайте будем смотреть правде в глаза: 90%, если не 99% рабочего времени среднестатистического кодера что тогда, что сейчас - приходится на решение задач, которые кто-то когда-то уже до него решал и решил. Так кто ценнее для команды разработки, пилящей очередной шедевр из серии "данные из постгреса достать, в джейсон завернуть, фронту отдать" - тот кто умеет быстро находить готовое решение в Гугле и засунуть это решение в код? Или доморощенный красноглазый гений, способный заучить наизусть стопиццот алгоритмов сортировки бубликом и продемонстрировать эти знания на очередном собесе? По моим наблюдениям - бизнесу (то бишь заказчику) нужен результат. Здесь, сейчас и за приемлемые деньги. Нагуглили вы этот результат или сами придумали - бизнесу без разницы.
"Я так думаю" (с)
Уметь быстро находить информацию необходимую для решения актуальной задачи
В классической неайтишной инженерии это называется "уметь работать с литературой" и до сих пор считается не багом, а фичей.
Более того, айтишникам не надо копаться в древних бумажных фолиантах и сомнительного качества сканах, которые не всегда вычитаны и имеют текстовый слой. У айтишников есть возможность искать по проиндексированной глобальной мировой библиотеке.
Но нет, они выебываются.
В отличие от студента, от специалиста с опытом хочется навыков, а не просто знаний. Нужно понять какие задачи он будет решать сходу, а где ему придётся ещё учиться и разбираться. Обучение, как ни крути, это дорогое удовольствие.
Нужно понять какие задачи он будет решать сходу, а где ему придётся ещё учиться и разбираться
... и подобные собеседования этого не показывают, вы хотели сказать :)
Такие собесы это минимальный фильтр для мимокрокодилов с кучей ложно-положительных срабатываний, а так как
Обучение, как ни крути, это дорогое удовольствие
поэтому лучше потерять хорошего спеца, нежели потратить время и деньги на промптера-копипастера-помогите-не-знаю-что-делать, который не факт ещё что сможет/захочет выучить именно то, что нужно вам. А так хотя бы видно что чел хоть что-то знает, (если не зарываться в детали в вопросе), и у него хватает мозгов и усидчивости чтобы задрочить БАЗУ (по мнению собеседующего, конечно) и литкод, или хотя бы иметь общее представление о вопросе, ещё и на собесе это вспомнить.
Тут вот недавно проскакивала статья от любителя рисовать опыт, вот от такого подобные собеседования и защищают.
Одно точно — с рынком найма в IT что-то пошло не так, причём с обеих сторон.
Извините, не удержался
Это одна из причин почему для меня важнее вопросы на которые кандидат не может ответить, чем вопросы на которые он дает ответ сразу. Такие выводятся на обсуждения, а какой ответ на него мог бы быть, что хорошо показывает как кандидат мыслит.
Оно показывает хорошо если человек а) умеет вслух рассказывать как он мыслит, б) либо умеет это делать в стрессовой ситуации, либо не нервничает на интервью. Проблема в том, что хорошие программисты... не обязательно обладают этими свойствами.
Вы же понимаете, что с человеком который не способен мыслить в стрессовой ситуации, а они повсюду, и не может вслух излагать свои мысли, крайне не комфортно и сложно работать, будь он хоть трижды гением. Хороший программист это не изолированная сущность, навыки "хорошести" не ограничиваются исключительно скилами в области кода. Лично я предпочту в проекте человека со средними скилами по разработке, но хорошими скилами по коммуникации, чем гения кодера, коммуникация с которым будет чрезвычайно затруднена, а в стрессовой ситуации, будь то личной или рабочей, его мозг будет выходить из чата.
Я в основном хотел обратить внимание что ответы даже в хорошем случае показывают не "как кандидат мыслит", а некоторую сумму "как он мыслит" + "как он вербально рефлексирует" + "как у него получается вести себя в обстановке собеседования".
Если вас как раз интересует что-то близкое к этой сумме, то и хорошо. Но это не универсальное предпочтение.
Могу сказать по себе, что на некоторые ситуации требуется больше времени, в стрессовых ситуациях нужно больше времени, теория в стрессовой ситуации это капец. И из-за скорости я не могу болтать на ходу. Но могу делать хорошие аргументированные заключения, и с опытом это делать чуть быстрее.
Но как работа, у меня не было проблем по коммуникации с коллегами, если конечно другой человек не токсик. Хорошие отзывы от коллег, от руководства. Хорошая самостоятельность по решению проблем.
Нужно учитывать разные факторы.
Это понятно. А почему на рынке присутствуют вакансии, по которым собесят кандидатов, хотя реального найма прямо сейчас не предполагается. Чтобы была пачка отсобеседованных кандидатов, когда ктот резко уволится или пробьют бюджет на увеличение штата? Это ведь не имеет отношения к читерству?
Ну, это обратная сторона сегодняшнего неадекватного айтишного найма. Сейчас для того, чтобы устроиться хоть в какую-то шарашкину контору, надо пройти семь кругов ада, как будто ты — кандидат лунной программы. Вы выстраиваете барьеры, кандидаты их пытаются обойти. Если бы найм был дружелюбнее, человек, понимая, что на нём не висит тяжкий груз, не боялся бы и не перестраховывался. Отказы тяжело пережить. Также бывает, что интервьюер самоутверждается за счёт кандидата. И, в конце концов, хотите проверить кандидата лучше? Так ведь есть трудовая книжка, есть испытательный срок.
Понравился один кейс. Израильская компания, сначала созвон с техдиром, он просто спрашивает про опыт, что делал, где и как, потом рассказывает про будущие задачи с целью понять, подходит ли мне это, никаких технических вопросов. Вторая часть это лайфкодинг(?) на нахождение проблем в реальном куске кода компании, обсуждение вслух, что не так тут и там. А потом дается ссылка на тест, который можно решать в течении недели, выбираешь определенный день и время, 2 часа, обязательно должна быть включена камера со звуком, всего две сотни задач с разделами - на ЯП, на базовые знания по разработке, на алгоритмы, на английский, на IQ. Спокойно проходишь тесты, просто жмякаешь кнопочки, никакого стресса, все тесты решать не обязательно, никакой гонки (можно пропускать тесты хоть пачками, а потом возвращаться к нерешенным). Тесты составлены так, что, зачастую, есть несколько правильных ответа, ну или почти правильных, и это приводит к тому, что смотрят не на правильно/неправильно решил задачу, а средне/хорошо/отлично.
Как по мне, самое без стрессовое собеседование, ну кроме тех которые были в середине нулевых или в начале десятых.
Рискну предположить, что автор статьи относительно мододой. А описанное просто является одним из сценариев самоутверждения
Как человек "относительно немолодой", и очень частый участник процесса найма с обоих сторон могу лишь сказать, что:
1) с точки зрения бизнеса абсолютно наплевать откуда работник берет свои познания в той или иной области - просто гуглит, выполняет запросы к chatGPT, общается с духами или с представителями генпрокуратуры - вообще пофиг, если это релевантная информация. Главное чтобы он умел эту информацию применять
2) Автор никак не описал выяснял ли он способность кандидата выполнять свои должностные обязанности (то самое - применять знания полученные из потусторонних источников) - для него видимо важнее, чтобы кандидат назхубок знал как можно реализовать сортировку пузырьком или что-то в этом роде. Подозреваю (обоснованно) что никак не выяснял, просто потому, что не знает как
3) Более того - автор фактически впустую потратил свое и чужое время и явно гордится этим. Казалось бы - ну не нравится тебе этот кандидат - чего париться - то? Вежливо закончи собеседование (что-то вроде "если у вас нет вопросов мы вам позвоним") и займись чем нибудь полезным.. или хотя-бы приятным...
И последнее, без номера - интервюер явно не понимает зачем он проводит собеседования. С его точки зрения он должен найти "куртого перца который знает почти все то, что он сам недавно прочитал в гугле". Но у руководства компании может быть иное мнение - нужно найти человекоподобный организм биологического происхождения, который будет приносить прибыль занимая определенную должность в компании (ну или хотя-бы не приносить убытков)
2 часа
две сотни задач
По 36 секунд на задачу?
никакой гонки
LOL
Я так понимаю вы промахнулись с уровнем комментария и писали мне.
Первое - задача найди лишнюю фигуру с 4 вариантами ответа, задача выберете пропущенное слово из 5 вариантов, или что вернет этот код из 5 строк, или что означает I в SOLID, или выберите вариант подходящий для описания типа string, выберите ответ не требует больше 15-20 секунд.
Второе. Все вопросы простые как лом, специально сделаны так, чтобы прочитать секунд за 5, подумать секунд 5-10 и нажать ответ.
Третье. Все задачи решать не обязательно. Это специально обговаривается, что ты должен решить только те задачи, которые понятны и над которыми думать по полчаса не надо.
Я сделал что-то около 120-140 задач за два часа (т.е. 60-80 не сделал вообще), и по итогу мне сказали, что я очень хорошо прошел тест, прямо топчик (хз, может и наврали).
Я всегда считал что от работника требуется умение думать, развиваться, находить решения, а не зазубрить ответы на вопросы. Благо на моём крайнем собеседовании мы сразу договорились что мы люди, а не машины и можно подгугливать временами. Хотя я даже скорее не гуглил, а подсматривал в свои конспекты и шпаргалки, скажем так. Обман, естественно, не оправдываю, я всегда честно говорю, что мне надо подглядеть.
У меня было множество забавных случаев которые демонстрировали диаметрально противоположные позиции по этому вопросу
1) собеседование в один из стратапов. Я первый разработчик за исключением отца-основателя, но он типа стратег - в смысле умеет, но у него другие задачи. Отец основатель серийный стартапер (и очень состоятельный человек, заработавший свое состояниеименно на реализации собственных идей, причем начальный этам всегда финансирует сам... ну и стартап фонд государственный конечно) - кодит он только на самом-мамом раннем этапе - когда саму концепцию вырабатывает. И вот он меня собеседует значит.. быстро поняли, что мы "на одной волне", предложил мне изложить идеи по поводу выбора стека (с актуальным на тот момент времени вопросом "а почему не scala?"). Ну и один из вопросов, которые он спросил помявщись был на предмет гугдения и копирования чужого кода. Я ему сказал, что мы все жтим занимаемся, вне зависимости от того, как отвечаем на подобные вопросы. Он так облегченно вздохнул и сказал что-то вроде "я так всегда копирую код если есть что копировать". Работу я эту получил, и работа была очень продуктивной с точки зрения финансов и личного развития
2) Собеседование в другой стартап. Правда он мне чем-то сразу не понравился.. Их главный дал мне некое задание которое я должен был выполнить прямо при нем. Задание было в принципе не сложное, гугл не понадобился, но я честно сказал, что я всю свою жизнь очень плохо сдаю экзамены любого рода (и всегда выкручивался за счет разных ухищрений), на что он мне сказал, что я вообше первых кто вот так вот на коленке написал код которых хотя-бы собирается без ошибок и что-то там делает. Ну и вот второй этам собеседований - с командой... Команда молодые (очень) разработчики очень важные от осознания доверенной им роли. Ну и значит дают мне задание - прямо тут сотворить реализацию какого-то там алгоритма... Блин мне тогда было немногим меньше пятидесяти лет.. Какие нахрен алгоритмы?! Но молчу.. пишу.. чего-то там вспоминаю, не очень получается... ну в общем что-то кривое я написал. И потом спросил - а вот это вот точно надо для должности на которую я претендую? На что я получил пространный ответ в духе "А как-же" с описанием какой-то совершенно тривиальной ситуации, решаемой той или иной библиотекой, причем я сразу же предложил пару вариантов выбора... На тот момент я уже решил что такая работа мне не нужна - они ведь не только меня так собеседуют.. а с какими коллегами я буду работать очень для меня важно
3) собеседование в крупную и распальцованную корпорацию. На техническом собеседовании мне выдают лжптом и предлагают реализовать приложение для подсчета очков в боулинг... Затык.. Я говорю объясните мне правила игры в боулинг! Меня спрашивают - ты что, не играл? Я говорю конечно играл - бросал мяч в нужную сторону когда меня звали и пил пиво - правила мне были до лампочки (и сразу сказал, что правила игр типа фубола, баскетбола, хокея и прочих подобных я тоже не знаю ибо никогда этой фигней не интересорвался). Ну в общем объяснили мне с грехом пополам. Но время же ушло... в общем начал кодить, за мной наблюдали, и походу добхясняли правила этой нелепой игры. Но интервьюеров интересовал сам процесс - как именно я пишу код и с этой точки зрения было все в порядке (ну и я почти закончил, когда мне сказали - что уже достаточно и все что нужно они увидели). Работу я получил, и она была просто замечательной... Но не очень хорошо оплачиваемой.... в смысле что вскоре я нашел получше
Пример хороший. Ещё есть один способ. Можно задать прямо очень сложный вопрос и посмотреть на реакцию. Если собеседуемый даст на него ответ по гуглу или около того, всё станет ясно. Правда это может адекватному программисту показаться ред флэгом (или как там новомодно сейчас).
П.С. Меня больше смутили слова: "у нас деплой в прод идёт я наблюдаю на другом мониторе". Что он там наблюдает, лично мне не совсем ясно. Ты либо деплоишь постоянно сидя в терминале либо нет.
Плюс если, что-то важное на работе, может стоит собес перенести, на свободное время?
"у нас деплой в прод идёт я наблюдаю на другом мониторе". Что он там наблюдает, лично мне не совсем ясно. Ты либо деплоишь постоянно сидя в терминале либо нет.
ну так бывает, если в процессе деполоя merge train есть, я бывало пару часов наблюдал краем глаза за происходящим и когда ВНЕЗАПНО твой MR попадет в прод
но вообще да, в таком случае собес надо переносить..это странно
Читерство на собеседовании