Pull to refresh

Comments 111

2 дизайнера — это вся выборка, что у вас есть? Ошибки при наборе людей были? Возникали ли сложности какие-либо?
за свою жизнь я набрал более 100(ста) сотрудников — php программисты, а дизайнеры это для меня ново и необычно, поэтому их и выложил.

Что является ошибкой при выборе? Наняли и уволили на испытательный срок — очень редко, так как обычно IT собеседование это только часть процесса и совсем не адекватные люди отсеиваются разными специалистами :)

Сложности… наверное тут стоит сказать о том, что часть импровизации в первых собеседованиях слишком затягивается, когда сам понимаешь, кто же все таки нужен и что мы можем дать этому соискателю, но на 2-4 собеседование уже идет довольно четко и лаконично
Моя профессия — QA Engineer. Я был на многих собеседованиях и могу поведать о тестовых заданиях.
Их 3 типа: «домашнее», «на месте» и «креативное».
Домашние это задания, обычно программы, которые HR высылают по почте. Самая распространенная — listboxer и её модификации. программы отсеивают невнимательных и неопытных людей.
На месте — то же самое, но на месте и на время (около часа).
Креативное — вам на месте предложат протестировать что-либо из того, что вы видите (карандаш, стул, стол, шапку и т.д.)
Вы требуете от кандидатов только список дефектов listboxer или еще, например, кейсы? Вам не кажется, что listboxer отсеивает еще и подходящих людей? По своему опыту скажу, что гораздо приятней выполнять тестовое задание на специальном приложении. Или даже на боевом.
Не я требую — от меня требуют.
очень странный блик горшка, на картинке с номерным знаком 127. Я так понимаю он должен быть с другой стороны или тень с другой стороны. Я не дизайнер если что.
Это я выложил еще более менее адекватные работы. Я тоже не дизайнер и для меня этот экспириенс был очень полезным.
Я посетил порядка 40 собеседований на должность программиста. Можно их разделить на два вида — где просили решить тестовую задачу и где спрашивали тонкости технологий, написанных в моем резюме.

Мое мнение однозначно — наличие практического тестового задания (на 30-60 минут), это верный признак адекватно конторы. А вот задачи вида, «что вернет код» и пара строчек, за которые надо оторвать руки — наоборот.
Спасибо за статью

>Если у вас возникли сложности с составлением вакансии, обратитесь к HR-менеджеру
Можно примеры? У меня как раз наоборот, что в моих грейдах HR ищут не там и не совсем то. Ведь не всегда написанные ключевые слова являются главным критерием. Например в плане поиска тестировщиков лучше ориентироваться не столько на программистов и знания языков, сколько на умение разбираться в чужом коде, архитектуре и знать уязвимые места алгоритмов, писать сценарии. Если мне неизвестно, что же надо найти, я тоже прежде чем свалить всё на HR скажу, что я жду и зачем. По полученной вакансии\выборке кандидатов так же отвечу, как можно подкорректировать вакансию.

>Можно дать какие-то простенькие задачи, типа напишите функцию на php с помощью рекурсии, для вычисления N! (факториала).
Поддерживаю, плюс работа с указателями, областью видимости классов весьма показательна.

А как же «задачи на размышления»? Способность увлечься задачей и предлагать разные решения? Чтобы выявить возможность человека не только заниматься, что он умеет, а искать новые решения в новых сферах? Конечно не только вопросы из разряда «почему люк круглый», но вопросы «как бы вы поступили? как можно улучшить? какие ошибки?».
по HR, если он ищет совсем не-то и вы руководитель отдела ищете человека себе в штат
Значит, здесь нужно действовать проактивно. Сами делайте подборку людей или договоритесь по каким критериям сразу отсеивать, а остальных брать. Т.е. HR должен понять, кто на 100% не подходит, остальных нужно впускать в воронку собеседований.

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

И дальше уже по алгоритму.

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

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

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

Да, это очень странно, но людям нужно убеждать, что это хорошая работа и ему здесь будет хорошо :)
Спасибо за развёрнутый ответ.
Кстати, люки бывают и квадратные и прямоугольные…
и треугольные тоже image
но круглые всё-таки чаще.
Мне уже дофига надоело эти ваши «умные» идиотские собеседования.

Я бы на собеседовании показал несколько картинок известных людей. Скажем если это собеседование по .NET то картинки Кнута, Джеффри Рихтера, Марка Руссиновича и т.д, и тогда будет вам ясно какой он человек.
Чорд!
Оказывается я совсем никудышний специалист со своим пятилетним опытом программирования под .NET. Ведь я не знаю этих людей в лицо! :)
И, кстати, какое отношение имеет Руссинович к .NET? Ну, так чтобы его ставить в один ряд с Рихтером. Я бы понял, если бы вы искали человека для написания драйверов или просто WinAPI-разработчика.
Может и никудышний. 5 лет ничего еще не значет. А Руссинович для того чтобы узнать насколько глубоки познания чувака. По желанию можно добавить и Стивена Синофски.
Вот именно! Может или не может — это и есть задача собеседования. А у вас, как я понял, я бы собеседование не прошел в любом случае. Но вот человек с хорошей памятью на лица прошёл бы, несмотря на его реальные знания.
во время интервью не только компания собеседует кандидата, но и наоборот. так что скорее компания Arterius не прошла бы это собеседование
гм… Стивен Синофски? кто это для обычного разработчика? президент подразделения MS вас интересует больше, чем Макконнелл, дядюшка Боб, Фаулер, де Марко etc etc???

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

ИМХО, странная методика. Она совершенно не показывает уровень подготовки кандидата. Все, что Вы этим проверите — это наличие зрительной памяти на лица, и интересовался ли кандидат, как они выглядели.
Я все понимаю, но зачем вычислять факториал PHP программисту?
это тривиальная задача, показывает
а) знает ли кандидат математику — некоторые не знают, что такое факториал ;)
б) легкость в применении алгоритмики и знания php — в частности применение рекурсии.

факториал — это как лакмусовая бумажка, сразу показывает плохого разработчика, но не показывает хорошего. Причем времени-то надо 2-5 минут. супер эффективно :)
Уж лучше спросить о пропорциях (вычислить размеры картинки), чем про факториал. Это чуть проще с точки зрения математики, но часто применяется на практике и не показывается в учебниках.
напишите подробнее условие задачи, пожалуйста.
Дана произвольная картинка, нужно сделать ресайз до размеров 100x100. Опишите алгоритм решения задачи.

Если бы мне такое задали, то ответ был бы таков… Это стандартная задача, существует множетсво готовых библиотек для её решения, но если нужно, я могу описать алгоритм. Далее я спрошу как именно выполнять ресайз картинки (нужно ли обрезать края и как именно или заливать свободные участки каким-либо цветом). В зависимости от ответом, можно написать немного псевдокода.
За 5 минут можно написать метод, вычисляющий факториал? Для некоторых языков можно, но в подавляющем большинстве случаев получится полная фигня, которая не посчитает даже факториал от 25, не говоря уж о трёхзначных аргументах.

> знает ли кандидат математику — некоторые не знают, что такое факториал ;)

это ж школьная программа

> легкость в применении алгоритмики и знания php — в частности применение рекурсии.

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

вычисления факториала рекурсией упирается в число итераций и как следствие в производительность компьютера. кочумай старик машина думать будет — это недопустимо.
Упирается оно в длину стэка (если нет оптимизации хвостовой рекурсии). Точное вычисление факториала N>0 всегда требует минимум N+1 итерацию (если не рассчитывать заранее).
Вы правы если говорить о любом из современных интерпретаторов языков. Там есть заданные ограничения. Сейчас специально проверил для себя вбив в браузер такое:

javascript:function fac(n) {return !n? 1: n * fac(n-1);} alert(fac(100));

Chrome и Reconq нормально дают факториал на 100, на 1000 говорит — infinity. Perl и PHP (не буду приводить) на 1000 дают INF.

А у Python есть sys.setrecursionlimit который таки позволяет вычислить 1000!

В общем я редко пишу на чём-нибудь из перечисленного выше и у меня таких добрых инструментов нет. Поэтому на переполнениях мои компиляторы и ассемблеры тупо виснут.
Мой комментарий (чуть выше) о том же самом как-то остался незамеченным… Действительно Ruby или Python дадут вычислить 1000!
Но делать это через рекурсию не стоит хотя бы потому, что глупо забивать стек при реализации задачи, вовсе не требующей рекурсии. Но Ruby и Python — скорее исключения (и то надо не recursion limit поднимать, а обычным циклом считать), т.к. для большинства языков программирования не хватит возможностей stdlib для написания за 5 минут метода, вычисляющего факториал (для теста хотя бы тот же 1000!). Просто тупо не будет целочисленного типа данных, в который влезет результат. Это можно обойти, но не за пару минут…
UFO just landed and posted this here
Ну хорошо, раз Вы сами вызвались, назовите хотя бы ещё 8 популярных языков, кроме Ruby и Python (чтобы до десятка добрать), которые в стандартной библиотеке имеют целочисленный тип, способный вместить 1000!
UFO just landed and posted this here
Эм… Давайте начнём с простого — с PHP. Программу считающую факториал 1000! на PHP и не дающую INF. Внимательно. Я свою дам:

Результат:

0! = 1
10! = 3628800
20! = 2.4329020081766E+18
30! = 2.6525285981219E+32
40! = 8.159152832479E+47
50! = 3.0414093201713E+64
60! = 8.3209871127414E+81
70! = 1.197857166997E+100
80! = 7.1569457046264E+118
90! = 1.4857159644818E+138
100! = 9.3326215443944E+157
110! = 1.5882455415227E+178
120! = 6.6895029134491E+198
130! = 6.4668554892205E+219
140! = 1.3462012475718E+241
150! = 5.7133839564459E+262
160! = 4.7147236359921E+284
170! = 7.257415615308E+306
180! = INF
190! = INF
200! = INF
UFO just landed and posted this here
да, php нужно собрать с bcmath, это не stdlib однозначно.
Слушайте, да ведь Вы хитрец! А почему сразу не:

$fact1 = gmp_fact(1000);
echo gmp_strval($fact1). "\n";

?! O_o
> .net языки, начиная с 4.0

Важное уточнение, только начиная с 4.0. А подобная задача мелькает на собеседованиях гораздо дольше, чем существует .NET 4.0

С Java и Perl соглашусь. Действительно языков оказалось больше, чем я полагал.
Ну а функциональные — это отдельная тема, тут изначально речь шла о PHP, в котором в stdlib этого нет, да и не в stdlib есть возможность работать со строками, содержащими большие числа, но не с целочисленным типом данных.
Вычисление факториала рекурсией — самый медленный и неэффективный способ. Используя простой for(;;) можно получить выигрыш в производительности во много много раз. Поэтому, если испытуемый пишет рекурсивный алгоритм для факториала, то он не знаком даже с основами теории алгоритмов.
Разве сложность что цикла, что рекурсии не O(N)? Как раз по теории алгоритмов эти способы эквиваленты, по-моему. А то что цикл бывает быстрее — это особенность конкретной платформы, в которой итерация цикла в разы медленнее итерации рекурсивного вызова и временем на итерацию нельзя пренебречь по сравнению с временем на умножение. На других платформах можно получить вообще идентичный объектный код. А может даже есть платформы где цикл будет медленнее. Плюс если факториалы нужно вычислять неоднократно от относительно случайных чисел, то рекурсивная функция оптимизируется по скорости куда проще цикла, а на некоторых платформах так вообще автоматически без каких-либо усилий со стороны программиста (а цикла на них может вообще не быть). PHP, увы, к ним не относится, но, повторюсь, это уже знание особенностей конкретной платформы и теория алгоритмов тут не причём — по ней алгоритмы одной сложности.
Давайте не будем спорить беспредметно. C#.

namespace Factorial
{
    class Program
    {
        static int recCalls = 0;
        static int iterCalls = 0;

        static void Main(string[] args)
        {
            var program = new Program();
            var fact = 8;

            Console.WriteLine("recursion {0} calls {1}", program.FactRecursion(fact), recCalls);
            Console.WriteLine("recursion {0} calls {1}", program.FactIteration(fact), iterCalls);

            Console.ReadLine();
        }

        public int FactRecursion(int num)
        {
            recCalls++;
            if (num == 0) return 0;
            if (num == 1) return 1;            
            return FactRecursion(num - 1) + FactRecursion(num - 2);
        }

        public int FactIteration(int num)
        {
            if (num == 0) return 0;
            if (num == 1) return 1;
            
            var first = 0;
            var second = 1;

            for (var i = 2; i <= num; i++)
            {
                iterCalls++;
                var current = second + first;
                first = second;
                second = current;
            }

            return second;
        }
    }
}

Количество вызовов рекурсивной функции — 67. Количество итераций в итеративной функции — 7. Если вместо 8 поставить 15, то количество вызовов рекурсивной — 1973, количество вызовов итеративной — 14. Даже по этим числам видно, что время работы рекурсивного алгоритма — экспоненциальное, итеративного — линейное. Это без учета особенности платформы.
ОПС :). Пардон, я ещё сплю. Вместо факториала посчитал числа Фибоначчи :))
То-то я смотрю что-то странное :)
Очевидно, вы правы, а я нет. Это я о времени работы рекурсии и итерации при вычислении факториала.
К пункту «тестовое задание» просится подпункт «тестовая зарплата». :)
Зарплата всегда по результатам собеседования.
И, немного, по результатам наглости.
Ну, я на самом деле немного не о том. Просто существует комплекс мер, который позволяет работнику и работодателю относиться друг к другу по-джентельменски, с определенным доверием. Работодателя, к примеру, защищает пункт о испытательном сроке. Кроме того, у нанимаемого специалиста — если речь не идет о совсем уж новичке — обычно есть некие доказательства собственной компетентности. Портфолио дизайнера, сертификаты администратора/тестера/разработчика. Есть, в конце концов, рекомендации бывших коллег.
Но почему-то в СНГ до сих пор необходимо что-то доказывать работодателю на тестовых заданиях.
Мое частное мнение заключается в том, что это такой же нонсенс, как и тестовая зарплата.
А почему бы и нет? Тестовое задание, именно простое, тестовое, которое можно сделать на коленке за 15 минут, позволит оценить текущее состояние человека в предметной области. Я не говорю о компаниях, которые в качестве тестового задания дают такую задачу, которая решает какую-то проблему в компании, а потом отказывают. Таких надо карать, всяко. Вот принес вам человек диплом об окончании музыкальной школы / сертификат по стрельбе / водительские права. Вроде как доказательство компетентности. А с другой стороны человек может уже лет 5 не играет / не стреляет / не водит.
>А почему бы и нет?
Нет — это если вдруг компания не считает соискателя лжецом, который купил себе сертификаты(признак высокой компетентности в предмете на момент сдачи экзамена), диплом о высшем образовании (признак способности к быстрому обучению), и наврал на счет рекомендаций бывших коллег (признак уживчивости в коллективе и трудоспособности at all), подсунув телефоны своих приятелей по двору.
Я собственно пишу без претензий к конкретной конторе, просто по мне — лучше строить рабочие отношения на взаимном доверии. И если человек говорит, что последние 5 лет играл/стрелял/водил, при этом демонстрируя документы, телефоны предыдущего начальника и коллег — то я бы ему поверил, а не просил бы сыграть на дудочке.
И собеседоваться, и работать в атмосфере взаимного доверия — куда приятнее.
к сожалению или к счастью, у нас нет адекватного ответа по профессиональному образованию. Если ты повар — есть диплом иди готовь и тут его можно пустить на кухню в подмастерье. А мастер или шеф-повар, думаю все равно доказывает свою компетентность.

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

Портфолио ничего не дает и не доказывает, если ты «плаваешь в теме». Приведу пример из практики. Пришел ко мне разработчик, уже несколько лет работал в крупных компаниях, сам сделал несколько проектов на 1С-Битрикс — о чем говорит его портфолио. На проверку элементарными вопросам и заданием на рекурсию выяснилось, что он php изучает только второй месяц(!) — и вот как, как после этого верить людям? :)

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

Дальше, не стоит забывать о том, что работодатель рискует своими деньгами!, у нас в стране налоги это 50% от зарплаты. Готовы ли вы слепо поверить только бумажкам и отдать за это свои деньги?
Приведу пример из практики. Пришел ко мне разработчик, уже несколько лет работал в крупных компаниях, сам сделал несколько проектов на 1С-Битрикс — о чем говорит его портфолио. На проверку элементарными вопросам и заданием на рекурсию выяснилось, что он php изучает только второй месяц(!) — и вот как, как после этого верить людям? :)


Вы не смешиваете кислое со сладким? Какое отношение имеет 1С к php? Открытая позиция у Вас для кого предназначалась для 1С или для php разработчика?
1C-Битрикс имеет как раз таки непосредственное отношение к php. Не путайте с 1С-Бухгалтерией.
Да, Вы правы. :)
Сейчас погуглил: я перепутал. Признаю и посыпаю голову пеплом. :)
UFO just landed and posted this here
А мне не надо знать как кандидат этого достигает с его слов.
Обладая большим опытом, я вижу это сам без его слов :)

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

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

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

Я хотел сказать, что есть не зримые методы оценки, такие способности есть у вас от Бога или вы смогли их в себе развить (я считаю, что у меня симбиоз — и было, да еще и развил). И что в собеседование не включать — всего не узнаешь. Здесь главная задача отсеить явно плохих — остальное тестирование идет на испытательном сроке, которое уже во всей красе показывает, как человек работает, как он мыслит и тд. И кстати за такое тестирование и обучение ему уже платят деньги.
Речь в Вашей статье шла об алгоритме, а не о техниках открытия третьего глаза для оценки кандидатов которых Вы достигли. Вы понимаете разницу?

Если «есть не зримые методы оценки» и «мы разработчики — элита», то Вас к людям допускать нельзя. Вы будете плодить вокруг себя элитарность и незаменимых людей подобранных по незримым оценкам. Вы сами об этом написали.
Ну и что? Если он эффективно работал в крупных компаниях и это его портфолио — сделано классно, какая разница сколько он его «изучает»? Допустим человек 5 лет писал драйвера для QNX, а потом 2 мес. «изучал» php. И чего? Я вообще не понимаю что там «изучать» в php? kernel developer-ам это вообще не понятно. Это наверное те же люди которые изучали ТурбоПаскаль, затем Лого, затем Бейсик, затем очень долго как пишут в популярных книгах «ломали психологический барьер перед Си», постигали ООП… Что Вы там постигаете всё? )))

p.S. На самом деле выбешивает просто вот такая «илита». Которая на проверку оказывается обыкновенными быдлокодерами с ЧСВ. Существа нежные, ранимые, ага… Гнать ссаными тапками и нанимать тех кто работает.
Я вообще не понимаю что там «изучать» в php?

Прежде всего «экосистему» — библиотеки, фреймворки, CMS и т. п., причём при отсутствии явного мэйнстрима. Да и в самом языке (синтаксисе) достаточно много вещей, которые «это невозможно понять, это нужно запомнить». Скажем то, что в C/C++ называется «member and pointer operators» ([], ->)в PHP операторами является весьма условно, это отдельные синтаксические конструкции, требующие в качестве первого операнда не любое выражение типа array или object, а только конкретные, весьма ограниченные его виды, до недавнего времени практически только переменные этого типа, лишь в 5.4 разрешили использовать конструкции типа func()[0] или (new Class())->method(), причём уверенности что можно использовать, например, (new Class())[0]->method() нет и быть не может, поскольку формальное описание -> отсутствует.
Ну и если человек первый раз сталкивается с http, то и там многое нужно изучить, хотя бы на уровне абстракций предоставляемых PHP.
А зачем? CMS не имеет никакого отношения к языку, а имеет отношение к сисадминству и допиливанию для которого как правило надо знать алгоритмику в общем виде и задачи решать чаще нетривиальные, для которых готового ничего всё равно нет. А если есть, то howto находится гуглом в 5 мин.

Таких вещей которые «невозможно понять, нужно запомнить» есть. Вы правы. Но опытному программисту хватит нескольких дней в новом языке (любом) чтобы запомнить. Он же не тупой. При переключении с языка на язык те мантры которые так нужно было запомнить быстро забываются. Потому что это преходящие всё вещи. Сегодня PHP, завтра BHB, послезавтра BGG ))

phpframeworks.com по итогам голосования PHP-сообщества утверждает что самый лучший фреймворк Yii. Что-то мне кажется шанс встретить в РФ задачи PHP-программисту для Yii… Я от них чаще слышу Zend да Kohana. Выучить экосистему — этот десяток мажорных фреймворков? Так а зачем? Инженерный подход гласит: возмите manual и посмотрите каким вызовом это достигается, так? Когда же мы начинаем работать над конкретной задачей с конкретным инструментарием, вот тогда мы туда и подтягиваем всё необходимое и запоминаем всё что регулярно используется. Стиль программирования вещь вообще надязыковая.
Про CMS я упомянул в плане использования её как фреймворка, то есть наращивание или изменение готовой функциональности. Для этого нужно знать её архитектуру, способы внедрения своего кода и т. п.

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

Эмм… Гласит. ) Если продолжить аналогию, то инструментом будет являться ЯП, деталью — фреймворк и CMS — материалом.

Отсюда, того чтобы прибить молотком (инструмент) на гвоздь (деталь) над дверью подкову (материал), уметь подковывать кобылу необязательно. =)

Imho, конечно.
Необязательно конечно, но надо знать как инструмент (с какой стороны за молоток браться), так и детали (какой стороной гвоздь забивать) с материалами (гвоздём лучше в отверстие попасть специально для прибивания предназначенное, а не пытаться подкову пробить). :)
Точно! И для этого необходимо и достаточно нескольких вечеров с инструментом. Чтобы рассмотреть с какой стороны за молоток браться и какой стороной гвоздь забивать. Куда лучше гвоздём попасть конечно приходит с опытом. =)
Собственно мне данная проблематика когда-то была довольно близка, даже топик когда-то писал, там один из рассматриваемых пунктов — выполнение тестового. Кстати, доводы ув. Mantis считаю довольно убедительными.
Нужно учесть, что по портфолио разработчика сложно оценить качество кода. Для него самого единственным критерием может быть, что код работает и он абсолютно искренне будет говорить что хорошо и быстро решал поставленные задачи. А вот для работодателя это единственным критерием может и не быть, для него ещё важно и качество — чистота, поддерживаемость и т. п., и вот тут их субъективные оценки могут не совпадать.
Значит либо разработчик станет писать код под требования работодателя, либо не пойдет на эту позицию.
Просто человек все равно всегда адаптируется к новой среде, и по-моему лучше правильно оценить потенциал и способность к адаптации, чем искать идеального кандидата, который будет вытягивать проект начиная с первого рабочего дня (что в любом случае нереально :) ).
Так или иначе, при наличии диплома, стажа, портфолио и сертификатов, все сводится именно к потенциальной способности кандидата давать нужный результат.
Другое дело, если человеку 18 лет, и он сам толком не уверен в выбранной профессии. Тогда можно и тестовое задание, благо вчерашнему школьнику это будет даже интересно.
Зачастую нанимают не для раскрытия потенциала, а для закрытия дыры — при прочих равных если человек уже пишет код более-менее соответствующий требованиям компании (не оформление, а архитектура), то возьмут его.
Вы тоже не платили соискателям за выполненное тестовое задание?
про оплату этого тестового задания оплата не предусматривается.
за все время только один человек спросил про оплату и остался без работы у нас.

Остальные получили либо опыт в объективной обратной связи, либо работу — ростокинолада, все по честному. :)
про оплату этого тестового задания оплата не предусматривается.

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

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

Или же не захотел идти к Вам работать? ;)
Не стоит расценивать возможность работать в Вашей компании, как возможность поймать Бога за яйца. Хотя, дело за Ваше.

либо работу — ростокинолада

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

Так вот, у них была реклама: РостокиноЛада — все по честному.
Из этого появился анекдот:

— Я позвонил в Ростокино Лада и мне сказали, что когда вы придете к нам в салон, вас возможно н@е$ут.
— Я приехал в автосалон и действительно — н@&#али! Ростокинолада — все по честному! :))))

Что касается тестовое задание может быть оплачено, если работа оформлена в виде открытого конкурса на очень крутую работу. :)
Скажите, а в понятие качественных тенденций будет входить оплата соискателями-студентами того курса обучения, который они фактически проходят, выполняя для моей компании тестовое задание — с подбором литературы, постановкой вменяемой задачи (не факториала), code review результатов их, гм, творчества и т.п.?
Нет, т.к.:
1. Это студент, у него по определению денег нет.
2. Курс обучения — выполнения Вашего тестового — я называю это синдром пойманного за яйца Бога. Не знаю как и где, но в Минске нехватка IT специалистов — спрос превышает предложение. Поэтому та или иная компания может сидеть месяцами без специалиста, специалист сидеть без работы не будет.
3. Я постоянно провожу code review, плюс разрабатываю свои пректы и могу отрекомендовать целую библиотеку по различным направлениям развития, начиная от простейших подходов к программированию и заканчивая довольно обширным менеджментом. А так же я имею мускулистое телосложение, вешу 95кг, подтягиваюсь 10 раз и отжимаюсь на брусьях 15 раз. И за всё это мне не платят денег. Не поверите. :)
Верим, за мускулы в IT точно платить не будут :), за сам факт обладания той или иной технологией тоже.

Здесь как и везде платят за прикладное применение и умение ваших знаний. Что не повторяться — все равно лучше, чем автор не напишу, почитайте статью — Программирование как искусство — Вам многое станет понятно, за что платят деньги, а за что нет.
Вы знаете, я ничего не имею против того, что «программирование — искусство», но как и везде — нужно «пахать». Поэтому давайте оставим спор.
Мне частично понравился Ваш подход: то что Вы перезваниваете, обдумываете того или иного кандидата, вы занимаетесь делом. Конечно это не предел, но на мой взгляд — довольно неплохие тенденции, которые ещё стОит развивать и надеюсь на достигнутом Вы останавливаться не будете.
Но есть один момент, противоречащий моим внутренним убеждениям — за выполненную работу нужно платить. Есть, разумеется, ряд факторов качественно\лажово, вовремя\затянуто, которые могут оспорить выплаты или их размер.
Но согласитесь, придёт к Вам работать человек, Вы на нём поимеете (самый подходящий глагол на мой взгляд) денег, как минимум 3x. Подальше положишь, поближе возьмёшь. ;)
за выполненную работу нужно платить — согласен.

>Но согласитесь, придёт к Вам работать человек, Вы на нём поимеете (самый подходящий
>глагол на мой взгляд) денег, как минимум 3x. Подальше положишь, поближе возьмёшь. ;)

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

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

Но полностью соглашусь с тем, если человека можно поиметь в три конца (так у говорят в бизнесе) — то и человек будет неплохо получать и он будет очень ценным сотрудником на рынке и соответственно у него всегда будет работа, а так и машина, женщины, квартира, яхты… :)
Нет, его просто и незатейливо будут иметь во все щели. :D
UFO just landed and posted this here
Забавно, я такого не встречал. Если задание было нормальной сложности на час и более — «держи мил человек компьютер, интернет и среду, в которой мы работаем», если «на бумажке» — задача никогда не превышала по сложности того же факториала и скорее сводилась к описанию алгоритма, а не конкретной реализации.
Меня собеседовали в ключе «Вот бумажка/доска/расшаренный документ, напишите код» много раз, и как-то не было с этим проблем, ни практических, ни морально-этических. Спрашивают же не затейливые библиотечные функции с десятком параметров, а базовый синтаксис языка + логику + алгоритмы. Более того, если нужна функция или какой-то особенный синтаксис, то интервьюер честно говорит «вам понадобится вот такое, вы можете не помнить наизусть» и сам пишет сигнатуру или пример синтаксиса.
Как вариант просто честно сказать, что не помнишь сигнатуру какой-нибудь strpos(), что привык полагаться на IDE/мануал. Обычно претензий не было, отсевали по другим критериям.
UFO just landed and posted this here
или, как вариант: есть число А и есть число В, сделайте так, чтобы А стало В, В стало А без применения третьей переменной.
Просто A←→B имеет меньше подводных камней:
a^=b; b^=a; a^=b;.

Тогда как с суммой имеем возможность переполнения:
c=a+b; b=c-b; a=c-b.

Также наверное стоит упомянуть про встроенные возможности x86:
mov eax, [a]; xchg eax, [b], mov [a], eax
Очепятка: b=c-a
отнюдь нет

b = c-b = (a+b)-b = a
Подводный камень и для xor swap есть: когда оба входных параметра указывают на одну переменную, она зануляется.
Ну те, кто изучал ассемблер, без труда вспомнят про xor. Хотя если у вас вакансия не на системного программиста, то зачем ему знать это?
в питоне вообще (a, b) = (b, a) сделает то, что надо
а в ruby даже скобки не нужны:
a, b = b, a

но тогда ведь не получится блеснуть знанием ассемблера, что изначально предполагает эта задача :-)
Кстати, этот пример уже настолько известный, что опять же выявит скорее эрудированного человека.
К тому же если бы у меня в проекте таким образом меняли местами переменные — я бы руки за такое поотрывал бы. :)
Ведь этот же код потом кто-то смотреть будет, пытаться понять, почему оно не работает. Нееет. Лучше var с = a; a = b; b = c; или даже:
static bool Swap<T>(ref T x, ref T y)
{
    try
    {
        T t = y;
        y = x;
        x = t;
        return true;
    }
    catch
    {
        return false;
    }
}

...

Swap(ref a, ref b);
так здесь третья переменная введена или это решение задачи с тремя переменными? но тогда с=a+b
Это не решение, это так как я бы писал в рабочем проекте.
Кстати, многим здесь читающим будет полезно почитать Я — Бренд или как поднять себе ценность?

Еще мне интересно, кто проходил тестирование по 1С-Битрикс, как со стороны соискателя, так и со стороны работодателя. Какие вопросы задают, что тестируют?
«Помним, что основной мотиватор — это сама работа» — сомнительно. Если точнее, то точно нет. Работа не может быть мотиватором. Как не может быть мотиватором и зарплата.
Если соискатель сам говорит, что «хочу работу. хочу денег», значит он слишком зашорен. Он скучен и узколоб.
Мотиватором может быть либо конечный результат работы («я создам крутое решение», «я смогу получить уважение своего учителя, если устроюсь рботать в крутую компанию», «я заработаю на машину, засчет которой мне даст вон та телочка» (да, бывает и такая мотивация), либо некий процесс («я решаю интересные задачи», «я работаю с душевными людьми», «до этой работы я каждый день езжу на велосипеде») и даже может быть просто по фану («я влядею долей в бизнесе и мне хватает денег, но я просто люблю программировать и потому с интересом буду делать это у вас» (отчасти шутка. Я такие варианты встречал, но не в IT, хотя чем черт не шутит)).
И это первая часть. Намерение соискателя.
Теперь вторая. Намерение работодателя. Как верно замеченно — «зачем ищем сотрудника». И это нельзя отдавать на откуп сомнительной эйчарне. Намерение работодателя — это тот результат, который он хочет от работника, будь то единовременное большое задание или постоянно выполняемая работа.
И третье: а что вообще и как вокруг. Если вы ищите там, где мало претедентов и их уровень невысок — то, наверное, главным критерием будет обучаемость. Если ищите среди множества профессионалов, то вступают в дело вторичные факторы, как то уживчивость, коммуникабельность и любимая футбольная команда.

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

И тогда вопрос — как определить чего хочет соискатель? как определить чего хотим мы? и как вообще понять что к чему сейчас в наших краях? а этого инстрментария в статье нет. Увы.

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

Я понял Ваш запрос :) — и в одной из будущих статей я напишу о своем опыте в этом вопросе на конкретном примере.
Да, вот еще что забыл от комментировать:

Мотиватор — это сама работа, поверьте. Если это не так, то вы не станете профессионалом. Про это много умных книжек написано :)

По результату работают люди со скилами менеджера
По процессу — это путь к гуру :)
По фану — это про меня, причем правильнее будет не доля в бизнеса (сама по себе она ничего не дает), а пассивный доход. Поэтому я сейчас занимаюсь развитием бизнеса одной IT компании по фану — мне нравится общаться с высоко интеллектуальными людьми, а деньги они зарабатываются простым путем с людьми без фантазии и образования :)
перефразирую: работа — слишком обобщенное понятие. Мотиватором выступает не сама работа, а определенный ее аспект. И чем лучше и работодатель и соискатель понимают, что это за аспект, тем продуктивнее их сотрудничество.
К сожалению, зачастую сосикатели сами не понимают что ими движит (или не хотят признавать/признаваться), и тут вся надежда компании на профессионализм проводящего собеседование.
Для меня два аспекта: возможность заниматься любимым делом и возможность не думать о деньгах на еду, квартплату, одежду, литературу и т. п.
абсолютно!
кто знает что он хочет — уже находится на том месте, где приходится искать и собеседовать тех, кто еще не знает :)
и все же. Вас мотивирует возможность не думать, или же все же просто жизнь на определенном уровне комфорта?

И да, «любимое дело» ничуть не менее обобщенное понятие, чем «работа». Хотя оно и говорит чуть больше о соискателе, но если бы я хотел бы понять, как именно этот соискатель может улучшить работу фирмы работая в ней — меня бы такой ответ всеравно не устроил бы, и я продолжу копать: «какие именно дела вы считаете любимыми?».
«Не думать» образно, конечно. Да, какой-то уровень. Но так можно назвать и минимальный прожиточный уровень, но там нужно сильно думать об оптимизации затрат и планировать бюджет. Вот пожалуй — чтобы не нужно было планировать бюджет на обычные покупки. Понятно, что с квартирой или машиной, предметами роскоши и т. п. такое пройдёт мало у кого, но не год экономить чтоб средний холодильник купить или отказываться от пятничных посиделок с друзьями и/или коллегами чтобы книжку умную купить.

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

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

Помню когда еще учился в институте, и интернет только только появлялся у корпоративных клиентов провайдеров (компаний), вот тогда для меня было забавно: «Заниматься любимым делом — сидеть в интернете, а тебе еще за это деньги платят» :)

С возрастом и профессионализмом понятие «любимое дело» становится только изощренней и извращенней :)
Sign up to leave a comment.

Articles

Change theme settings