Много боли изливается на страницы Сети по поводу неудачных собеседований. Кому-то не понравились вопросы интервьюеров, другого обидели насмешками, иных посудили по страничке вконтакте. Интервьюеры не отстают от соискателей и ругаются на то, как плохо нынче с кадрами, и какие глупые ответы дают неопытные программисты на их заковыристые технические вопросы.
К сожалению, универсальных правил прохождения и проведения собеседования нет и быть не может, потому что сотрудников подбирают не только по их техническим навыкам и личностным качествам, но и по совпадению с некоторым (зачастую неявным и очень субъективным) «профилем», который, по мнению интервьюеров, вписывается в их команду или компанию. Что же касается руководств из серии «как правильно проходить собеседования», то они обычно вызывают не меньше боли в комментариях, потому что очень субъективны и обязательно задевают чьи-нибудь болевые точки.
За свою профессиональную карьеру мне довелось побывать по обе стороны баррикад, хотя, пожалуй, проводить технические собеседования приходилось всё же немного больше, чем проходить их. Но за это время у меня накопилось некоторое количество «пунктиков», которые отпугивают меня во время технического интервью и сразу в моём сознании ставят крест на дальнейшей беседе. Об этом мне и хотелось рассказать — с позиций интервьюера и соискателя. Хочу сразу оговориться, что статья отражает мои личные субъективные впечатления и не претендует на «руководство по прохождению собеседований». С другой стороны, это не минутный всплеск ярости от неудавшегося интервью, а давно взвешенный набор тех критериев, которые, хотя и по негативному принципу, позволяют мне отсеять варианты, либо самому не отпугнуть потенциально подходящего соискателя.
А что на собеседованиях раздражает или напрягает вас? Поделитесь в комментариях.
Собеседование с позиции соискателя
Каждый раз при поиске работы программисту приходится проходить множество технических собеседований. Он ходит по офисам или разговаривает по скайпу, решает задачки или делает тестовые задания, отвечает на заковыристые технические вопросы, пытаясь продемонстрировать себя с лучшей стороны. Однако и сам он при этом оценивает людей, которые собеседуют и проверяют его, думая о том, что завтра ему потенциально с этими людьми придётся работать. И есть множество способов для технических интервьюеров отпугнуть соискателя от интересной должности. Я расскажу о том, что всегда отпугивало лично меня, и чего стараюсь не допустить я как интервьюер.
1. «Какое ещё техническое собеседование?»
Первое и главное, что всегда настораживало меня в техническом собеседовании — это его отсутствие. Бывает так, что вся беседа с техническими специалистами — потенциально будущими коллегами — строится на вопросах относительно профессионального опыта: где работал, какими проектами занимался, какую функцию в них выполнял. По технологиям или знаниям — вопросы уровня «какого цвета учебник». Знаете, что такое Message Broker? Отлично, мы вас берём!
Такой подход к проведению собеседования всегда резко настраивал меня против потенциального работодателя. Мне не задали ни одного вопроса, чтобы проверить, что я действительно знаю своё дело. Выглядит это так, будто собеседующие меня люди либо сами ничего не понимают в теме и ищут хоть одного человека, который понимает, либо просто отчаялись и готовы брать кого угодно. В любом случае, в коллективе, набранном подобным образом, мне едва ли захочется работать.
2. «Ну и чем вы там занимались в этом своём…»
Удивительно, как часто встречается пренебрежительное отношение к соискателям на технических собеседованиях. Да, возможно, вы суровый и опытный программист с кучей проектов за плечами, вас оторвали от чрезвычайно важной работы ради каких-то ненужных интервью с людьми, большая часть из которых, по вашему мнению, совершенно некомпетентна. Но не забывайте о том, что вы в этот момент представляете свою компанию и свою команду, и человек по вашему поведению обязательно составит оценку о климате в коллективе и о том, как к нему в этом коллективе будут относиться. Будьте вежливы и уважительны к соискателю, даже если вы с первых пяти минут поняли, что его и близко нельзя подпускать к вашему драгоценному коду.
3. «Что-то у вас имя/фамилия/отчество в резюме неправильно написано!»
Это совсем не технический, но, тем не менее, часто встречающийся косяк даже на технических интервью. У меня, к счастью, достаточно простое и распространённое имя, и таких проблем со мной не случалось. Однако я знаю, что существует удивительно много людей, которые свято уверены в том, что определённых имён и даже отчеств попросту не существует. Они будут вас убеждать, что правильно не «Данила», а «Даниил», или что имени «Алёна» нет, а есть только «Елена». Будут предлагать исправить и записать в своих документах «правильно». С такими грамотеями-доброхотами приходится часто иметь дело людям с редкими или необычными именами, и поверьте, это невероятно раздражает. Так вот, есть одно простое правило: нет таких имён, которых нет. Правильно писать так, как записано в паспорте. Проявите уважение к соискателю и не считайте его настолько глупым, что он не в состоянии переписать из паспорта в резюме собственное имя. Если даже подозреваете ошибку, это можно уточнить как-то более тактично.
4. «Сколько шариков для гольфа понадобится, чтобы помыть все круглые окна в школьном автобусе, уменьшенном до размеров пятицентовой монеты, во время эвакуации из Сан-Франциско, используя не более 3 взвешиваний?»
Ни одна статья про собеседования не будет полной без упоминания канализационных люков. Можете считать это моим персональным пунктиком, связанным с неумением быстро и под напряжением решать нестандартные задачи. Но я уверен, что брейн-тизеры на собеседованиях абсолютно бесполезны. Вернее, это отличный способ набрать полный отдел вундеркиндов с олимпиадой головного мозга, которые круглыми днями вместо работы будут перекидываться свеженькими брейн-тизерами. Реальный программист в естественной среде обитания, даже занимающийся очень крутыми и нестандартными задачами, всё равно редко кодит под напряжением, а большую часть дня сидит и в относительно спокойной обстановке неспешно думает над тем, как ему красиво распилить код по методам. «Мозговые мышцы» для решения хитрых задачек он не задействует в этом процессе ни разу.
5. «Неправильно. Дальше.»
Конечно, заниматься обучением приходящих на собеседование людей — это не задача интервьюера. Однако, если соискатель не смог ответить на вопрос, но всё же заинтересовался, то подсказать или хотя бы указать ему на правильное решение, прежде чем переходить к следующему вопросу — это вопрос профессиональной этики, демонстрация того, что здесь ему в случае чего помогут, научат, не бросят наедине с техническими проблемами. Скажите хотя бы пару слов, что ему погуглить, что почитать. Ведь интерес к правильному решению задачи — это само по себе положительное качество технического специалиста, и не стоит демотивировать такого человека пренебрежительным отношением к его ошибкам или неточностям.
Собеседование с позиции интервьюера
Каждый раз при открытии новой вакансии ведущему специалисту или начальнику отдела приходится проводить множество технических собеседований. На собеседования приходят люди с разным техническим опытом, уровнем подготовки, ожиданиями. Для проведения собеседований нужно продумывать план разговора, составлять список вопросов, а потом пытаться по ответам на эти вопросы понять, подходит человек на должность или нет. И вот иногда соискатели на собеседованиях говорят такие вещи, что становится сразу ясно — нет, ты с этим человеком работать вместе не сможешь. Вот некоторый набор ключевых фраз соискателей, которые настораживают лично меня.
1. «Какие-то у вас вопросы теоретические. Я не силён в теории, я закалён в практике! Давайте лучше тестовое!»
Слово «теоретические» обычно произносится с пренебрежительным оттенком, как будто это что-то плохое. Но беда даже не в этом. Думаете, этой фразе предшествовала просьба интервьюера доказать теорему Коши? Дать точное определение третьей нормальной форме? Отнюдь. Такие возгласы я слышал в ответ на следующие вопросы:
- чем сравнение по == отличается от сравнения по equals в Java?
- расскажите, как устроена хэш-карта.
- объясните своими словами, что такое REST.
- что такое транзакции и зачем они нужны?
Да, с определённой позиции, любой вопрос по программированию является теоретическим, если он не требует от вас прямо здесь и сейчас написать строчку кода. Но я уверен, что человек с достаточно большим опытом в определённой области должен уметь своими словами объяснить самые базовые вещи, или хотя бы не делать вид, что их незнание — это нормально и естественно.
2. «Не ожидал здесь испанскую инквизицию! У вас прямо как на экзамене в институте. Обычно просто спрашивают, где работал, что делал»
Вы пришли на техническое собеседование. На техническом собеседовании вам будут задавать технические вопросы, чтобы проверить ваши технические навыки. Методику проверки и выбор вопросов оставьте на совести интервьюера — вопросы не всегда могут вам казаться адекватными, но интервьюер знает, какую именно информацию он хочет о вас получить, анализируя ваши ответы. Многие вопросы нужны не затем, чтобы проверить знания, а чтобы заставить вас порассуждать и посмотреть на ход ваших мыслей. Помните также, что не на все вопросы требуется идеально точный ответ, и если вы внятно ответите хотя бы на половину из того, о чём вас спросили, это уже произведёт хорошее впечатление.
3. «Мне и не нужно это знать, я специализируюсь на более высокоуровневых задачах!»
Не надо путать специализацию и незнание основ программирования. От разработчиков мобильных приложений я слышал подобные вещи про протоколы стека TCP/IP, от фронтэнд-программистов — в ответ на вопросы про алгоритмы сортировки и поиска. «Зачем мне это знать, всё есть в стандартной библиотеке, я работаю на более высоком уровне». В ответ на такие заявления я давно придумал пару небольших задачек с подло скрытой алгоритмикой — в надежде показать, что «наивное» решение, выданное от незнания алгоритмов, не выдерживает критики, и побудить хотя бы к самообразованию. Причём это не какие-то искусственно сконструированные задачи, а такие вещи, которые встречаются в разработке ежедневно. Любой код это алгоритм. Понимание основных алгоритмов и структур данных важно для любого программиста, а протоколы сети Интернет — это база, без знания которой невозможно грамотно написать хоть что-то, что выходит за пределы одного компьютера.
4. «А сами-то! / А покажите ваш код! / А вот я зашёл к вам на GitHub, а там такое...»
Меньше всего интервьюеру хочется взять человека на работу, а потом выслушивать от него критику своей кодобазы. Да, она, скорее всего, неидеальна. Да, технический долг есть везде и у всех. В любом коде найдётся что покритиковать. Но если вы действительно считаете себя настолько крутым, что видите очевидные проблемы в коде своих потенциальных работодателей — переведите это в конструктивный позитив: я знаю, как улучшить, у меня есть наработки на эту тему, я смогу принести вам пользу.
5. «Вы не правы!»
Всякое бывает, конечно, но мнение относительно неправоты интервьюера или сомнения в его компетентности лучше оставить при себе до окончания собеседования. Потом погуглите и разберётесь, кто из вас был прав. Техническое собеседование — это не место для дискуссий или самоутверждения, и вопросы здесь в первую очередь задают вам. Интервьюер не станет спрашивать о том, в чём сам не разбирается.
Заключение
А знаете, какую самую приятную вещь я слышал на собеседовании от соискателей? «Что-то я не очень наотвечал, да? А можете дать листочек? Я запишу ваши вопросы и дома поразбираюсь, даже если не возьмёте меня, хоть буду знать теперь». Слёзы гордости наворачиваются на глаза — ты не зря потратил на человека полтора часа времени, он и сам что-то вынес из этого собеседования. Даже если сейчас он слабоват для этой должности, возможно, это побудит его к самообразованию, и через годик-другой он придёт ещё раз, покажет себя с лучшей стороны и получит работу — как это случилось однажды и в моей собственной карьере.
Комментарии (146)
f0rk
17.07.2015 14:13+10А что на собеседованиях раздражает или напрягает вас?
Меня лично напрягает несоответствие требований в вакансии и вопросов на собеседовании, например, пишут нужен фуллстек js-девелопер, a на деле 70% вопросов про верстку и различия бордеров и прочих марджинов.
Нравится, когда менеджмент демонстрирует достаточную компетентность в технических вопросах. На одном из последних интервью в процессе общения с CTO подробно прошлись по тестовому заданию, я был приятно удивлен и принял предложение :)
Indemsys
17.07.2015 14:18-34Только 20 часов нужно любому человеку чтобы изучить что угодно с нуля!
Это 3-и рабочих дня.
Зачем спрашивать то, что так быстро можно изучить?
Лучше на собеседовании обсуждать и договариваться о мотивационных моделях.
forketyfork Автор
17.07.2015 14:38+12Помимо знаний, которые действительно можно утрамбовать в краткосрочную память за несколько дней (как перед экзаменом), есть ещё навыки, опыт, кругозор, которые приобретаются сотнями и тысячами человеко-часов.
vedenin1980
17.07.2015 14:44+13Только 20 часов нужно любому человеку чтобы изучить что угодно с нуля!
Ерунда,
1) вы просто не сталкивались с по-настоящему серьезными вещами, попробуйте изучить весь стек технологий Oracle хотя бы за месяц,
2) иметь отрывочные представления/вызубрить документацию и действительно знать — абсолютно разные вещи, скажем вам дадут задачу правильно спроектировать базу Oracle, оптимизировать её производительность, хранимые процедуры и прочее при том что вы даже sql не знаете, за 20 часов вы сможете выучить гайд, но не сможете выучить все best practise и в результате получится полная ерунда
monah_tuk
18.07.2015 08:27+1Спек USB и UVC класс (объёмы меньше чем стект Оракла). Хотя бы на уровне — внятно рассказать другому. Хотя, это для всего верно.
crmMaster
17.07.2015 15:16+29А потом такие вот товарищи «20-ти часовики» пишут такую хрень, что возникает желание отрубить руки.
Надеюсь, из вас подобные утверждения лезут по неопытности, и со временем вы поймете, какую ббредятину только что сморозили.
Delphinum
17.07.2015 15:21+1А как вы предлагаете мне мотивировать человека, который только через 3 рабочих дня, возможно будет знать то, с чем ему придется работать?
mark_ablov
17.07.2015 15:46ИМХО, для миддла+ самое главное это паттерны и best practices.
А их ты никак не научишься видеть за 3 рабочих дня.
Для джуниора да, N часов на технологию и вперед кодить под руководством.vedenin1980
17.07.2015 15:57+2Для джуниора да, N часов на технологию и вперед кодить под руководством.
Скорее для джуниора важнее ум, мотивация и общая адекватность, а технологию он изучить/ему расскажут по ходу дела.
ИМХО, для миддла+ самое главное это паттерны и best practices.
Брр, не согласен, ИМХО для миддла и синера важнее интуиция, которая позволяет находить золотую середину между паттерном и простой реализации, между чужими best practices и тем что реально нужно именно Вашему проекту. Как раз попытка чрезмерного бездумного следования паттернам и чужим описанием best practice и методологий характерна для сильного джуниора, а всегда вот находить золотую середину могут только хорошие миддлы и сеньоры, даже очень хорошему джуниору это как правило недоступно.mark_ablov
17.07.2015 16:08> Скорее для джуниора важнее ум, мотивация и общая адекватность, а технологию он изучить/ему расскажут по ходу дела.
Дык я об этом и написал, только не так явно.
> Брр, не согласен, ИМХО для миддла и синера важнее интуиция…
Senior — да, нужно еще больше опыта. Но для миддла достаточно идти по паттернам/практикам. Пусть даже и часто это бывает лишним для текущего проекта. Типа лепить для home page несколько слоёв абстракции, а-ля интерфейс репозитория + одна реализация + интерфейс data mapper'a + та же одна реализация под одну используемую БД + еще пара контрактов, используемых только в одном классе. Я такое видел, да.
Для меня разделение между middle и senior как раз и проходит в умении определять необходимый уровень абстракции.
maaGames
17.07.2015 15:53+4Т.е. книжки «С++ за 21 день» это для лентяев, готовых заниматься менее часа в день?
сарказм_мод_выкл
hungry_ewok
18.07.2015 16:13+9>Только 20 часов нужно любому человеку чтобы изучить что угодно с нуля!
А вы пойдете вырезать аппендицит к хирургу, подготовленному за 20 часов?
tangro
17.07.2015 15:34+12Интервьюер не станет спрашивать о том, в чём сам не разбирается.
Ага, конечно. Я когда-то на интервью доказал интервьюверу что он не прав, правда для этого пришлось вспомнить книгу и главу в ней, где данная тема освещалась (каким-то чудом я её недавно читал и помнил где искать). К его чести, он признал, что ошибался.forketyfork Автор
17.07.2015 15:48-15Я не говорил, что интервьюер не ошибается, я лишь говорил, что он не будет спрашивать о том, в чём не разбирается. Да, к его чести, он признал ошибку, но это плюс ему, а не вам. Не забывайте про человеческий фактор. Вот вы пришли к техническому специалисту, потенциальному будущему начальнику или наставнику, и в первый час общения с ним доказали ему, что он ошибается в том, в чём, как ему казалось, он разбирается. Как вы считаете, у человека возникнет желание с вами работать? Говорят, что «умников» никто не любит — здесь под «умниками» понимаются не просто грамотные специалисты, а те, кто любит спорить и доказывать чужую неправоту там, где это ну совершенно необязательно.
tangro
17.07.2015 17:10+20Если бы мне на собеседовании человек аргументированно доказал, что я ошибаюсь в чём-то, в чём я считал, что разбираюсь и это было бы действительно так — я бы начальству и HR-ам в тот же день мозг бы съел, чтобы его взяли немедленно.
forketyfork Автор
17.07.2015 17:17-1Это зависит от стиля «доказательства», конечно, но в любом случае не забывайте, что вы принимаете на работу не сумму знаний, а живого человека, и работать он будет с живыми людьми.
lair
17.07.2015 17:25+12А умение отстаивать свою точку зрения тоже полезно (и аргументированно вести дискуссию) тоже важно для выживания в коллективе. Если человек из-за боязни авторитетов не доказывает свою правоту, он может повести себя так же и при разговоре с «более опытным» коллегой, и будет принято неправильное решение.
forketyfork Автор
17.07.2015 17:42-3Согласен, это важное умение, но есть целый спектр между умением отстаивать свою точку зрения ради пользы общего дела и самоутверждением в виде попыток на каждом ровном месте доказывать окружающим, какой ты крутой. Едва ли собеседование — это адекватное место для первого. Чаще на собеседованиях проявляется что-то ближе ко второму.
lair
17.07.2015 17:45+6Собеседование — адекватное место, чтобы показать, как ты умеешь первое.
forketyfork Автор
17.07.2015 17:50-7Для этого на собеседованиях, как правило, есть специальные задачи. Например, спроектируйте какую-нибудь архитектуру кода или системы. А почему вы так сделали? А как вы учли это? А почему выбран не этот, а тот вариант? Вот это хороший повод для того, чтобы проявить умение убеждать и аргументировать. А вот «вы не правы» — типичное самоутверждение.
lair
17.07.2015 17:51+9Во-первых, таких «специальных» задач может и не быть.
Во-вторых, если человек, который меня собеседует, говорит мне что-то неправильное, откуда я знаю, он специально это говорит, чтобы меня проверить, или случайно ошибся, или действительно не в курсе?
Понимаете, собеседование — это двухсторонний процесс, мне как кандидату тоже полезно заранее знать, как люди, с которыми я планирую работать, реагируют на мое поведение.forketyfork Автор
17.07.2015 17:54-2Ну а это уже было бы из области провокаций, я мог бы добавить это шестым пунктом в «как отпугнуть соискателя». Я бы указал на ошибку, но спорить не стал бы. Если из этого следует какой-то вывод о моих личных качествах, то он, скорее всего, будет неверным.
midday
17.07.2015 21:41+6Довольно интересно было наблюдать за вашим «спором». Один вывод для себя я сделал, что особенно если тебя собеседует твой будущий руководитель, то очень полезно увидеть как реагирует именно собеседующий на такое. Т.к. бывает, что ищут именно хорошего исполнителя, который бы не лез со своими знаниями, а лучше засунул их поглубже себе. Вот если руководитель из этого плана, который не воспринимает ни аргументированную критику, не хочет слышать никаких твоих начинаний, то тут стоит задуматься. И такая же зеркальная ситуация с другой стороны бывает. Тут вопрос именно в том, кого ищут все-таки?
Мне интересно работать конечно с теми, кто может сказать «вы не правы», даже если это утверждение ложно. Т.к. после окончания дискуссии каждый участник уже чему-то научится. А в конце концов научатся проводить продуктивные дискуссии, в которых рождается истина.forketyfork Автор
18.07.2015 11:02Кроме технического аспекта «начинаний», есть ещё и аспект ответственности. С моей точки зрения, инициатива всегда приветствуется, но она наказуема. Это означает, что если человек принёс какую-то идею, то он за неё отвечает — т.е. помогает внедрять, подсказывает другим, собирает грабли, вовремя отслеживает, если идея не работает, и её надо пересмотреть и т.д.
Просто иногда случается такое, что человек приносит свою гениальную идею, а потом, когда она не работает, отходит в сторону со словами «мучайтесь сами, это не идея была плохая, это ваша задача отстой». Отвечать за криво реализованную идею приходится как раз начальнику. Поэтому начальник может не принимать идеи подчинённых не по причине того, что он самодур и считает себя умнее всех, а потому что он понимает, что отвечать за эту идею потом ему.midday
18.07.2015 14:33+4Допустим вы — начальник. А зачем подчиненный должен/обязан делать работу начальства? Это тоже одна из проблем. Если вам принесли идею, а вы ее приняли, то дальше — ваша задача не ударить в грязь лицом. Риски принимаете вы. Никто не отменял того, что в дискуссии должны оговариваться и риски. А перекладывая ответсвенность на инициатора, вы подрываете свой авторитет как руководитель в глазах подчиненных. Ну допустим, переложили ответсвенность на подчиненного, а он воплотил идею. Вы как хороший руководитель получаете все лавры, подчиненный не получает ничего, только одобрительное похлопывание по плечу, в лучшем случае премию 10 тысяч рублей, усталость, недосып, чувство обиды. Так обычно и происходит. Но что дальше? Дальше вы получили безинициативного, обиженного, нелояльного, но в тоже время отличного специалиста, что хуже лояльного плохого. Со следующей идеей он уже к вам не придет, а может и придет, но уже к вашему начальнику, расскажет о своих идеях, о своем отношении к вам. А может и вообще пойдет увольнятся и все выскажет уже большому боссу. А если человек попадется устремленным, то увольняться пойдете вы, а он сядет на ваше место.
forketyfork Автор
18.07.2015 14:39+1Я же расшифровал, какая именно часть ответственности приходится на подчинённого, а какая — на начальника. Начальник отвечает за принятое решение перед своим начальством. Подчинённый же отвечает за реализацию идеи перед самим начальником.
Иначе говоря, нормальный начальник никогда не «сдаст» подчинённого своему собственному начальству в духе «у нас не заработало, потому что имярек такой-сякой придумал хреновую идею» — потому что он сам принял решение и все шишки заранее взял на себя. Но при этом никто не снимает с подчинённого ответственность за эту идею перед его начальником и перед коллегами (в том числе и будущими разработчиками на проекте), которым тоже придётся с этой идеей потом жить.midday
18.07.2015 15:00Мы просто не поняли друг друга. Простите. Если эта идея выходит за рамки области принятия решений подчиненного, то все риски берет на себя командование. Хотите, чтобы он нес ответственность перед товарищами — повышайте его до соответствующей должности. А если же входит в область принятия решений, то тут вы во всем правы. Да. За исключением того, что риски заранее обговариваются, т.е. подчиненный должен понимать, что его «гениальная» идея не стоит этих рисков. Вот и все, тогда все довольны. Ведь зачастую, подчиненный не видит всей картины, а после отвержения его «гениальной» мысли, вы в его глазах так и останетесь «самодуром».
khim
18.07.2015 01:26Пример из жизни: интервьюер задаёт кандидату вопрос на тему работы с локами. Кандидат сразу даёт правильный ответ, интервьюер несёт полную чушь. Я (как shadow) на это смотрю с изумлением. Ну да ладно, разобрались.
Второй вопрос: развернуть строку (это было лет 10 назад, тогда эта задача не была ещё так заезжена). Кандидат (с пятилетним типа опытом работы на Java) минут пять пытается вспомнить какой функцией можно изменить букву в java.lang.String. В конце-концов, после кучи намёков интервьюер прямым текстом предлагает скопировать строку в массив. После чего ещё минут десять длятся попытки таки получить развёрнутую строку. Безуспешные.
Ваши действия? Всё ещё бежите в HR-отдел?monah_tuk
18.07.2015 08:49Если я что-то вспомнить не могу — я предлагаю сделать в лоб либо свести к известной задаче. Потом можно и гугл напрячь и книжку поштудировать, если помнить что где примерно есть. Это с точки зрения собеседуемого. А с точки зрения собеседующего, мне вот в школе привили: если ты понимаешь физический смысл явления, мы можешь привести пример в окружающем мире: очередь — она и в любом магазине очередь; стек — стопку бумаги перекладываешь, вот тебе и стек; пул воркеров (или просто пул потоков) — электронная очередь с несколькими окнами обслуживания. Я, к примеру, плохо структуры данных знаю, но есть же какой-то базис, который нужно знать и понимать.
Это как отдать машину на ремонт механику, который толком не понимает что где и как, но где-то чуйка, где-то методом тыка — бац и получилось. А когда и не всё так радужно. Со своей машиной так можно повозиться — тут только ты виноват (этот как те люди, которые для себя что-то пишут), но когда появляется ответственность перед другими — это недопустимо.khim
18.07.2015 23:37+1Если я что-то вспомнить не могу — я предлагаю сделать в лоб либо свести к известной задаче.
Похоже вы не поняли всей глубины ужаса (возможно не работали с Java'ой). Строки в Java неизменяемы. В принципе. Для того, чтобы их создавать/менять (вернее создавать новую строку с изменённым содержимым) есть StringBuffer и StringBuilder, но они, разумеется, не могут изменить строку, они порождают новую. Про эту дихотомию есть ажно статья в Википедии и куча фреймворков построены на этом разделении (не конктретно на строку и StringBuffer/StringBuilder, а на идею хранения данных в виде неизменяемых объектов). И, понятно, если человек с как бы вроде как пятилетним опытом работы этого не знает (а если про это знать то сама идея «вспомнить» каким методом меняется буква в строке выглядит дикостью), то возникает вопрос: а чем, собственно, всё это время он занимался? Как выяснилось из собеседования — тестированием. Была попытка скромно и незаметно выдать свои пять лет опыта работы тестировщиком за работу программистом. А это, увы и ах, разные вещи. Причём они разные от слова «совсем».
Это как отдать машину на ремонт механику, который толком не понимает что где и как, но где-то чуйка, где-то методом тыка — бац и получилось.
Нет, это как если бы автомеханик попытался устроиться работать конструктором. Ты можешь прекрасно разбираться в тонкостях уже существующих машин и двигателей, но из этого вовсе не значит, что ты сможешь создать с нуля свою. Для конструктора нужны совсем другие умения, чем для работы автомехаником.
strannik_k
19.07.2015 00:42Похоже вы не поняли всей глубины ужаса (возможно не работали с Java'ой). Строки в Java неизменяемы.
На мой взгляд, интервьюер не правильно пытался проверить знания о неизменяемости строк. Он дал задачу — написать алгоритм для инвертирования строки. Это сделать можно. Да, будет создан новый экземпляр строки. Но вопроса об этом и близко не было. Только телепат из такой задачи мог бы понять, что его спрашивают о неизменяемости строк.khim
19.07.2015 00:56+2Интервьюер вообще не пытался проверять как-то отдельно эти знания. Ожидалось увидеть код, разворачивающий строку, а не что-то ещё. На обсуждение же неизменяемости строк более нескольких секунд тратить никто вообще не собирался. Ожидалось замечание типа «да, строки неизменяемы, а это значит, что мы либо должны принимать массив, либо создавать новую строку...» — и дальше уже, собственно, сам алгоритм. Всё. Причём тут телепатия?
Вы же не будете проверять — умеет ли маляр одевать щётку на ручку? Дадите ему ведро краски и попросите покрасить забор, А если он в результате не дойдёт до макания щётки в ведро — то что ж с ним делать-то?
Maccimo
20.07.2015 16:24+1А, собственно, что этим вопросом пытались проверить?
Разворачивать строку банальным разворотом последовательности char-ов в общем случае неверно, эдак мы все суррогатные пары поубиваем.
senia
20.07.2015 17:37Можно и по кодпоинтам развернуть — не велика наука.
khim
20.07.2015 18:15+2После кодпоинтов пойдут всякие комбинируемые символы и разные другие чудеса. Из одной этой задачи можно много чего вытащить. Но первое, что хочется увидеть — это, чёрт побери, алгоритм, который разворачивает строку в массиве.
Вы не поверите, но как минимум ? кандидатов этого сделать неспособны.
P.S. Только не нужно из этого делать вывод, что если вы на это способны, то вы входите в «Top 25% самых крутых программистов». Нет, конечно. Просто хорошо знающие своё дело программисты, когда нужно устроится на работу, проходят интервью в одном-двух, от силы трёх, местах, получают предложение и начинают работать. А вот людям, которые программировать не умеют от слова совсем могут от слова «совсем» приходится иногда сходить в сотню мест, пока они наконец «просочатся через фильтр» и куда-то устроятся. Потому среди кандидатов идиотов гораздо больше, чем «в среднем по больнице». Кстати это полезно учитывать и когда вы устраиваетесь на работу: не обижайтесь на интервьюеров, когда они задают вам совсем-совсем элементарные вопросы — поверьте, над вами не издеваются! Если бы эти вопросы не позволяли бы отсеять внушительную часть кандидатов — вам бы их не задавали.
khim
20.07.2015 18:00Я не знаю что конкретно интервьюер хотел обсудить. Обычно следующим вопросом бывает либо как раз обсуждение суррогатов, особых символов и флагов, либо, наоборот, просят развернуть уже не строку целиком, а слова в строке и обсуждают как это всё немного порефакторить. В зависимости от того, какие слова будет кандидат произносить и вопросы задавать. Но тут всё рассыпалось на первом этапе — на попытке написать функцию в десять строк фломастером на доске.
P.S. Надо понимать, что написать десять строк на интервью гораздо, гораздо сложнее, чем написать десять строк в спокойной обстановке и на это нужно делать скидку, но всё-таки человек, устраивающийся на работу программистом, должен быть способен совершить подобный подвиг.
edwardspec
18.07.2015 12:31+6> Вот вы пришли к техническому специалисту, потенциальному будущему начальнику
> или наставнику, и в первый час общения с ним доказали ему, что он ошибается в том,
> в чём, как ему казалось, он разбирается. Как вы считаете, у человека возникнет
> желание с вами работать?
Программист, который закрывает глаза на ляпы своих коллег, чтобы их не обидеть, создаёт технический долг.
Это очень большой минус ему как кандидату.
Ну и менеджер, который одобряет закрывание глаз на замеченные ошибки — соберёт ли он хорошую команду?
dnovikoff
17.07.2015 15:54+5По собственному опыту могу сказать: очень нравится когда человек хорошо оценивает свои знания и очень не нравится, когда соискатели в своем резюме пытаются указать, что являются специалистами во всех технологиях о которых слышали.
Список технологий из резюме студента часто выглядит так: «MySQL, Postgres, Oracle, MsSql, css, html, javascript, php, C/C++, Rust, Golang, XML, Pascal, Delphi, Python, Java ...»
Резюме профессионала часто содержит в себе самый минимум того в чем он действительно разбирается. При этом о многих побочных (для него) технологиях он имеет хорошие средние знания.
Если человек заявляет, что он специалист в технологии X, а сам путается в основах — это крупный минус.
Если человек говорит, что он «с этой технологией не очень много работал», но выдает уверенные знания по теме с ньюансами, то это жирный плюс. Даже если он чего-то про это не знает — то это не будет минусом — он же не заявлял себя специалистом в этой технолгии.monah_tuk
18.07.2015 08:53+5меня в резюме смущает запись C/C++: как показывает практика, хорошие С-программисты пишут плохой код на С++, обратное тоже, отчасти, верно, но не на 100%.
Vayun
18.07.2015 11:17+4В 90% случаев такая запись означает «прослушал курс С/С++ в университете». Тому кто хоть сколько-то работал с любым из них в голову не придет эти языки так сгруппировать.
justaguest
18.07.2015 13:25Например моя повседневная работа и бывший хобби-язык (сейчас сменился на Haskell) связаны с С++. При этом я знаю так же и слой различий под чистый С, т.к. в свободное время иногда отвечаю вопросы на StackOverflow, которые больше любят тэгировать под С — и там в комментариях приходилось участвовать в разного рода каверзных дискуссиях на эту тему. И в самом начале я кодил на С++ как на С.
Я думаю, я бы подошел к программированию на чистом С, как на зверски урезанном Хаскелл. Мне не известны минусы этой идеи.
RomanArzumanyan
20.07.2015 18:55+2Полагаю, дело в том, что С++ — понятие растяжимое. Формально, процедурное программирование в стиле С — тоже С++. Лично меня раздражает, когда под программированием на плюсах подразумевают только высокоуровневое ООП.
stack_trace
22.07.2015 22:30Высокоуровневое ООП на плюсах — это как? И чем оно отличается от невысокоуровневого (или не ООП?)
maaGames
17.07.2015 15:57+15Как-то чуть не устроился админом в сеть кафешек. На собеседовании меня спросили, какая сейчас самая мощная видеокарта (мой ответ был устаревшим примерно месяца на три-четыре, потому что я не мониторю железячные новинки). С чувством собственного превосходства и снисхождения мне рассказали, какая карта была самой крутой. На мой вопрос, зачем в кафе игровая видеокарта и, что я могу подобрать оптимальную для задач конфигурацию, ответа я не получил.
a_mastrakov
17.07.2015 16:36+5Меня вот например в принципе раздражают собеседования формата вопрос-ответ, ибо собеседование процесс двусторонний, а такой формат просто убивает возможность понять, с кем придется работать и не позволяет ответить на главный вопрос, после собеседования — не мудак ли мой будущий начальник.
На текущем месте, перед собеседованием сделал тестовое задание, а собеседование больше походило на дружескую беседу программистов о своем опыте и взглядах на штуки типа ооп, паттерны и прочие best practices, по ходу решил несколько задачек по алгоритмам и то не все до конца и мы обсудили какие еще есть варианты решения и написал на бумажке 20 строк кода. Ни одного вопроса по синтаксическим конструкциям, деталям реализации какой-нибудь фигни и прикладным технологиям не было, ибо правильно написали выше, любую технологию изучить не проблема, особенно если коллеги с ней знакомы.forketyfork Автор
17.07.2015 18:11-1Естественно, универсальных способов построения команды нет. Для кого-то нормальный начальник («нему*ак» в ваших терминах) — это тот, с которым можно потрындеть про шутки на тему ООП и паттернов, а для кого-то — тот, кто всё под контролем держит и умеет нормально работу команды организовать. Далеко не всегда эти вещи совпадают.
dzugaru
18.07.2015 02:49+4«расскажите, как устроена хэш-карта»
Это hashmap так перевели? )khim
18.07.2015 23:47Похоже на то.
У меня есть похожий вопрос про C++: «расскажите про то, как в C++ устроен std::map»…
Если кандидат честно заявляет, что про C/C++ он написал в резюме, потому что знал, что у нас программируют на C++, а так, в общем, он прослушал курс С/С++ в университете и всё, то вопрос немедленно меняется: «расскажите про то, как в C++ мог бы быть устроен std::map при условии, что стандартная библиотека также содержит тип std::unordered_map?»…
Хороший кандидат может много рассказать полезного/интересного даже притом, что он ничего не знает о С++, но знает о том, что его создатели были весьма озабочены эффективностью кода. Причём, что парадоксально, я предпочту взять на место C++ программиста такого кандидата скорее, чем кандидата, который помнит наизусть все сложности всех методов std::map'а (да-да — в стандарте это описано), но не понимает — почему они такие (в стандарте C++ этого нет, есть немного в стенограммах обсуждений стандарта).
memkill
21.07.2015 16:20Тоже запнулся на этом месте. «Хэш-таблица» вроде принято по-русски. Поискал в гугле «хэш-карта», первый результат — страница Вики «Хэш-таблица» :)
tgz
18.07.2015 08:30+3Я не программист, но меня как соискателя отпугнули только один раз. Интервьюер был полный мудак. Когда об этом тебе говорит сотрудник отдела кадров перед тем как передать тебя на техническое интервью — такое было только один раз.
Suvitruf
18.07.2015 10:58+6Напрягают собеседования в большие конторы, где интервьюирующие считают себя асами, а соискателя, простите, говном. Особенно это любят ребята из Яндекса. Ощущение складывается, что они не нового сотрудника ищут, а просто развлекаются и собственное ЧСВ тешат.
grafmishurov
18.07.2015 11:48Скорее всего это про московский офис, работает знакомая, с которой в институте учились, судя по тому, как изменились ее манеры, там такая идеология в компании. Ну и рекомендую пропускать мимо ушей и быть готовым к тщеславным людям, громкое имя всегда подобный контенгент привлекает. И не забывайте самое главное, что работать там — это быть всегда вторым после Google.
ZloyHobbit
18.07.2015 11:50+1Такое случается очень много где. На счет Яндекса не знаю, я с ребатми от туда общался долго и с удовольствием. Причем с большой пользой для себя и не один раз =) Собеседование в Яндекс вообще удобно использоваться для того что бы получить множество подсказок, что полезно выучить для полее глубокого развития в своей области.
Другое дело, что завастую абсолютно непонятно зачем нужен такой уровень знаний на указанной должности. Лично я для себя решил что просто слабо представляю, чем они там занимаются.grafmishurov
18.07.2015 12:03+1Уровень знаний адекватный требуется, учитывая их масштабы задач. Я согласен с той точкой зрения, что даже сисадмин должен понимать что-такое опкоды, системные вызовы, kernel threads и мало-мальски уметь что-нибудь состряпать на C при необходимости. Тут не об этом, о том, что у них с ЧСВ какие-то проблемы, считают почему-то, что за пределами Яндекса жизни нет, и надпись «Яндекс» в профиле дает индульгенцию хамить всем подряд.
ZloyHobbit
18.07.2015 12:06Как раз сисадмин очень хорошо должен понимать, что такое системные вызовы, он с ними работает, другой вопрос, должен ли это понимать дежурный администратор, который парсит логи и говорит какой сервис сломался.
Ну а ЧСВ — от людей зависит. Я с этим сталкивался, когда решал задачки на стажера С++, а вот когда с инженерами общался — проблем не было.grafmishurov
18.07.2015 12:12Ну так про ЧСВ и речь, и конечно зависит от людей. В крупных компаниях, а особенно у таких эстрадных звезд как Яндекс, процент тщеславных и высокомерных на порядок выше, ну и атмосфера и окружение меняют самомнение.
webkumo
18.07.2015 12:48+1«дежурный администратор, который парсит логи и говорит какой сервис сломался» — это как? а как же системы мониторинга-оповещения???
foxmuldercp
19.07.2015 01:01-1Сломаться можно так, что система мониторинга этого и не заметит. К примеру — пинг есть, ок, порт слушается — ок, а дальше демон замер и все.
agent10
18.07.2015 12:55Было у меня собеседование в Яндекс 1.5 месяца назад. 5 видео интервью из разных городов. Никто асами себя не считал, меня никто с говном не смешивал. Со всеми отлично пообщались… может мне повезло…
maxlips
18.07.2015 16:54+2На Яке был такой диалог о видеостримминге моего друга (техдир на телеканале) с парнем из Яндекса:
Друг: Что ты думаешь о технологии XXX?
Яндексоид: Первый раз слышу.
Друг: Ну как же, это YYY.
Яндексоид: Если я об этом не знаю, значит это не важно.
А на Субботниках все улыбаются и машут.dborovikov
19.07.2015 00:43Да, чувак дерзкий попался :) Можно было его в ответку подколоть, типа, да может и не важно, но не важно для Яндекса, что ничего удивительного, т.к. вы там поди технологии каменного века используете, с чем вас и поздравляю ))
maxlips
19.07.2015 05:53Вы не знаете сути вопроса, а пытаетесь сделать вывод. Не повторяйте его ошибок :)
dborovikov
19.07.2015 13:29На борзость можно только борзостью ответить увы. Вы же понимаете, что такие люди другого языка не понимают?
dborovikov
19.07.2015 00:37-1Я и работал в крупных конторах и соответсвенно на собесах был не раз. Так вот, это скорее вы на себя как-то не правильно переносите. С говном никого не машают, задают в основном стандартные вопросы, но из области базы + да, бывают довольно сложные алгоритмические задачм, и странно, что они оказываются полной неожиданностью для соискателей. Почему-то в народе бытует такой наивный подход, что достаточно почитать доки по библиотекам, там или стековерфлоу, и все, ты программист. Как программист может называться оным без базовых знаний алгоритмов и структур данных и problem solving skills?
Suvitruf
19.07.2015 09:06Про вопросы ни слова не написал я. Спрашивали у меня алгоритмы, и это нормально. Моё сообщение было про отношение интервьюера.
RicoX
20.07.2015 13:47Тут похоже как повезет, года 4 назад тоже собеседовался к ним (московский офис), хоть и не взяли в итоге, но ничего плохого сказать не могу, оплатили перелет из другой страны, на собеседовании (второе техническое после скайпа) около 2х часов общались на интересные темы и технологии, меня собеседовало 3 специалиста, все адекватные, вежливые и оставили приятное впечатление, так что похоже сильно зависит от отдела куда собеседоваться, гадюшники бывают везде, но я бы не делал такое заключение о всей компании на основе единичного опыта.
ZloyHobbit
18.07.2015 12:03На самом деле большой вопрос, надо ли разработчику fe знать стек TCP/IP. Если рассматривать сферической IT в вакууме, то конечно всем надо знать все и чем больше знаешь в любой области — тем лучше. Но на самом деле, как разработчик fe должнет учитывать в своей работе ограничение MTU на последней миле? В общем виде, что такое, ip адрес, знания, думаю есть у всех, а более глубокие — это уже не его область ответсвенности. И к тому же такой подход — предпосылка к созданию вакансий: Инженер программист со знианием C/C++, php, ruby, java, js, mysql, postresql, oracle, mongodb, html5, css3, less, sass, tcp/ip, cisco, hp, junifer… ПУЭ.
forketyfork Автор
18.07.2015 14:27-1Если под «фронтэндом» вы понимаете «программирование браузера», то пожалуй, хотя даже там это важно. Например, чтобы не городить велосипедный транспорт поверх HTTP/REST там, где можно перейти на более низкий уровень, или чтобы понимать, как работает TLS и сертификаты. А если рассматривать понятие «фронтэнд» как разработку клиентского ПО вообще, то там такое понимание незаменимо.
По-хорошему, любой разработчик приложений, которые что-то передают/принимают по сети, должен хотя бы примерно представлять себе, как происходит весь процесс передачи данных на всех уровнях, и к кому бежать, если что-то пошло не так. Область ответственности быстро расширяется, когда что-то не работает, и человек не может не то что решить проблему, а даже диагностировать её, чтобы определить эту самую область ответственности.webkumo
18.07.2015 19:08+3Что-то не припомню ни одного случая, когда требовалось именно знание стека TCP/IP (хотя я его неплохо знаю). При этом я не FE (хотя и такую роль иногда играю), а больше по бекэнду. Реально знание TCP/IP нужно тогда, когда приходится городить свой протокол.
khim
18.07.2015 23:57+3Но на самом деле, как разработчик fe должнет учитывать в своей работе ограничение MTU на последней миле?
Очень просто: он должен понимать, что современные сервера настраиваются на initial congestion window в 10 сегментов, а более старые — на 2-4 сегмента. А это значит, что если ты хочешь получить хороший, отзывчивый, сайт, то тебе нужно сделать так, чтобы пользователь что-то увидел получив первые 14600 байт (а то и 2920 байт).
michael_vostrikov
19.07.2015 19:58+1По поводу протоколов TCP/IP и других подобных вопросов. Года 3-4 назад я мог в сетевом дампе разобрать начало IP-кадра, узнать значения флагов, и предположить, какие данные придут дальше. Сейчас я практически ничего из этого не помню, просто потому что этим не занимаюсь. Основы основами, но если человек хороший фронтенд/бэкенд разработчик, то совсем необязательно, что он знает тонкости смежных областей.
YChebotaev
20.07.2015 08:22+1Вы бы сами для начала своим же статьям следовали.
Извините, конечно, но конкретно в этой компании процесс прохождения резюме построен просто отвратно: вначале hr не прочитал мое резюме и пригласил на собеседование, затем, «технический специалист» — тимлид тоже не удосужился прочитать резюме, да еще и нахамил.forketyfork Автор
20.07.2015 10:05-1Мне очень жаль, если у вас остались плохие впечатления о нашем собеседовании. У нас достаточно большая компания, много подразделений, куда набор идёт по совершенно разным критериям. Я отвечаю лишь за набор людей в свои команды, поэтому не в курсе всех происходящих интервью. На какую именно вакансию вас пригласили, и чем обидели?
YChebotaev
20.07.2015 10:22Я не знаю, на какую вакансию меня пригласили. Мне это не сообщили, а я понадеялся, раз люди звонят, значит, прочитали резюме и им понравилось то, что они прочитали (можно еще статью дополнить: не говорят, на какую вакансию, и не говорят какие обязанности).
По факту выяснилось, что ни резюме ни читали, ну и почти что все антипаттерны из вашей статьи на этом собеседовании со стороны вашей компании были применены. И, между прочим, это было в екатеринбурге, так, что, скорее всего, прямо в вашем офисе, и я не уверен, что это были не вы.forketyfork Автор
20.07.2015 10:56Нет, это был не я. Думаю, меня при желании можно опознать по аватарке: о)
Если HR не сообщил вам, на какую вакансию вас приглашают, это, конечно, не очень хорошо с его стороны. Но вообще совет лично от меня как от человека, много походившего по собеседованиям — следует помнить, что HRы далеко не всегда разбираются в тонкостях технологий и ориентируются в основном по ключевым словам в резюме. Нет смысла судить их за это, они не технические специалисты. Поэтому лучше не идти на собеседование вслепую, а всё же самостоятельно уточнять такие вещи, как вакансия и список требований, заранее. Не стоит надеяться на то, что ваше резюме правильно соотнесли с вакансией и догадались, какую именно должность вы ищете, особенно если в резюме написано «всё умею, всё могу»: о)YChebotaev
20.07.2015 11:51+1Проблема заключается в том, что вакансии составляют тоже не очень разбирающиеся, и требования часто противоречивые и не соответствуют реальности.
Как раз-таки к тому, что мое резюме не соотнесли с вакансией я не жалуюсь. А жалуюсь я на то, что то, что происходило во время интервью прямо противоречит статье в блоге компании за вашим авторством.
У вас так принято — смеяться над резюме соискателей?forketyfork Автор
20.07.2015 12:12-1Я не смеялся над вашим резюме, как раз наоборот, отметил, что спектр указанных там умений достаточно широкий, его сложно подогнать под какой-то ограниченный набор вакансий, и такие ошибки неизбежны. С таким резюме вам неизбежно придётся самостоятельно отсеивать все поступающие предложения, не надеясь на то, что резюме правильно истолкуют HRы, чтобы не погрязнуть в бесконечных собеседованиях на самые разнообразные вакансии.
YChebotaev
20.07.2015 12:34+1Повторюсь. Я не жалуюсь на то, что не подошел для вакансии, я думаю, что это нормально — подходить не везде.
А вот ваша статья, размещенная в блоге компании явно не соответствует принятой в вашей же компании практике:
Вот например, 1. «Какое ещё техническое собеседование?». Со мной не проводили технического собеседования.
Пункт 2. «Ну и чем вы там занимались в этом своём…». Технического специалиста явно оторвали от очень важных дел, и всем своим видом он показал, что тратит напрасно свое время.
Пункт 5. «Неправильно. Дальше.». Выслушав мой рассказ о том, где я работал и что делал (что и так было написано в резюме), ваш технический специалист просто выгнал меня, даже не обмолвившись почему я, в итоге, не подхожу.forketyfork Автор
20.07.2015 13:13В статье речь идёт не об отсутствии технического собеседования, а о той ситуации, когда кандидата готовы принять без технического собеседования. Как я понимаю, оффер вам не делали, так что это не ваш случай. Рассказать своими словами о рабочем опыте — вполне нормальная просьба интервьюера, даже если всё подробно расписано в резюме, ведь на работу принимают не резюме, а живого человека.
«Выгнал» — сильное слово, это в моём понимании когда вам говорят «пшёл вон, свободен». Не могу себе представить что-то подобное из уст моих коллег. По окончании собеседования никто вам не скажет «вы нам не подходите, потому что...» — обычно интервьюер просто заканчивает собеседование тогда, когда считает нужным, и по его результатам составляет внутренний отзыв, который, естественно, никто и нигде вам не предоставит. При наличии положительного отзыва вам могут сделать оффер. Это абсолютно нормальная процедура проведения собеседования.YChebotaev
20.07.2015 15:01Возможно, вы это имели в виду, но написали другое. В моем случае все ровно так как вы написали, но с противоположным знаком. «Мне не задали ни одного вопроса, чтобы проверить, что я действительно знаю своё дело.». Не могу утверждать наверняка, но, возможно, если бы такие вопросы задали, это бы повлияло на итог. А так получается, по каким-то формальным признакам отбраковка, как будто бы на работу принимают не живого человека, а резюме.
Вы искусственно критерии сужаете. Вроде как, раз «пшел вон, свободен» не сказали, значит, все норм. Пренебрежение можно выразить не только матом и руганью. А, например, посмеявшись над моими словами (это ваш коллега себе позволил). Тут вообще никаких слов нет, а все равно неприятно. До внутреннего отзыва дело не дошло (может быть и дошло, раз у вас такое предвзятое обо мне мнение), меня выпроводили сразу же по окончании.
Что касается моего резюме, то что делать, если я действительно все, что у меня там указано, продуктивно применял, умею с этим работать, и могу сделать с места в карьер то, чего еще не делал? Строчка «все умею, все могу», ироничная, разумеется, но и во многом правдива.
ZloyHobbit
20.07.2015 15:38На самом деле чтение резюме — это бич современных HRов. У меня сложилось ощущение, что большинство этого не делают принципиально. К примеру у меня было два-три месяца открыто на hh резюме дежурного инженера. Помимо включенного пункта «Посменный график», я специально написал в резюме что учусь в аспирантуре и ищу исключительно посменную работу для совмещения. С частотой 2-3 раза в неделю мне приходили приглашения на полный день, причем один раз даже на вакансию Java Dev, хотя я явы не знаю и никогда ничего про нее не писал.
Так же очень расстраивает некорректное заполнение форм на сайте, к примеру на том же hh очень часто в вакансии написано что она посменная, а в соответсвующем поле «Полный день», или «Гибкий график», и либо приходится пересматривать вообще все вакансии, либо фильтр осеивает две трети нужных.
kloppspb
20.07.2015 17:00+1Ну да, неоднозначность на HH присутствует. Там же есть две группы: «занятость» (частичная, полная, ...) и «график работы» (полный день, удалёнка, ...). У меня указано: 1) полная занятость и 2) полный день, удалённо. Люди видят полный день/полная зянятость и уже не видят ни галочку «удалённо», ни явное указание этого в тексте.
Но и HR-ы тоже молодцы. Несколько раз умудрялись уточнить — не напутал ли я сам чего в своей же анкете. По их представлениям понятия «удалёнка» и «полный день/полная занятость» почему-то не совмещаются…
khim
20.07.2015 18:22+3На самом деле чтение резюме — это бич современных HRов.
К сожалению это бич вообще всего IT-рынка в России.
У меня сложилось ощущение, что большинство этого не делают принципиально.
Вы почти правы. Проблема в том, что в России очень плохо пишут резюме и, как следствие, на них обращают очень мало внимания при рассмотрении. Да собственно вы сами об этом пишите:Так же очень расстраивает некорректное заполнение форм на сайте, к примеру на том же hh очень часто в вакансии написано что она посменная, а в соответсвующем поле «Полный день», или «Гибкий график», и либо приходится пересматривать вообще все вакансии, либо фильтр осеивает две трети нужных.
У HR'ов та же история — если они будут отсеивать людей, которые по формально заполненным признакам, им не подходят, то они пропустят две трети хороших кандидатов.
SirArhey
21.07.2015 14:12+1У меня был не большой опыт собеседований. Но безусловно смущают стандартные вопросы про люки, почерпнутые из паблика «Все для HR» и «Это интересно».
А еще я бы добавил, что соискателя на собеседовании может смутить излишняя суровость интервьюера. Собеседующий должен показать, что помимо интересных задач, карьерного роста и т.д. в колликтиве хороший микроклимат. В свое время, когда я пришел на собеседование на должность QA (не обладая большими знаниями, но стремясь их получить) меня спросили знаю ли я что такой bash, то я вместо того чтобы ответить, что это командная оболочка, переспросил: «Это цитатник рунета?», ребята посмеялись. Тон беседы был задан. В итоге меня подкупила простота общения с начальством отдела. Начальник и его зам серьезные вопросы могли разбавить шуткой, это как-то настраивает на хороший лад и демонстрировать свои знания/умения становится проще.
Sequd
А где самое интересное?
f0rk
Из прикладного приходят в голову автоскейлинг чего угодно в зависимости от нагрузки, управление лифтами… все, закончилась фантазия.
forketyfork Автор
На такие задачи многие специалисты по фронтэнду и мобильной разработке справедливо делают удивлённые глаза: «зачем мне это?»
Самое простое — дайте человеку todo-список и функцию сортировки и попросите найти самую раннюю по дате задачу. Далеко не все уловят подвох и спросят «а зачем сортировать, когда достаточно одного прохода?»
Или попросите в том же списке организовать возможность связи между задачами, но попросите не дать пользователю возможности сохранять задачи с кольцевыми ссылками, например.
lair
Мне очень стыдно, но я тоже не вижу подвоха. Почему одного прохода недостаточно?
forketyfork Автор
Спросят как раз те, кто уловит подвох. Большинство соискателей говорят «отсортирую и возьму первый элемент», а сложность такого решения в среднем будет линеарифмическая. И даже на вопрос «а можно проще?» отвечают не все.
lair
А. Я просто удивился, подумав, что вы считаете, что надо сортировать, а это очень странно.
С другой стороны, будем честными, почти во всех современных языках и СУБД будет использоваться подход «отсортируй и возьми первый» (хотя, скажем, в F# есть
minByиmaxBy).forketyfork Автор
Ну не знаю. В СУБД да, это стандартный подход, и меня это несколько смущало всегда. В Java рядом с Collections.sort есть Collections.min и Collections.max, и всё равно все фигачат сортировку для поиска граничных элементов.
lair
А зря смущаетесь, кстати. SQL- декларативный язык, вы не знаете, как именно будет выполнен ваш запрос (например, если там был индекс… ну вы понимаете). Аналогично и в последовательностях, если захотеть — можно написать итератор, который даст сублинейное время (например, на основе алгоритма быстрой сортировки).
forketyfork Автор
Да, но всё равно для достаточно частой задачи получения строки с экстремальным значением в этом декларативном языке нужно встать на уши, и выглядит полученная конструкция неинтуитивно. Предполагаю, что и оптимизатор там нетривиальный для распознавания таких ситуаций.
vedenin1980
Ээээ, зачем вставать на уши-то? Select max(field1) from table1 group by field1; — что же тут неинтуитивного-то?
forketyfork Автор
Это вы максимум нашли, речь шла про строку с экстремальным значением в одном из полей.
vedenin1980
Эээ, а пример может показать?
forketyfork Автор
У меня есть табличка с задачами todo_tasks, там есть поля id, name и created_timestamp. Я хочу найти самую раннюю задачу, т.е. ту, у которой значение в created_timestamp минимально. «Найти строку» — т.е. найти её идентификатор id, либо сразу всю строку. Без подзапросов или джойнов на стандартном SQL вы такое не напишете. Как-то так, например:
lair
Вообще, конечно,
forketyfork Автор
Да, а в других базах есть ещё FIRST, LIMIT и т.д. Я говорил про стандартный SQL.
lair
А смысл ограничивать себя ANSI, если в каждой БД есть своя оптимизация?
forketyfork Автор
Нет, на практике всегда можно выкрутиться родным диалектом SQL, спору нет, но даже в вашей конструкции есть некоторая неинтуитивность. ORDER это всё-таки глагол, и мне надо очень постараться, чтобы увидеть в этой конструкции декларативное описание того, что я на самом деле хотел получить.
lair
Там, вообще-то, все операции — глаголы (прямо начиная с SELECT), это нормально. Ну да, в SQL не заложили nth order selection, бывает — семантика «отсортируй/выбери» тоже неплоха. Что там внутри — вы все равно не знаете, а предполагаете.
khim
К сожалению «что там внутри — вы все равно не знаете, а предполагаете» на практике не работает. Если хотите, чтобы ваши запросы отрабатывались быстро — нужно знать. Потому реально SQL очень часто используют не по делу. Если у вас SQL запросы не формируются программой, а статичны — в 9 случаях из 10 вам SQL не нужен и будет только мешать. Вырезание аппендицита не снимая пальто. Вот когда запросы заранее неизвестны — другое дело, тот SQLю найти альтернативу сложно.
lair
Может, вы объясните, что вы хотели сказать?
Вот у меня есть база данных. Почему, если у меня к ней есть статичные и хорошо известные запросы, мне не нужен SQL?
(не говоря уже о том, что в данном треде о статичности вообще никто ничего не говорил)
grayhat
Прежде чем начинать выпендриваться своими нанооптимизациями, стоит вспомнить про benchmark.
А то программа после этих нанооптимизаций начинает медленней работать.
forketyfork Автор
При чём тут нанооптимизации? Я привёл совершенно типовую реализацию задачи на стандартном SQL, в котором LIMIT отсутствует.
bolk
В SQL2008 есть FETCH FIRST n ROWS ONLY (работает в Оракле, Постгресе, ДиБи2 и в микрософтском сервере), в SQL2011 есть OFFSET n ROWS (работает там же + несколько СУБД пожиже).
Bronx
1. Зачем тут group by?
2. Ваш запрос потенциально может вернуть более одной записи, в нарушение условий задачи.
forketyfork Автор
Да, там ошибка, не проверил перед отправкой. Хотел только показать идею.
BearUA
Кстати говоря, максимум вы нашли неправильно. Этот код даже не запустится.
alekciy
Правильно ли я понимаю, что у человека при этом есть контекст "В Java рядом с" (просто без этого решение выглядит не так однозначно; да, привет РСУБД).
forketyfork Автор
У человека есть контекст в виде процедурного языка программирования общего назначения, в котором есть циклы, присваивания и операторы сравнения. Этого достаточно, чтобы решить задачу в один проход.
webkumo
Если задачу поставить как «Есть todo-лист, есть сортировка, напишите поиск» — то больше половины (мне даже кажется — значительно больше) опрашиваемых будут делать поиск через сортировку.
forketyfork Автор
Да, сам по себе ответ «отсортирую и возьму первый элемент» ещё ничего не значит. Самое интересное начинается тогда, когда интервьюер задаёт вопрос «а можно быстрее?»
webkumo
И я в такой ситуации могу и сообразить, а могу и затупить окончательно «чего он от меня хочет»… Тут от ситуации зависит — есть ли контакт с интервьером, важность конкретной вакансии для меня и ещё кучи факторов.
В общем, имхо, проще сразу как-то разграничить todo-листи сортировку… тем более, что сортировка для todo-листа вещь ну очень абстрактная.
khim
Если вы «затупите», то ничего страшного не произойдёт: просто вас не возьмут на работу. Самой главной задачей интервьюера не является отбор всех хороших кандидатов, самой главной задачей является отсев плохих кандидатов, задача отбора хороших всё-таки вторична.
Просто потому что последствия несравнимы: отсев хорошего кандидата обозначает, что вакансия ещё несколько дней (ну, может быть, недель) повисит, приём на работу плохого — последствия могут быть самыми различными, но в самом благоприятном случае — это несколько месяцев «выпитой крови» у остальных разработчиков.
vedenin1980
Эээ, странное у вас понятие о задаче приема сотрудников, действительно хороший разработчик может разработать новую архитектуру, исправить косяки старой и вообще спасти проект, который могут загубить чуть менее хорошие разработчики… но вы его отсеяли, потому что он не вспомнил алгоритм красно-черного дерева, который вообще никогда не требовался и не потребуется в реальной работе.
Прием на работу плохого это лишь потеря денег на зар.плату испытательного срока, а вот отсев очень хороших разработчиков это снижение общего уровня команды, что может быть фатально (действительно сильных разработчиков дефицит, а ошибочно отсеев очень хороших, вам останется просто хорошие, то есть более слабые разработчики). Так что это палка о двух концах, если вам реально нужны разработчики, а не просто исполнители.
khim
Честно говоря не хочется с вами спорить. Когда в ответ на давно всем известные банальности (да-да, банальности, надо понимать что статьи Джоэла никаких откровений никогда не содержат, они просто хорошо описывают то, что «люди в теме» и так хорошо знают) начинаются какие-то странные абстрактные рассуждения неизвестно о чём…
Возможно мы опять говорим о каких-то других мирах? На всякий случай — я из мира «ширпотреба», где продукты разрабатываются годами, а используются миллионами. Впрочем я, если честно, людей и из других миров не встречал, которые кого-либо нанимали на работу руководствуясь другими подходами… ну то есть я видел много разработчиков которые считали, что «так нанимать людей нельзя», но никого из тех, кто решал — принять кого-то на работу или нет исповедующего вашу религию я, если честно, не встречал. Среди успешных компаний, по крайней мере. Легко могу поверить что в компании, которая и так готова вот-вот развалиться кто-то и будет так думать… но стоит ли туда идти работать?
А вы-то сами с какой «стороны баррикад» находитесь? Сколько людей проинтервьюировали, скольких с вашей подачи наняли? Мне вот «герои» способные спасти проект в одиночку не встречались, а вот «выродки» способные его извести встречались неоднократно — но возможно в других «мирах» по-другому…
vedenin1980
Сразу с двух сторон
Больше сотни, несколько десятков.
Вопрос не в спасти, вопрос в том что чтобы выбрать правильную архитектуру и правильную технологию нужен соответствующий уровень экспертизы, много раз встречал ситуации когда хорошие кодеры тратили кучу времени реализации ошибочной архитектуры или не верной технологии, потому что не было в команде человека с достаточным уровнем компетенции, который мог бы предложить правильный и короткий путь.
На самом деле, найти отличного специалиста с высоким уровнем компетенции очень сложно, насколько сложно что компании готовы выплачивать изрядные бонусы тем кто порекомендует такого специалиста для найма. Возможно в Вашем мире, хорошими специалистами можно разбрасываться, в нашем — нет.
khim
Хорошими специалистами разбрасываться нельзя, «хорошими» кандидатами — легко.
Вообще в вашей фразе словосочетание «хороший кодер» меня несколько покоробило. Это вообще кто? Джуниор, который ещё опыта не имеет и потому не может сам спроектировать архитектуру? А как так получилось, что в команде одни джуниоры собрались? Вам не кажется, что подобные проблемы — как раз следствие того, что вы очень «бережно» относитесь к кандидатам и потому у вас нехватка людей «с достаточным уровнем компетенции»? Как-то само описание ваших проблем ну никак не наводит на мысли о том, что ваш подход привёл к тому, что уровень команды оказался офигительно высоким.
khim
А вообще, похоже, проблема даже не в том с какой стороны баррикад вы находитесь, а скорее в каком мире вы живёте. И тут мир «ширпотреба» (в котором, как я уже рассказывал, я и живу) резко отличается от мира заказного ПО или внутреннего ПО. Потому что в случае заказного ПО или внутреннего ПО «какой-нибудь» результат — часто лучше, чем никакого. Контракты, сроки, etc. Отсюда и появляется желание «не упустить» мало-мальски грамотных людей, а после набора пресловутых «хороших кодеров», которые сами не видят проблем в архитектуре, начинаются проблемы с архитекторами, которые все их косяки не могут предугадать и т.д. и т.п.
В мире «ширпотреба» жизнь устроена совсем не так. Продажи «продукта №1» и «продукта №2» отличаются на порядок. Иногда — и не на один. Отсюда следует правило: никому не нужен «продукт №2». Речь всегда идёт только и исключительно о первом месте. Понятно, что первое место может принадлежать только одному продукту и иногда (достаточно редко) компаниям удаётся перейти с первого места но второе, это всё понятно. Главное — что вы никогда не будете и пытаться сделать продукт, который не планируется вывести на первое место. Вам на это никто денег не даст! Речь идёт только о том когда и как вы завоюете первое место, сама цель даже не обсуждается.
Отсюда и требования к командам и вообще рекрутингу: лучше не нанять никого (в этом случае вы «пропустите» всего лишь очередную попытку сделать что-то, что «всех удивит»), чем нанять кого-то неподходящего. Соответственно ситуация «а в команде не было архитектора и потому кодеры потратили время впустую» не возникает в принципе: никаких «кодеров» у вас в команде просто нет и быть не может, а если кто-то и потратил время на «кривую» и плохо работающую архитектуру — так это его вина в первую голову. Даже если архитектуру разработал кто-то с большим опытом — у него-то где была голова, когда он начал её реализовывать и понял, то так — оно работать не будет?
Если так — тогда разница в подходах понятна и простительна. Но только тогда уж и называть вещи нужно своими именами: в первом случае, когда вы «боитесь упустить» хороших разработчиков вы получаете в основном «просто исполнителей», а во втором случае — да, у вас будет команда разработчиков, причём хороших разработчиков. Хотя, возможно, и меньшего размера чем вам бы хотелось. Отсев хороших кандидатов ну никак не может «снизить общий уровень команды» — за исключением только лишь патологических случаев, когда вы умудряетесь отсеять хороших кандидатов, но почему-то берёте плохих. Но для мира ширпотреба это — никогда не проблема, там «закрытие плана по валу» не висит на интервьерах никогда. Как пишет Джоэл: «Это не ваша проблема. Это проблема рекрутеров и отдела кадров, это проблема Джоэля, но никак не ваша.» Откуда при таком подходе у вас в команде возьмутся «просто исполнители»? Непонятно.
ZloyHobbit
Вот если вы прийдете на собеседование к плотнику и он вас попросит забить шуруп молотком, то половина народу забъет-таки этот шуруп молотком, не потому что они про отвертку ничего не знают, а потому что их конкретно попросили забить шуруп. И если потом их спросят: «а нельзя ли сделать это быстрее?», то далеко не все подумают о том, что можно взять шуруповерт, ведь в контексте забивания шурупов скорее подходит молоток потяжелее.
forketyfork Автор
Отличный пример. Вот я предпочту взять тех немногих, кто выкинет молоток и попросит шуруповёрт.
khim
Ну шуроповёрта может и не быть. А может оказаться, что и шуруп тут не нужен, а достаточно простого гвоздика. Но человек, который молча, не меняя выражения лица, берёт молоток и начинает им забивать шурупы — это совсем не тот человек, которого я хотел бы видеть у себя в команде. Об этом, собственно, весь разговор.
Borz
а потом такие, «с шуруповёртами» в мебель шурупами вкручивают подпятники, вместо того, чтобы гвоздиком прибить, т.к. молотка при себе нет. И не важно, что ножку раскорячивает от этого малость — зато шуруповёртом р-раз и готово
webkumo
Быстрее? Ну если молоток потяжелее — оно всяко быстрее шуруповёрта… Проверял. ;)
Только это не очернь корректное сравнение — программирование предоставляет куда большую возможность/вариативность действий.
khim
Именно потому что программирование предоставляет куда большую вариативность действий подобные вещи и важно проверять. Если у вас кто-то начнёт шурупы забивать молотком — его соседи это заметят (хотя бы по странному шуму) и могут на это как-то повлиять, а если у вас кто-то N! памяти потребляет, то этого можно сходу на тестовых данных и не заметить, а чинить потом может быть весьма непросто.
webkumo
По секрету: иногда бывает надо забить шуруп. Пример (несколько утрированный, но у меня что-то подобное случалось): на даче — не оказалось гвоздей, отвёрток, шуруповёртов, а вот саморезы и доски и чурбаны есть: что лучше, сидеть на земле, или таки забить саморезы, сделав скамейки?
khim
Про это все как бы знают, но это совершенно не делает аналогию хуже: в программировании тоже бывают случаи, когда лучше-таки отсортировать. Но в обоих случаях нужна веская причина. Если человек грамотно аргументирует свои «странные» действия — то честь ему и хвала, но ведь ясно, что в большинстве случаев речь идёт не об этом…
forketyfork Автор
Безусловно. Любая нормальная задача на собеседовании — это не какой-то однозначный вопрос, требующий правильного ответа, а приглашение к диалогу, в ходе которого человек может очень много всего рассказать, в том числе и по поводу того, в каких именно случаях правильнее забивать шурупы молотком. И чем больше человек скажет на эту тему умных мыслей, различных юзкейсов, случаев из практики, тем больше у него шанс произвести хорошее впечатление.
kloppspb
Вы таки будете смеяться, но я спрошу (сейчас): вы действительно хотите, чтобы именно этот шуруп я забил именно этим молотком?
Это, конечно, если стресс от самого факта собеседования не забьёт мозги. А это бывало, и не раз, даже когда уже вполне уверенным в себе специалистом приходил, пусть средней руки, но…
webkumo
Знаете, а я, скорее всего, тоже попадусь на эту уловку… а с учётом того, что собеседование для меня всё-таки стрессовая ситуация, то и на уточняющий вопрос не факт, что смогу ответить, особенно сразу:
Вы ещё в постановке задачи сами же сбиваете с толку кидая в кучу «дайте человеку todo-список и функцию сортировки и попросите найти самую раннюю по дате задачу». Вы в одном месте упоминаете задачу и инструмент, который может эту задачу решить (то что не оптимально — дело уже совсем другого порядка).
DaylightIsBurning
Это никак не связанно с пониманием алгоритмов, а просто эффект когда образование провоцирует на сложные шаблонные решения там, где лучше применить более простые. Наверное у этого эффекта есть какое-то звучное название, часто встречается.
Справедливости ради, сложность будет O(ln(n))+O(n)=O(n). Линеарифмическая — это, я так понимаю O(ln(n)*n) — никак не получится.
forketyfork Автор
Не очень понимаю, откуда ваша формула. Если вы сначала сортируете массив, а потом берёте первый элемент, то на сортировку у вас уходит (в типовой реализации сортировки в стандартных библиотеках) как раз O(ln(n)*n), а потом константное время чтобы взять первый или последний элемент по индексу.
DaylightIsBurning
Вы правы, я неверно прочитал сообщение, читая по диагонали.
f0rk
Я тоже долго врубался в эту фразу :) Я так понимаю, forketyfork хотел сказать, что мало кто догадывается, что сортировка не нужна.
forketyfork Автор
Да. Причём это выстраданная задача. Я часто видел подобный поиск граничного значения в реальном коде. Думаю, это SQL всех испортил.
khim
А тут ещё и не факт, что она не нужна. Тут ведь какая засада: «логарифма не существует». В практической жизни у вас ln(N) в задаче сортировки явно не превысит сотню (а в ToDo списке вряд ли превысит и десяток). А разница между интерпретируемым кодом и компилируемым может достигать трёх порядков. И на старом JavaScript-движке сортировка будет быстрее. Тут уточняющий вопрос нужен. Что-нибудь типа «а если у нас дата хитрым образом записана?». Тогда использовать чисто встроенную сортировку нельзя, нужно вспомогательную функцию передавать — и вот тут-то уже лучше по массиву пробежаться.
forketyfork Автор
Если бы мне такую аргументацию привели, это было бы человеку только в плюс. К сожалению, зачастую соискатель вообще не знает, что такое сложность и как её оценить.