Стоит ли жаловаться на собеседования?

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


    Первая тема — "мне слили карму, систему кармы надо изменить/отменить".
    Вторая тема — "меня не взяли на работу, процесс приема надо изменить".


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


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


    Как относиться к результату собеседования?


    Вообще из двух параметров "результат собеседования" и "качество собеседования с точки зрения кандидата" в простейшей бинарной модели можно составить четыре комбинации. Рассмотрим их:


    • Кандидат считает собеседование качественным и получил оффер — ну тут стоит только порадоваться. Все звёзды на небе сошлись.
    • Кандидат считает собеседование качественным и не получил оффер — раз уж кандидат сам считает собеседование хорошим, то должен признать, что он объективно не подходит компании. Стоит поработать на собой, чтобы в следующий раз было лучше.
    • Кандидат считает собеседование некачественным и не получил оффер — тут надо вздохнуть с облегчением. Если уж по мнению кандидата приемом на работу занимаются идиоты, то принятые ими сотрудники не могут быть хорошими — слава богу, что не придется с ними работать.
    • Кандидат считает собеседование некачественным и получил оффер — а вот это очень плохой случай. Кандидату стоит сильно задуматься — как же так получилось, что он понравился идиотам.

    Как видим, ни в одном из случаев обижаться на интервью и собеседников там нет смысла. В первом и третьем случае всё прошло так, как надо — можно похвастаться на Хабре. Во втором и в четвертом случаях стоит покопаться в себе. Можно написать на Хабр самообличительную статью.


    Почему так много некачественных интервью?


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


    Вторая причина тоже кроется в неправильном понимании кандидатом процесса интервью. Кандидат зачастую ошибается думая, что интервьюера интересуют правильные ответы на вопросы. Очень часто вопросы задаются не для того, чтобы услышать ответ, а для того, чтобы понять как человек будет действовать. Будет он задавать дополнительные вопросы, уточняющие постановку или сразу бросится писать код. Отметит ли он некорректность (или абсурдность задачи) или будет пытаться найти несуществующее решение. Приведёт ли он примеры из своей практики или процитирует фразу из документации. Все эти маркеры намного информативнее, чем собственно ответ на вопрос. И само содержание вопроса очень часто второстепенно.
    Вполне может оказаться, что человек, который дал формально неправильный ответ на достаточно тривиальный вопрос более подходит интервьюеру, чем человек с "безупречным" ответом. Несомненно, есть и действительно прямые вопросы, требующие прямого ответа, но какие из вопросов интервью были именно такими — кандидат не знает. Причем и сам интервьюер обычно четко этого не осознает. Он просто видит после интервью, что вот этот кандидат размышлял "здраво", хоть и дал неправильный ответ. А другой — совершенно не понравился, хотя ответы вроде были верными. Решение во многом эмоционально и мало кто пытается его формализовать.


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


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


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


    Нужны ли качественные интервью?


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


    Итак для начала надо найти крутого рекрутера, который умеет организовать процесс и платить ему зарплату. Затем надо провести обучение — как проводить интервью. И потратить время обучаемых на это. Причем обучать надо не абы кого, а людей с соответствующими скиллами (то есть коммуникативных и хорошо подготовленных технически). Что делать, если таких людей в компании просто нет (вполне нормальная ситуация для стартапа из пяти человек) — неясно.
    Теперь собственно интервью. С каждым кандидатом должны побеседовать 3-4 (в некоторых компаниях 5) человек. Прикидывая по часу на интервью (и ещё час на подготовку к нему и отзыв) получаем, что каждый кандидат обходится в пару человеко-дней работы высококлассных специалистов. Для поиска одного сотрудника компании просматривают 5-20 кандидатов. Итого выходит в среднем один человеко-месяц работы высококлассных спецов для приема одного рядового сотрудника. Сколько времени должен этот сотрудник отработать, чтобы покрыть такие расходы?


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


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


    Правда надо сказать, что некоторые компании действительно вкладываются в процесс приема по-полной. Так “любимые” многими интервью в Google и Facebook это результат именно такого подхода. Обычно программист проходит 6 технических интервью (1 телефонное и 5 очных) и после прохождения всех этих интервью львиная доля кандидатов остаётся за бортом. Google может себе позволить такие расходы и осознаёт, что окупаемость сотрудников наступает не ранее чем через год. А может ли их позволить себе интересный технологический стартап? Многие ли стартапы имеют горизонт планирования более чем на год? Успеет ли сотрудник в стартапе окупиться прежде, чем стартап вылетит в трубу? Кстати, стоит сказать, что гугловые интервью здесь ругают также как и все остальные. :)


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


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

    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 87

      +3
      Ну а главным показателем качества рекрутинга является успешность компании —… это значит, что сотрудников он набирают правильно.
      компания может быть успешной и по инерции, например. или маркетологов они набирают правильно, а разработчиков — как получится. или ещё какая-либо причина.

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

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

          И самое главное в такие компании лучше не идти работать. А если уже там, то пора смотреть по сторонам.

        +2
        Какими-то способами собеседование проводить всё равно нужно.

        Пусть это и не идеальные способа, но брать первого, кто пришёл, без всякого собеседования — тоже не вариант.
          0
          Ну да, каким-то способом и проводят.
          +1

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


          Давайте посмотрим на корень зла. Почему адекватный разработчик может иметь проблемы при найме на работу:


          1. Общая предвзятость и стереотипы например к женщинам, старикам, таджикам, замкадешным, больным и инвалидам
          2. Нежелание тимлидов брать себе конкурентов (сейчас надеюсь подтянутся тимлидиы которые начнут рвать на себе тельняшку и говорить что они отвечают за проект и весь проект на них и они заинтересованы в квалифицированных кандидатах) как правило наиболее циничные так прямо и говорят: мне нужно на проект три мартыхи.
          3. Отсутствие реальных дополнительтных рабочих мест. Вопрос а зачем же выставлять вакансию? Причин может быть много: для рекртутеров это просто работа. Иначе могут навесить обязанности HR или офис-менеджера. Для фирмы — дополнительный показатель стабильности перед инвесторами и заказчиками. Ищут работников — значит развиваются, не принимают всех подряд- значит высокий уровень. Ну а если кто-то просто "понравится" то могут и взять.
            Ну а для разрабтотчиков которые уже на борту это как бы возможность оторваться от весла и затрекать время на собеседование а по сути немного переключиться на другой вид работы.

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

            0
            Ну вот я провожу собеседования. На них приходят адекватные разработчики, но не получают оффера потому-что уровень знаний и навыков кажется недостаточным. При этом количество программистов в компании растёт процентов на 10 каждый год. То есть принимают довольно много. Это я не говорю про случаи, когда человек себя считает адекватным, но не является таковым с точки зрения нанимающей стороны.
              +3

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

                0
                Но отвечает за ошибку всегда та сторона которая приходит на собеседование
                Почему же? Если нанимающая сторона ошибается и принимает плохого разработчика, то это обходится ей довольно дорого. Гораздо дешевле ошибаться в другую сторону.
                  +1

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

                    0

                    Опять вернулся к этому Вашему комменту, т.к. не дает он мне никак покоя.
                    Ведь все не так, совсем не так.
                    1) Вы неявно пытаетесь склонить сбеседников к такой вот дихотомии


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

                    2) Вы ошибочно полагаете что прием плохого разработчика обходится для бизнеса дороже чем не прием хорошего. Мол де в первом случае на него будет потрачены деньги на время испытательного срока и время хороших разработчиков. В то же время якобы не прием хорошего разработчика это бесплатно. Так вот, это совсем не так. Начнем с того что как бы хорошо ни была система отбора может произойти два события :


                    • кандидат все же не готов к работе и это не было определено на собесе
                    • кандидат устраивает фирму но он сам по своей инициативе вскоре уходит.
                      Так что выхлоп средств так или иначе неизбежен.
                      То что Вы не приняли хорошего разработчика — это вот как раз очень большая потеря. Т.к. именно хорошие а не среднепроходные разработчики могут способствовать росту бизнеса. То есть это да, упущенная выгода и измерить ее невозможно.
                      0
                      Вы не уловили главной мысли моего комментария. Мысль следующая — для компании (особенно успешной и привлекательной для потенциальных сотрудников) выгоднее организовать процесс приема так, чтобы планка была заведомо выше, чем это требуется для реальной работы. Завышение планки позволяет допускать меньше ошибочно принятых кандидатов за счет увеличения числа ошибочно непринятых. Несомненно, идеальных процессов не бывает, и реализация идеи зависит от конкретных исполнителей.

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

                      2.
                      -кандидат все же не готов к работе и это не было определено на собесе
                      -кандидат устраивает фирму но он сам по своей инициативе вскоре уходит.
                      Оба этих случая я бы отнёс к категории приём плохого разработчика. Хороший разработчик для компании это не «абстрактиный хороший разработчик в вакууме», а разработчик, который принесёт конкретной компании конкретную пользу. Если компания приняла сотрудника, который никакой пользы принести не смог (вне зависимости от причин), то компания приняла плохого сотрудника. И задача собеседования — постараться такого не допустить. Всякие ненавидимые кандидатами дурацкие психологические вопросы часть этого. «Непрофильные вопросы» — тоже. Если человек не готов отвечать на вопросы, котьорые чуть-чуть выходят за рамки его потенциальных обязанностей, то это значит, что он не сможет работать, если ситуация чуть-чуть изменится.
              +1
              Скажите почему рекрутеры не читают резюме перед собеседованием, регулярно сталкиваюсь с этим явлением. Аргумент об экономии времени на чтении резюме не принимается, так как время на само собеседование все же находят. В чем причина?
                –2
                Они вам сами говорили, что не читают? Или вы сделали такой вывод из того, что их предложение в чём-то не соответствовало вашим ожиданиям?
                Я не рекрутёр, но собеседования провожу. Перед собеседованием резюме обычно просматриваю, но не очень детально. Скорее сканирую, надеясь найти что-то знакомое, о чём можно будет поговорить. При этом вполне могу пропустить что-то, что кандидат считает очень важным. Бывает так, что закручусь и напоминание о собеседовании прилетает из календаря за 10 минут до начала. В этом случае на чтение резюме времени уже не остается.
                Вообще формат резюме у всех настолько разный, что найти и обратить внимание на какую-то информацию там зачастую не просто.
                  +4
                  Делаю такой вывод так как обычно начинают читать резюме при мне)) с удивлением обнаруживая какие-то детали которые судя по всему не ожидали там увидеть. Да и вообще видно читает ли собеседующий резюме первый раз или уточняет какие-то детали.
                  Судя по вашим словам, действительно не читают))
                    +3
                    Делаю такой вывод так как обычно начинают читать резюме при мне)) с удивлением обнаруживая какие-то детали которые судя по всему не ожидали там увидеть.


                    Вы не один. Прочитали ранее ваше резюме. Но забыли. На собеседовании — перечитали, чтобы вспомнить.

                    Вы далеко не один. Типично на собеседовании: нескольков десятков человек на место. Резюме всех — в голове не удержишь.
                      +5
                      С моей точки зрения это неуважение к кандидату. Когда кандидат идет на собеседование от него ждут, что он ознакомится с деятельностью компании. Некоторые даже задают вопросы кем вы видите себя в компании через 5 лет))) (особенно умиляет когда так делают в стартапах). Почему же кандидат, не вправе надеяться, что его резюме хотя бы прочитают??? Очное собеседование это достаточно временно-затратный процесс, причем для всех.
                      Уважаемые собеседующие, читайте пожалуйста резюме, если есть вопросы просто позвоните и спросите, пятиминутный звонок легко экономит 2-3 часа.
                        –4
                        К сожалению, бОльшая часть текста в резюме малоинформативна для собеседующего. Прочитать можно, но из-за отсутствия информации мало что в голове удерживается. Но и сказать, что стоило бы выкинуть из резюме, — сложно, потому что у каждого собеседующего свои информационные фильтры.
                          +2
                          к тому же в резюме зачастую присутствует ощутимый процент вранья/преувеличения заслуг/умолчания
                          +1

                          Кто ждёт, что кандидат с деятельностью компании ознакомится больше чем в вакансии написано?

                            0
                            Когда кандидат идет на собеседование от него ждут, что он ознакомится с деятельностью компании

                            Кто ждёт, что кандидат с деятельностью компании ознакомится больше чем в вакансии написано?


                            И из каких источников до собеседования он узнает что там внутри?
                      +1

                      Большинство либо не читают, либо делают вид что не читают. Как иначе объяснить вопрос «вы работали с javascript?» или «какие css препроцессоры вы знаете?» когда у меня в резюме черным по белому написаны и препроцессоры и опыт с javascript в отдельном абзаце «навыки».

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

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

                            0
                            К сожалению, то что написано, часто мало что значит, т.к. кандидат уже этого не помнит. И тут, как раз, такой вопрос уже кстати. Правда, соглашусь, что спрашивать работали или нет, когда написано, что работал неуважительно.
                          +3

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


                          Те, кто проводит тех собеседование, в принципе заинтересованы отсеивать по резюме, но тут срабатывает два фактора.


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


                          Второй — с опытом приходит недоверие к написанному, даже если там стоят явно какие-то условия. Потом выясняется, что "нет" не такое уж и "нет", или устарело, или для всех "нет", но для вас… Это реальность, и если я вижу хорошего кандидата, который, например, не хочет работать с нашим стеком — я все же отдам его рекрутерам на установку первого контакта, ибо см. выше. И это работает.


                          Или, например, "зачем вы меня, С++ программиста, зовете на вакансию PHP"… звучит логично, но только если не знать, сколько я видел таких программистов, решивших сменить стек, потому что им предложили.

                            +5
                            В этом и собственно проблема, рекрутеру нужен вал кандидатов, как следствие — встречает знакомое слово — передает на тех интервью. А тех интервьюер похоже считает, что если человека направили ему, то уже отсев произведен и можно работать дальше. В итоге выясняется, что либо стек не тот, либо мои условия неприемлемы, либо от меня ожидают больше того, что я могу выдать немедленно. Хоть аналог код-ревью для проверки резюме рекрутерами ввели, что то вроде резюме-ревью)))
                              0

                              Рекрутерам прямо поток не нужен. Если 90% отсекается на техинтервью почти с самого начала, то к рекрутерам будут претензии

                              0

                              Имхо, все максимально просто:


                              Рекрутера уволят за то, что он не провел собеседование? Естественно.
                              Рекрутера уволят за то, что он не прочитал что-то так? Да нет, он работает, он ничего.


                              Зачем читать, когда можно пожрать в столовке и поболтать с коллегой?

                              +3
                              Проблема найма в IT заключается в том, прежде всего, что не существует универсальных формальных критериев для определения качества специалиста, но при этом, цена ошибки достаточно высока. Поэтому, работодатели, от страха, занимаются фигней, типа «на позицию бегуна нам нужен кандидат с сильными ногами, поэтому мы вас попросим присесть со штангой сто раз», а соискатели жалуются на то, что их не просят просто «показать результаты прошлых забегов» и «пробежать стометровку на время, по асфальту, без лыж», а заставляют играть в дурацкие игры, не имеющие отношения к реальной работе. Хорошие собеседования проводит тот, кто ищет своего будущего коллегу, человека, с которым придется работать плотно в команде. Такие люди знают чего хотят и могут задавать правильные вопросы в нужном контексте. В статье написана ерунда, ибо если всерьез говорить о том, что по представлениям работодателя ему нужен именно тот, кто хорошо пишет код на бумажке, в противогазе, со связанными за спиной руками, то такой работодатель — идиот.
                                0
                                Проблема не втом, что нет универсальных критериев качества, а втом, что универсальные критерии качества не достаточны. Если я покупаю обои, то я смотрю на некоторые универсальные критерии качества (типа прочности, матриала и т.п.), но при этом выберу разные обои для спальни и для столовой. И тут дело не в качестве.
                                Так и с программистами — есть некоторые критерии качества, которые легко проверить, но гораздо важнее не качество, а разные психологические характеристики, которые никакой линейной шкалы измерений не имеют.
                                  0
                                  То есть, «психологические характеристики» вы вынесли из категории «качества»? С какой стати вообще?
                                    0
                                    Потому что «качество» — это относительно упорядоченная величина, допускающая сравнение (качество выше/качество ниже). А психологические характеристики не сравнимы. Нельзя сказать, что интроверт, например, хуже экстраверта.
                                      0
                                      А психологические характеристики не сравнимы.

                                      Во первых, сравнивать можно любые психологические характеристики, если критерии сравнения задает контекст. Это элементарно, например: ищете тимлида — интроверт не подойдет. Во вторых, ох…
                                        0

                                        Вы считаете, что на тимлида интроверт не подойдёт, а я тут не согласен. Для менеджера по продажам такое, наверное, верно.
                                        Но не суть. Я хотел отметить то, что для большинства важных характеристик "универсальных критериев" не просто не существует, а их не может существовать. То есть проблема не в том, что кто-то недостаточно организовал процесс и не вычислил критерии, а в том, что такое вычисление в привычном понимании невозможно.
                                        Хотя вот обучат скоро машинный интеллект прием сотрудников проводить. Как он будет решения принимать никто не объяснит, но зато будет универсально :)

                                          +2
                                          Если вы перечитаете мой первый коммент, то увидите, что я пишу то-же самое.
                                          +5

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

                                            0

                                            Может. Но в данном контексте это не важно, главное, что сравнивать можно.

                                  +3
                                  Проблема всех этих собеседований — ты каждый раз должен доказывать свои знания. Что больше половины плевать на твой гитхаб и размещенные там задания (даже если некоторые их них не так давно появились). Им интересны только свои задачи. Что каждый раз при поиске работы ты должен садиться и повторять заново всю теорию как будто снова готовишься к экзамену. Ведь когда например, хирурги приходят на работу им не говорят — сделай мне операцию, а я посмотрю и определю подходишь ты нам или нет.
                                  Что хочется — введения какой-то общей квалификации. Наподобие как у врачей или педагогов. И тогда напрягаться придется раз — при получении этой квалификации.
                                    0
                                    Во-первых, как я и написал в статье интервью — это не проверка знаний. Вопросы задают не для того, чтобы услышать на них правильный ответ. Те соискатели, которые этого не понимают, испытывают трудности при поиске работы.
                                    Во-вторых, общая квалификация существует. Есть разные там сертификаты. Но, к сожалению эта общая квалификация мало что значит. Потому-что компании нужен не человек, который знает определённый набор вещей, а человек который сможет эффективно работать. Эффективность работы только частично зависит от конкретных знаний.
                                    +2
                                    Одним из важных критериев качества собеседования считаю наличие или отсутствие обратной связи по итогам. Любой соискатель достоин знать, почему он не подошел на позицию
                                      +2
                                      Да, обратная связь очень важна, хотя ее обычно не дают. Правда, иногда и отзыв обескураживает и думаешь, что лучше б не знал, если б по существу, а то просто испорченное настроение.
                                      +1

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


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


                                      Когда нам присылают решение (принимается репозиторий на GH / BB), его вскользь просматривает один из четырех ведущих специалистов. Если оценка ниже, чем ожидается (эта цифра варьируется в зависимости от того, насколько нам нужен человек вотпрямщас) — мы вежливо отвечаем, что, мол, извините. Пояснений к отказу не даем, потому что субъективная оценка одного, пусть и крутого, чувака — это не то, что хочется прямо выплеснуть в лицо соисканту, который старался, но не дотянул. Потеряли половину человекочаса, ну так и ничего страшного.


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


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


                                      И обычно люди наше предложение принимают, даже если им придется переехать к нам из Аргентины (2 примера), Болгарии (1 пример), Кубы, Франции и т. п.


                                      Такие вот дела. В общем, я абсолютно убежден, что домашнее тестовое задание — решает вопрос успешности собеседования на 80%.

                                        +2

                                        Вот уж в самом деле, неоплачиваемые тестовые задания, которые требуют больше получаса времени — "сразу нахрен"

                                          +2
                                          Вот уж в самом деле, неоплачиваемые тестовые задания, которые требуют больше получаса времени — «сразу нахрен»


                                          Вопросы только в том:

                                          1) Есть ли у вас достаточно количество предложений без таковых заданий?
                                          2) Достаточно ли высокий уровень оплаты на этих предложених без таковых заданий?

                                          Если ответ на оба вопроса «да», то тестовые задания можно посылать далеко и сразу.

                                          Но, что-то мне подсказывает, что ответ на оба вопроса «да» только у меньшинства наших коллег.
                                            +3

                                            Ну и мы, разумеется, охотно рассмотрим профиль нс гитхабе — вместо тааого задания.

                                              +2
                                              В своё время наелась этими тестовыми заданиями надолго. Потратила целый месяц по 12-14 часов почти без выходных на их выполнение. Но это было при отсутствии заданий на гитхабе.
                                              Сейчас прежде чем мне дают задание вначале стараюсь их туда послать (я про гитхаб веду речь). Но не все соглашаются. Многим на это плевать. Их только своя задача интересует.

                                              И вот решаю я задачу (кстати, наподобие до этого месяц назад делала, но та задача им не подошла). Да, она у меня занимает не час, а 2-3 часа. Т.к. она идет на создание архитектуры проекта. Время на подумать как лучше тоже тратиться. И тут выясняется, что в команде тимлид и один разработчик. И вот тут мне не понятны такие требования. Считаю, что они слишком завышены.
                                              +3

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

                                                0

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

                                                  +1
                                                  А вот расскажите, если я сеньор, работаю, с кучей предложений, почему у меня обязательно должено быть что-то на гитхабе? Элементарно у меня нет времени на ерунду, а что-то стоящее у заказчиков в репозиториях.
                                                    +2
                                                    А вот расскажите, если я сеньор, работаю, с кучей предложений, почему у меня обязательно должено быть что-то на гитхабе?


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

                                                    И, следовательно, не можете не знать какое огромное количество шлака идет на собеседования.

                                                    Сеньором вы станете в глазах нанимателя не ранее, как каким-либо способом сможете предъявить как-то, что вы сеньор. Вашим кодом, верительными грамотами, рекомендацией тех, кому доверяет работодатель… Верить вам просто потому что вы говорите, что вы крут — не разумно.

                                                    Пример из жизни:

                                                    Вакансия примерно такая, деталей не помню, но суть: «Администрирование Linux, командная строка, удаленные подключения». Оклад — чуть выше среднего по региону.

                                                    Идут на эту вакансию люди «я умею ставить Windows, слышал про какую-то Ubuntu, но она же похожа на Windows; ой, что такое маска сети и шлюз IP, нет не знаю» и т.п.

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

                                                    Не обязательно доказывать своей репой на ГитХабе. Но хоть чем-то — да надо доказать.
                                                      +3

                                                      А зачем мне что-то вам доказывать?


                                                      Если все так радужно, как вы рассказыаете, и вас все устраивает, — вы найдете миллион достойных работ и без нас. Но если вы почему-то захотите работать именно у нас, даже тут никто не станет воротить нос и все отнесутся с пониманием: вам придется всего лишь написать тест. Если вы и правда señor — займет он от силы часов шесть.


                                                      А если вы продолжаете считать, что тест — это унизительно, — тоже прекрасно, просто вы будете работать где-нибудь в другом месте. Win-win.

                                                        +3
                                                        Меня интересовало конкретное утверждение:
                                                        А вот если кто претендует на синьора и почему-то гитхаб у него пуст — явный повод не тратить время на собеседование до того, как взглянуть на код.

                                                        Я знаком с огромным количеством высококлассных специалистов, у которых на гите в открытом доступе ничего нет и это не повод усомниться в их компетенции.
                                                        В одной из компаний у меня попросили, просто, прислать пример моего кода. У них, кстати была, на мой взгляд, лучшая система найма, как для соискателей, так и для сотрудников.
                                                        Блиц опрос по языку программирования «да»-«нет» и на вменяемость психологом. Высылаете пример саоего кода.
                                                        Если проходите, опрос на категорию джун-милд-сеньор с техническим специалистом, опять же по телефону.
                                                        Если прошли, тогда уже личное собеседование о найме.
                                                        Конечно, главное, что у них в HR дипломированные психологи профессионалы, не просто «девочки». Причем их было человек 3-5 на 200 человек штата. Поэтому анкеты, вместо часов потраченных на отсеивание шлака и только собеседование уже на конкретную позицию.
                                                        И не нужны были тесты, т.к. все равно в каждой команде и компании свои стандарты, а от соискателя нужно только понимание и готовность их выполнять. А качество вливание в коллектив, все равно, лучше испытательного срока ничто не покажет.
                                                          +3
                                                          Я знаком с огромным количеством высококлассных специалистов, у которых на гите в открытом доступе ничего нет и это не повод усомниться в их компетенции.

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


                                                          в HR дипломированные психологи профессионалы

                                                          Люди будут работать в конечном итоге с нами, а не с дипломированными HR'-специалистами, так что нет. Неоднократно случалось, что HR (да, у нас они тоже дипломированные) — браковали кандидата, которого я лично потом отстаивал перд CEO, и — мы по нескольку лет работаем вместе, нарадоваться не можем.

                                                            +2
                                                            Неоднократно случалось, что HR (да, у нас они тоже дипломированные) — браковали кандидата, которого я лично потом отстаивал перед CEO

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


                                                            За отстаивание специалистов — респект.

                                                              +3

                                                              Я не только в OSS коммичу, мне еще приходится немного тут код для нужд бизнеса писать (правда, 60% мне удается отстоять и выложить в OSS :)


                                                              «Отстаивать» — это сильно сказано. Я изобрел формулировку: «когда мой голос будет рещающим при отборе в Sales, я буду полагаться на HR в вопросах комплектования Tech», и она пока работает.


                                                              нежелание тимлида иметь себе же конкурента в лице нанимаемого [из другой ветки]

                                                              За это тимлида надо выгнать и ославить на всех столбах. Я лично буду счастлив, если удастся сгрузить половину сложных рутинных задач и заняться тем, что у меня в должности написано (principal engineer — то есть, пишу код в уголочке без ТЗ, который, может быть, пригодится через год).

                                                          +4
                                                          Если вы и правда señor — займет он от силы часов шесть.

                                                          Если Вы Гугл, то к вам наверное стадами тянутся сеньоры. Но если нет, то не так много желающих согласиться делать такое задание.

                                                          Вы в курсе, что вы не одни такие? Что у сеньора еще вас таких минимум штук 10. И вы думаете, что он всем будет по 6 часов (а скорее всего не меньше 10 часов) сидеть и делать задания? Тем более вы еще пишите, что если вас оно не устраивает, то нет обратной связи. Это просто супер — сидеть 6-10 часов работать, а в ответ тишина.

                                                          Именно об этом и идет речь. Когда ТЗ рассчитано на 1-2 часа это адекватное время. На него можно потрать свое свободное после работы время.
                                                            +1

                                                            Мы не Гугл, но к нам тянутся.


                                                            у сеньора еще вас таких минимум штук 10.

                                                            Ну, в нашем стеке — в стране, где я работаю — больше нет компаний, в которых ведущий специалист — language core committer и более-менее известный в коммьюнити человек. Мы открываем много кода в OSS — для многих это тоже очень весомый плюс. А Гугл… ну, в 2020 в Гугл имеет смысл идти либо совсем зеленым джуном, либо Робом Пайком, зачем бы туда пойти крепкому профессионалу — я не могу взять в толк.


                                                            Когда ТЗ рассчитано на 1-2 часа это адекватное время.

                                                            Я считаю, что 10–12 часов, это адекватное время. Соискатели ищут работу, а не покупают сигареты — возможно (скорее всего) на годы. На этом фоне — инвестиция двенадцати часов не кажется такой ужж прямо невероятной тратой времени. Если вам так не кажется — ну что же, мы не подошли друг другу, не судьба, в этом нет ничего страшного.

                                                            +3
                                                            вам придется всего лишь написать тест. Если вы и правда señor — займет он от силы часов шесть
                                                            Не смог пройти мимо.

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

                                                            Быть может, это просто какая-то очень интересная компания, куда все толпами идут? Зашел в профиль, оттуда по ссылке — да нет, обычный форекс, ничего грандиозного.

                                                            Остался лишь один вопрос — вы ведь понимаете, что с таким подходом к вам идут далеко не сеньоры, даже если они говорят противоположное? Ну или я чего-то не понимаю в этом мире.
                                                              +2
                                                              вы ведь понимаете, что с таким подходом к вам идут далеко не сеньоры, даже если они говорят противоположное

                                                              Ну, вам-то оттуда лучше видно, конечно.


                                                              Соискатели ничего не говорят. Они показывают профиль GH, или пишут тест. У нас вообще нет формулировки «señor / middle / junior» в предложении. Вообще. Потому что то, что вы называете señor, я, скорее всего, назову average / middle. Например, в 2020 в моем мире не бывает сочетания слов «сеньор» и «фуллстек» в одном резюме. Либо одно, либо другое. Невозможно действительно уметь правильно разрулить миллионы зависимых конкурентных потоков (гринтредов) в кластере и, одновременно, левой рукой создавать сложные компоненты в эмбере.


                                                              Но недостатка в кадрах нет, стабильно раз в несколько месяцев мы находим профи (в последнее время — преимущественно в Латинской Америке).


                                                              Ну или я чего-то не понимаю в этом мире.

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

                                                                0
                                                                У нас вообще нет формулировки «señor / middle / junior» в предложении. Вообще.

                                                                Заглянул на сайт Кантокса. Увидел позиции
                                                                — R Developer/Data Scientist
                                                                — IT Support Engineer
                                                                — User Researcher Specialist (Fintech)
                                                                — Quality Engineer
                                                                — Ruby/Rails Software Engineer
                                                                — Senior Software Engineers (Ruby on Rails/Elixir)

                                                                Так что как минимум «Senior» там присутствует.
                                                                  +2

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


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

                                                                    0
                                                                    Да это я так, позанудствовал. Я тоже не считаю эти титулы имеющими реальный смысл. И меня вы всё-равно не возьмёте.
                                                                      +2
                                                                      меня вы всё-равно не возьмёте

                                                                      Этого я утверждать без взгляда на тест / код не берусь. Если это, конечно, не «Не дожидаясь отказа, свою кандидатуру я снимаю сам» :)

                                                                        0
                                                                        Ну глядя на
                                                                        Ненавижу MacOS, Google
                                                                        в вашем профиле, у меня с моим текущим местом работы — нет шансов. :)
                                                                          +2

                                                                          Мои личные предпочтения вообще никак не сказываются на процесс отбора кандидатов, по-моему, это очевидно :)


                                                                          У нас у всех разработчиков iMac27 и макбуки про (кроме меня), а corporate mail — так и вовсе гугловская.

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

                                                                      В подавляющем большинстве случаев по личному опыту, если нет титула, то работодатели имеют в виду middle/regular позиции

                                                                        +2

                                                                        Тут проблема в том, что я не очень понимаю это разделение в принципе. «middle/regular позиции» — это что значит?


                                                                        «Мало, что умею, вряд ли буду полезен, но есть 5 лет стажа»? Что-то другое? Что?


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

                                                                          0

                                                                          Более-менее общепринято, по-моему, что middle/regular не нуждается в присмотре, а senior могут успешно присматривать за junior.

                                                                            +2
                                                                            не нуждается в присмотре, а senior могут успешно присматривать за junior

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


                                                                            Яснее, в общем, не стало.

                                                                              0

                                                                              Вот хотел написать после слова "присмотр" в скобках "не путать с код-ревью", но поленился :)


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


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

                                                                                +1

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


                                                                                Что есть присмотр тогда? Советы? — любому нужны. Парное программирование? — любому нужно. Обмен опытом? «Ты этот таск не копай, ты вон тот копай»? Ежедневные отчеты? Что?


                                                                                Потому что — повторю — я убежден, что присмотр нужен в равной мере всем. Для ситуации, когда присмотр не нужен (включая чем он там занимается вообще) — придуманы должности «principal engineer» и «distinguished engineer».

                                                                                  0

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

                                                                                    +2

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

                                                                    +2
                                                                    Потому что то, что вы называете señor, я, скорее всего, назову average / middle.

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


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

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

                                                                      +2
                                                                      фронт и бек в одном лице

                                                                      Я об этом и говорю. Я от человека, который говорит, что умеет бэкенд — жду адекватного решения задачи «вот этот эндпоинт теперь должен проверять введенное пользователем значение относительно данных, обновляемых со скоростью 10K/sec из постороннего источника».


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


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


                                                                      Или вот еще хороший вопрос, например: как сделать апдейт системы без разрыва долгоживущих соединений. hot code upload — сам по себе не особенно прост (нет, просто ждать, пока старые соединения отвалятся — не вариант, после апдейта все вебсокеты должны использовать свежий код, но рвать соединение нельзя).

                                                                        0
                                                                        Я от человека, который говорит, что умеет бэкенд — жду адекватного решения задачи «вот этот эндпоинт теперь должен проверять введенное пользователем значение относительно данных, обновляемых со скоростью 10K/sec из постороннего источника».

                                                                        Вы сейчас свою специфику натянули на всех бекендов. Не надо так. Не все пишут высокочастотных роботов, или что вы там делаете.


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


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

                                                                          +1
                                                                          свою специфику натянули на всех бекендов

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


                                                                          если справится база, справится и приложение

                                                                          А вот это и вовсе неверно. База очень быстро становится узким местом на больших объемах, даже если вопрос просто в обслуживании банального голосования. change.org на какой-то из последних конференций рассказывал, как они боролись с всплеском голосов на чем-то активном #прямосейчас — и там никакая база не потянет эти самые 10K прилетающих в секунду голосов (без помощи приложения). Да даже если и потянет, не нужно бездумно нагружать базу в этом случае.

                                                      +3

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

                                                        +4

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


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

                                                          0
                                                          Тестовое задание по сравнение с написанием кода на интервью плохо тем, что отсутствует обратная связь. На интервью всегда можно задать вопрос и уточнить постановку задачи, а при тестовом задании приходится угадывать. И проблемой будет не плохой код, а то, что задание соискателем и компанией понимается по-разному.
                                                            +1

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


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

                                                              0
                                                              Тестовое задание по сравнение с написанием кода на интервью плохо тем, что отсутствует обратная связь.

                                                              Совершенно неверно. Не знаю как по вашему опыту, а я всегда задаю уточняющие вопросы перед тем как делать задание, если они у меня есть. И мне всегда дают пояснения, уточнения и т.д.
                                                          +2

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


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

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


                                                              Конечно, там же все святые и какают только радугой.
                                                              А все говно только здесь?

                                                              На Хабре были даже переводы.

                                                              Например, переведенная статья-жалоба про собеседования с доской, на которой нужно сразу написать решение. Может, кто из завсегдатаев название вспомнит.
                                                                0
                                                                да.

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

                                                              Самое читаемое