A>По-моему, этим все загран компании грешат. Ходил в CTL несколько раз, потом раз! пауза. всё, думаю. A>Ан нет! через 2 недели звонят — приходите. Ведущий спец был в отпуске. A>Я отпуск, конечно, уважаю Но необходимость уже отпала.
это нормально если контора большая и кандидат проходит через длинную цепочку прежде чем будет принято решение о его приеме
(HR-> старший программист-> Ведущий программист -> начальник IT департамента )
было дело я очень хотел попасть в Аэлиту. сделал тестовое задание — через месяц-полтора меня пригласили на собеседование
я к тому времени уже работал в другой конторе и от их предложения вежливо отказался.
O>На тот момент я уже получил предложение работы, которое меня устроило, и имелась определенная договоренность с другим работодателем. Соответственно, пришлось отказаться. Так что имейте в виду и возможность подобной схемы развития событий.
Я то имею, но толку с этого немного. Я никак не отношусь к HR, и у нас на самом деле длинная цепочка.
Здравствуйте, Spidola, Вы писали:
S>Здравствуйте, Awaken, Вы писали:
L>>>Теперь думаю может зря поторопился (к слову, не сдлелал даже элементарной обработки исключений)?.. L>>>Какие представляются требования к решению задач в CQG или других компаниях?
A>>"Требования к решению — это должно выглядеть как хороший код production-качества, как вы его понимаете"
S>Претенденту при получении задания нужно задавать дополнительный вопрос работодателю: "Прошу вас уточнить требования такие-то и такие-то и прислать мне пример вашего хорошего кода production-качества как у вас принято его понимать"...
S>Тогда можно сделать и нормальное решение задачи, которое априори удовлетворит работодателя (ведь главное, как человек сумеет подстроиться под команду и инфраструктуру разработки, а не то, что он понимает под production-качеством и, тем более, какое production-качество было приемлемо на его старойм месте работы).
По моему вы не так меня поняли. Человек никуда не денется — подстроится под команду и инфраструктуру. Это вроде как предполагается. Оценивается инженерное мастерство. Любой дизайн и реализация — это компромисс. Важно, какое решение выберет претендент, какие алгоритмы и структуры данных применит, как раскидает функционал по классам, и, самое главное, отдает-ли он себе при этом отчет, что делает. То есть, сможет ли он (на собеседовании) аргументированно объяснить, почему он сделал именно так, а не иначе, какие у этого решения плюсы, и какие минусы. Вот что проверяется.
Смысла же давать задачи, решения которых априори нас удовлетворят, я не вижу — зачем их давать, если мы заранее (априори) знаем, что ответ нас удовлетворит? Надо ценить время кандидата, оно и так тратится на решение задач, так пусть хоть с пользой.
A>это нормально если контора большая и кандидат проходит через длинную цепочку прежде чем будет принято решение о его приеме A>(HR-> старший программист-> Ведущий программист -> начальник IT департамента ) A>было дело я очень хотел попасть в Аэлиту. сделал тестовое задание — через месяц-полтора меня пригласили на собеседование A>я к тому времени уже работал в другой конторе и от их предложения вежливо отказался.
Вот и у меня сейчас такая ситуация складывается. Что называется "и хочется и колется". Предложений по Москве на счёт работы очень много, все зовут, манят и пряниками в обеды и золотыми горами в качестве заработной платы.
Есть ли смысл так долго разбирать кандидатов? Ведь если соискатель действительно достойный, то его с руками и ногами звберут в какую-нить другую контору (как это с тобой и произошло). Выходит что за месяц текучки остаются или очень упорные товарищи, которые готовы всё это время ждать и ничего не кушать. Или это люди, которые просто не смогли найти другую работу. Или потом нужно предлагать что-то с помощью чего можно переманить специалиста, который уже куда-то хорошо устроился.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, Spidola, Вы писали:
S>>Здравствуйте, Awaken, Вы писали:
L>>>>Теперь думаю может зря поторопился (к слову, не сдлелал даже элементарной обработки исключений)?.. L>>>>Какие представляются требования к решению задач в CQG или других компаниях?
A>>>"Требования к решению — это должно выглядеть как хороший код production-качества, как вы его понимаете"
S>>Претенденту при получении задания нужно задавать дополнительный вопрос работодателю: "Прошу вас уточнить требования такие-то и такие-то и прислать мне пример вашего хорошего кода production-качества как у вас принято его понимать"...
S>>Тогда можно сделать и нормальное решение задачи, которое априори удовлетворит работодателя (ведь главное, как человек сумеет подстроиться под команду и инфраструктуру разработки, а не то, что он понимает под production-качеством и, тем более, какое production-качество было приемлемо на его старойм месте работы).
G>По моему вы не так меня поняли. Человек никуда не денется — подстроится под команду и инфраструктуру. Это вроде как предполагается. Оценивается инженерное мастерство. Любой дизайн и реализация — это компромисс. Важно, какое решение выберет претендент, какие алгоритмы и структуры данных применит, как раскидает функционал по классам, и, самое главное, отдает-ли он себе при этом отчет, что делает. То есть, сможет ли он (на собеседовании) аргументированно объяснить, почему он сделал именно так, а не иначе, какие у этого решения плюсы, и какие минусы. Вот что проверяется.
С этим согласен — применение тех или иных алгоритмов, тех или иных технических решений с их последующим объяснением действительно выявит логику принятия решений кандидата. Кстати, если у человека есть логика вроде: "Я сделал здесь так, потому что, рассмотрев такие и такие варианты пришёл к выводу, что этот вариант наиболее уместен в данном случае...", то это уже немалый плюс. Даже если принято не совсем верное решение, то это можно скорректировать, указав, где человек не прав. А если логики нет совсем, это уже диагноз.
G>Смысла же давать задачи, решения которых априори нас удовлетворят, я не вижу — зачем их давать, если мы заранее (априори) знаем, что ответ нас удовлетворит? Надо ценить время кандидата, оно и так тратится на решение задач, так пусть хоть с пользой.
Я несколько утрировал, конечно. Однако имелось ввиду проблема с придирчивым отношением к формату кода. Если дать человеку задачу и принятые в компании правила к оформлению кода, то тогда можно сразу "двух зайцев убить". С одной стороны проверить, как человек справится с оформлением кода, с другой стороны уже оценить качество кода.
Например, есть правила оформления кода (вроде таких). Они выдаются человеку и он в соответствии с данными правилами всё оформляет. При этом собственно технические решения находятся внутри и их можно спокойно оценивать. Это сбережёт от принятия решения на основе негативных эмоций, появляющихся от того, что человек использует не тот стиль при именовании переменных или не так оформляет комментарии. А также поможет отделить неумение человека рассматривать пиковые ситуации и обрабатывать исключения от банальных несоответствий правилам оформления.
По поводу "ценить время кандидата" — ИМХО как раз кандидат не будет думать и маяться, как надо оформить код для конкретного работодателя.
Здравствуйте, Spidola, Вы писали:
S>Я несколько утрировал, конечно. Однако имелось ввиду проблема с придирчивым отношением к формату кода. Если дать человеку задачу и принятые в компании правила к оформлению кода, то тогда можно сразу "двух зайцев убить". С одной стороны проверить, как человек справится с оформлением кода, с другой стороны уже оценить качество кода.
Это точно. Есть неплохие девелоперы, но которых не заставить оформлять код, так, как принято в команде. Что еще хуже — они бывает забивают на сам процесс, ради быстроты выдачи результата. Результат — печален. Такой подход с выдачей спецификаций (надеюсь они у вас есть) позволяет рассмотреть кандидата с еще одной стороны. Надо взять на вооружение.
Здравствуйте, Spidola, Вы писали:
S>Я несколько утрировал, конечно. Однако имелось ввиду проблема с придирчивым отношением к формату кода. Если дать человеку задачу и принятые в компании правила к оформлению кода, то тогда можно сразу "двух зайцев убить". С одной стороны проверить, как человек справится с оформлением кода, с другой стороны уже оценить качество кода.
Если человек привык хоть к какому-нибудь code standard, то он будет ему следовать всегда. Это привычка, и так удобнее. Это дополнительный плюс. Из-за одного отсутствия code standard никто резать кандидата не будет — хороших спецов и так не сыщешь, чтобы оказывать им из-за фсякой фигни. Так что это не смертельно.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, Spidola, Вы писали:
S>>Я несколько утрировал, конечно. Однако имелось ввиду проблема с придирчивым отношением к формату кода. Если дать человеку задачу и принятые в компании правила к оформлению кода, то тогда можно сразу "двух зайцев убить". С одной стороны проверить, как человек справится с оформлением кода, с другой стороны уже оценить качество кода.
G>Если человек привык хоть к какому-нибудь code standard, то он будет ему следовать всегда. Это привычка, и так удобнее. Это дополнительный плюс. Из-за одного отсутствия code standard никто резать кандидата не будет — хороших спецов и так не сыщешь, чтобы оказывать им из-за фсякой фигни. Так что это не смертельно.
Не смертельно, конечно. Поэтому я и предлагал сразу устранить эту проблему, послав ему code standard. Ведь может быть хороший спец, но "застенчивый", и будет, бедолага, напрягаться лишний раз. Поэтому ИМХО лучше пояснить, что такое "production-качество".
Да и вообще — ведь известная истина, что чем лучше задача будет поставлена, тем лучше она будет сделана. Другое дело, если конторе лень ставить задачу полностью или нужно посмотреть, как человек работает с "неполным объёмом требований".
Вроде как был я соискателем на должность UNIX-программиста. Являюсь я системным UNIX программистом (IPC разные, системы встраиваемые) и так получилось, что мой плюсовый код скорее сишный (например я не использую потоки -- вместо них printf/scanf; результаты работы методов и ошибки получаю через возвращаемые значения, а не через исключения; при обработки ошибок в теле функций использую goto вместо исключений и т.д.). Хотя для решения ваших задач заглянул в книжку, как пользовать потоки
Через неделю после того, как отправил решение послал письмо вашему HR. Ответ отрецательный, но замечаний по коду я не получил.
Работу я уже нашел. Но теперь мучает вопрос -- почему? Можно ли так писать код на плюсах, как его пишу я?
И если нет, то почему?
P.S. Решал я задачи eurodiffusion и интегральчик считал. Можно ли выложить код для всеобщего поругательства?
Здравствуйте, Gaperton, Вы писали:
O>>На тот момент я уже получил предложение работы, которое меня устроило, и имелась определенная договоренность с другим работодателем. Соответственно, пришлось отказаться. Так что имейте в виду и возможность подобной схемы развития событий.
G>Я то имею, но толку с этого немного.
Мое "имейте в виду" было обращено к кандидатам, ожидающим решения вашей конторы
G>Я никак не отношусь к HR, и у нас на самом деле длинная цепочка.
Не, все понятно — длинная цепочка, все дела. Но зачем тогда называть заведомо некорректную дату принятия решения?
L>Вроде как был я соискателем на должность UNIX-программиста. Являюсь я системным UNIX программистом (IPC разные, системы встраиваемые) и так получилось, что мой плюсовый код скорее сишный (например я не использую потоки -- вместо них printf/scanf; результаты работы методов и ошибки получаю через возвращаемые значения, а не через исключения;
Системного Unix программиста обычно меньше всего беспокоит использование printf("Hello, world\n") или cout << "Hello, world" << endl. Настоящие системные unix программисты иcпользуют printk() . Прежде всего оценивается аккуратность кода — если одна переменная называется send_counter а другая uiReceiveCounter — то это говорит об отсутствии внутренней дисциплины программера. Второе качество кода — стиль и ясность, понятно что стили бывают разные и оценки субъективны, но меня почему-то воротит от Win32 с его LPTCBSP_CHAR GetSuperObjectState(...четырнадцать загадочных параметров...). Третий параметр — эффективность кода. Четвертый — понятность и т.д.
Код который понравится мне может вызвать отвращение у другого человека и наоборот. Все не просто субъективно а супер субективно. Код который пять лет назад казался мне дерьмом -может начинать нравится сейчас (вероятно я как программер немного вырос). Опытные программеры могут писать код в разных стилях. Для микроконтроллера код будет выглядеть одним способом, для PC другим. код может быть на писан на С в стиле C++ и наоборот, код для multithreaded приложения будет глобально отличаться от signle-threaded.
A>Есть ли смысл так долго разбирать кандидатов? Ведь если соискатель действительно достойный, то его с руками и ногами звберут в какую-нить другую контору (как это с тобой и произошло). Выходит что за месяц текучки остаются или очень упорные товарищи, которые готовы всё это время ждать и ничего не кушать. Или это люди, которые просто не смогли найти другую работу. Или потом нужно предлагать что-то с помощью чего можно переманить специалиста, который уже куда-то хорошо устроился.
Не совсем так. Я, к примеру, просто искал хорошую работу, работая в это время на не очень хорошей.
Я выбрал компанию, в которую ОЧЕНЬ хотел устроиться и отправил резюме. Через 2 месяца я пришел туда работать. 2 месяца — огромный срок, если у тебя нет работы. Но ведь не всегда так бывает. Я в это время и кушал и получал другие предложения (про запас).
Но необходимость уже отпала.
