Здравствуйте, Other Sam, Вы писали:
OS>Здравствуйте, AntZ, Вы писали:
L>>>Теперь думаю может зря поторопился (к слову, не сдлелал даже элементарной обработки исключений)?.. L>>>Какие представляются требования к решению задач в CQG или других компаниях?
AZ>>Я предлагаю такой вариант. Заводите себе левый ящик на mail.ru и посылаете запрос на задание. Маловероятно, что они имеют много вариантов заданий, скорее всего один или несколько. Анализируете и решаете без напрягов. Потом повторяете то-же с официального адреса. Разведка — великое дело.
AZ>>Так-же ценится умение задавать дополнительные вопросы. Спросите насколько детальное решение им надо, спросите нужна ли обработка исключений — какие ограничения по использованию multi-thread'ов и т.д.
OS>При найме прогрмного архитектора. Попросите его написать простенький (анализатор, модель, базовый класс или что-то еще). Если сразу взялся писать — то он вам не нужен. Если стал выяснять требования — самое то.
Да, а если не нужный Вам чел спец в таком деле, и заранее знает что этот отморозок начитавшийся пургши в инете спросит у него?
Все такие эксперты прям вообще, с пары слов могут определить стоит претендента брать или нет..
Смешно смотреть на такие рассуждения, психологи доморощенные...
L>Теперь думаю может зря поторопился (к слову, не сдлелал даже элементарной обработки исключений)?.. L>Какие представляются требования к решению задач в CQG или других компаниях?
Я предлагаю такой вариант. Заводите себе левый ящик на mail.ru и посылаете запрос на задание. Маловероятно, что они имеют много вариантов заданий, скорее всего один или несколько. Анализируете и решаете без напрягов. Потом повторяете то-же с официального адреса. Разведка — великое дело.
Так-же ценится умение задавать дополнительные вопросы. Спросите насколько детальное решение им надо, спросите нужна ли обработка исключений — какие ограничения по использованию multi-thread'ов и т.д.
L>Теперь думаю может зря поторопился (к слову, не сдлелал даже элементарной обработки исключений)?.. L>Какие представляются требования к решению задач в CQG или других компаниях?
ИМХО, ошибка — то, что ты этого не выяснил подробно прямо у них. То есть взялся за задание, не выснив толком, что от тебя хотят. В реальности ведь всегда есть какие-то требования, находящиеся за границами формального ТЗ, но тем не менее очень сильно влияющие на требующееся решение.
Например, решение должно быть:
* готово вчера
* сделано на века, надежным как танк
* легко читаемым
* гибким
* очень быстрым
* многоплатформенным
Здравствуйте, AntZ, Вы писали:
L>>Теперь думаю может зря поторопился (к слову, не сдлелал даже элементарной обработки исключений)?.. L>>Какие представляются требования к решению задач в CQG или других компаниях?
AZ>Я предлагаю такой вариант. Заводите себе левый ящик на mail.ru и посылаете запрос на задание. Маловероятно, что они имеют много вариантов заданий, скорее всего один или несколько. Анализируете и решаете без напрягов. Потом повторяете то-же с официального адреса. Разведка — великое дело.
AZ>Так-же ценится умение задавать дополнительные вопросы. Спросите насколько детальное решение им надо, спросите нужна ли обработка исключений — какие ограничения по использованию multi-thread'ов и т.д.
При найме прогрмного архитектора. Попросите его написать простенький (анализатор, модель, базовый класс или что-то еще). Если сразу взялся писать — то он вам не нужен. Если стал выяснять требования — самое то.
L>>Теперь думаю может зря поторопился (к слову, не сдлелал даже элементарной обработки исключений)?.. L>>Какие представляются требования к решению задач в CQG или других компаниях?
A>"Требования к решению — это должно выглядеть как хороший код production-качества, как вы его понимаете"
Претенденту при получении задания нужно задавать дополнительный вопрос работодателю: "Прошу вас уточнить требования такие-то и такие-то и прислать мне пример вашего хорошего кода production-качества как у вас принято его понимать"...
Тогда можно сделать и нормальное решение задачи, которое априори удовлетворит работодателя (ведь главное, как человек сумеет подстроиться под команду и инфраструктуру разработки, а не то, что он понимает под production-качеством и, тем более, какое production-качество было приемлемо на его старойм месте работы).
А то получается как с ФАПСИшниками — делаешь им задачу — они говорят "небезопасно, не принимаем". Спрашиваешь, какие требования к безопасности, а они говорят "не можем вам раскрыть — это гостайна". Вот и идёт бестолковое переделывание по несколько раз, пока не заплатишь денег за сертификацию... (Это я так, к слову, в качестве примера )
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, Spidola, Вы писали:
S>>Здравствуйте, Awaken, Вы писали:
L>>>>Теперь думаю может зря поторопился (к слову, не сдлелал даже элементарной обработки исключений)?.. L>>>>Какие представляются требования к решению задач в CQG или других компаниях?
A>>>"Требования к решению — это должно выглядеть как хороший код production-качества, как вы его понимаете"
S>>Претенденту при получении задания нужно задавать дополнительный вопрос работодателю: "Прошу вас уточнить требования такие-то и такие-то и прислать мне пример вашего хорошего кода production-качества как у вас принято его понимать"...
S>>Тогда можно сделать и нормальное решение задачи, которое априори удовлетворит работодателя (ведь главное, как человек сумеет подстроиться под команду и инфраструктуру разработки, а не то, что он понимает под production-качеством и, тем более, какое production-качество было приемлемо на его старойм месте работы).
G>По моему вы не так меня поняли. Человек никуда не денется — подстроится под команду и инфраструктуру. Это вроде как предполагается. Оценивается инженерное мастерство. Любой дизайн и реализация — это компромисс. Важно, какое решение выберет претендент, какие алгоритмы и структуры данных применит, как раскидает функционал по классам, и, самое главное, отдает-ли он себе при этом отчет, что делает. То есть, сможет ли он (на собеседовании) аргументированно объяснить, почему он сделал именно так, а не иначе, какие у этого решения плюсы, и какие минусы. Вот что проверяется.
С этим согласен — применение тех или иных алгоритмов, тех или иных технических решений с их последующим объяснением действительно выявит логику принятия решений кандидата. Кстати, если у человека есть логика вроде: "Я сделал здесь так, потому что, рассмотрев такие и такие варианты пришёл к выводу, что этот вариант наиболее уместен в данном случае...", то это уже немалый плюс. Даже если принято не совсем верное решение, то это можно скорректировать, указав, где человек не прав. А если логики нет совсем, это уже диагноз.
G>Смысла же давать задачи, решения которых априори нас удовлетворят, я не вижу — зачем их давать, если мы заранее (априори) знаем, что ответ нас удовлетворит? Надо ценить время кандидата, оно и так тратится на решение задач, так пусть хоть с пользой.
Я несколько утрировал, конечно. Однако имелось ввиду проблема с придирчивым отношением к формату кода. Если дать человеку задачу и принятые в компании правила к оформлению кода, то тогда можно сразу "двух зайцев убить". С одной стороны проверить, как человек справится с оформлением кода, с другой стороны уже оценить качество кода.
Например, есть правила оформления кода (вроде таких). Они выдаются человеку и он в соответствии с данными правилами всё оформляет. При этом собственно технические решения находятся внутри и их можно спокойно оценивать. Это сбережёт от принятия решения на основе негативных эмоций, появляющихся от того, что человек использует не тот стиль при именовании переменных или не так оформляет комментарии. А также поможет отделить неумение человека рассматривать пиковые ситуации и обрабатывать исключения от банальных несоответствий правилам оформления.
По поводу "ценить время кандидата" — ИМХО как раз кандидат не будет думать и маяться, как надо оформить код для конкретного работодателя.
Здравствуйте, lunc, Вы писали:
L>Пару недель назад в понедельник выслали задания из CQG. Потратил на них три вечера на работе L>и в четверг выслал решения. Результат отрицательный.
Пару недель назад в понедельник выслали задания из CQG. Потратил на них три вечера на работе
и в четверг выслал решения. Результат отрицательный.
Теперь думаю может зря поторопился (к слову, не сдлелал даже элементарной обработки исключений)?..
Какие представляются требования к решению задач в CQG или других компаниях?
L>Теперь думаю может зря поторопился (к слову, не сдлелал даже элементарной обработки исключений)?.. L>Какие представляются требования к решению задач в CQG или других компаниях?
"Требования к решению — это должно выглядеть как хороший код production-качества, как вы его понимаете"
S>Тогда можно сделать и нормальное решение задачи, которое априори удовлетворит работодателя (ведь главное, как человек сумеет >подстроиться под команду и инфраструктуру разработки, а не то, что он понимает под production-качеством и, тем более, какое production->качество было приемлемо на его старойм месте работы).
не буду гадать, и я не из CQG. но я эту фразу понимаю "так как вы бы писали код для своей работы".
A>это нормально если контора большая и кандидат проходит через длинную цепочку прежде чем будет принято решение о его приеме A>(HR-> старший программист-> Ведущий программист -> начальник IT департамента ) A>было дело я очень хотел попасть в Аэлиту. сделал тестовое задание — через месяц-полтора меня пригласили на собеседование A>я к тому времени уже работал в другой конторе и от их предложения вежливо отказался.
Вот и у меня сейчас такая ситуация складывается. Что называется "и хочется и колется". Предложений по Москве на счёт работы очень много, все зовут, манят и пряниками в обеды и золотыми горами в качестве заработной платы.
Есть ли смысл так долго разбирать кандидатов? Ведь если соискатель действительно достойный, то его с руками и ногами звберут в какую-нить другую контору (как это с тобой и произошло). Выходит что за месяц текучки остаются или очень упорные товарищи, которые готовы всё это время ждать и ничего не кушать. Или это люди, которые просто не смогли найти другую работу. Или потом нужно предлагать что-то с помощью чего можно переманить специалиста, который уже куда-то хорошо устроился.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, Spidola, Вы писали:
S>>Я несколько утрировал, конечно. Однако имелось ввиду проблема с придирчивым отношением к формату кода. Если дать человеку задачу и принятые в компании правила к оформлению кода, то тогда можно сразу "двух зайцев убить". С одной стороны проверить, как человек справится с оформлением кода, с другой стороны уже оценить качество кода.
G>Если человек привык хоть к какому-нибудь code standard, то он будет ему следовать всегда. Это привычка, и так удобнее. Это дополнительный плюс. Из-за одного отсутствия code standard никто резать кандидата не будет — хороших спецов и так не сыщешь, чтобы оказывать им из-за фсякой фигни. Так что это не смертельно.
Не смертельно, конечно. Поэтому я и предлагал сразу устранить эту проблему, послав ему code standard. Ведь может быть хороший спец, но "застенчивый", и будет, бедолага, напрягаться лишний раз. Поэтому ИМХО лучше пояснить, что такое "production-качество".
Да и вообще — ведь известная истина, что чем лучше задача будет поставлена, тем лучше она будет сделана. Другое дело, если конторе лень ставить задачу полностью или нужно посмотреть, как человек работает с "неполным объёмом требований".
Здравствуйте, EXECUTORСo, Вы писали:
EXE>Здравствуйте, lunc, Вы писали:
EXE>Есть такой подход у некоторых, "если парень через неделю присылает правильное решение то его надо взять"
Здравствуйте, lunc, Вы писали:
L>Теперь думаю может зря поторопился (к слову, не сдлелал даже элементарной обработки исключений)?..
Я тоже отбираю персонал. И, если бы увидел такое решение, даже не стал бы приглашать на интервью
А если бы увидел решение, пусть и больше на разработку которого времени бы потратилось, но оно было качественным, то на интервью пригласил бы точно
Здравствуйте, EXECUTORСo, Вы писали:
EXE>Здравствуйте, Курилка, Вы писали:
EXE>Если тебе это не надо, ты точно не станешь доделывать задачу.
А причём тут "доделывать"?
Может он за 2 дня решил, потом 5 дней пил, просох и вспомнил — надо бы кинуть письмо
Я, конечно, утрирую, но мало ли какие бывают ситуации — ничего эта неделя не гарантирует и любые такие "подходы" — есть просто шаманство с бубном, не более...
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, EXECUTORСo, Вы писали:
EXE>>Здравствуйте, Курилка, Вы писали:
EXE>>Если тебе это не надо, ты точно не станешь доделывать задачу.
К>А причём тут "доделывать"? К>Может он за 2 дня решил, потом 5 дней пил, просох и вспомнил — надо бы кинуть письмо К>Я, конечно, утрирую, но мало ли какие бывают ситуации — ничего эта неделя не гарантирует и любые такие "подходы" — есть просто шаманство с бубном, не более...
точно, однако наверняка и испытательный срок никто не отменял
плюс видно по лицу чем чел последние сутки занимался
Здравствуйте, apih, Вы писали:
A>А как скоро из cqg приходит ответ о правильности или неправильности решения задачи?
Собственно, нет такого ответа. Если задача решена приемлемо, то следует приглашение на собеседование. Что такое "приемлемо" зависит от проверяющего, оценивается не только и не столько работоспособность программы. Как я говорил, пишите простой, понятный и красивый код промышленного качества, и не ошибетесь. Использование языковых и дизайнерских наворотов не по делу а также трех контейнерных библиотек вперемешку (с целью показать, что вы их знаете) идет кандидату в минус. Срок — я точно не знаю, но думаю, что порядка недели.
A>>А как скоро из cqg приходит ответ о правильности или неправильности решения задачи? G> Срок — я точно не знаю, но думаю, что порядка недели.
Пример из жизни: отправил решенное задание, созвонился с человеком из HR, который мной занимался, получил заверения в том, что решение получено и ответ будет к такому-то сроку.
В названный срок ответа не было, я решил, что не подхожу — ну и продолжил поиски работы.
Через неделю (!) после обозначенного срока получаю звонок от вашего HR, в котором меня пытаются пригласить на собеседование.
На тот момент я уже получил предложение работы, которое меня устроило, и имелась определенная договоренность с другим работодателем. Соответственно, пришлось отказаться. Так что имейте в виду и возможность подобной схемы развития событий.
A>>>А как скоро из cqg приходит ответ о правильности или неправильности решения задачи? G>> Срок — я точно не знаю, но думаю, что порядка недели.
O>Пример из жизни: отправил решенное задание, созвонился с человеком из HR, который мной занимался, получил заверения в том, что решение получено и ответ будет к такому-то сроку. O>В названный срок ответа не было, я решил, что не подхожу — ну и продолжил поиски работы. O>Через неделю (!) после обозначенного срока получаю звонок от вашего HR, в котором меня пытаются пригласить на собеседование. O>На тот момент я уже получил предложение работы, которое меня устроило, и имелась определенная договоренность с другим работодателем. Соответственно, пришлось отказаться. Так что имейте в виду и возможность подобной схемы развития событий.
По-моему, этим все загран компании грешат. Ходил в CTL несколько раз, потом раз! пауза. всё, думаю.
Ан нет! через 2 недели звонят — приходите. Ведущий спец был в отпуске.
Я отпуск, конечно, уважаю Но необходимость уже отпала.
A>По-моему, этим все загран компании грешат. Ходил в CTL несколько раз, потом раз! пауза. всё, думаю. A>Ан нет! через 2 недели звонят — приходите. Ведущий спец был в отпуске. A>Я отпуск, конечно, уважаю Но необходимость уже отпала.
это нормально если контора большая и кандидат проходит через длинную цепочку прежде чем будет принято решение о его приеме
(HR-> старший программист-> Ведущий программист -> начальник IT департамента )
было дело я очень хотел попасть в Аэлиту. сделал тестовое задание — через месяц-полтора меня пригласили на собеседование
я к тому времени уже работал в другой конторе и от их предложения вежливо отказался.
O>На тот момент я уже получил предложение работы, которое меня устроило, и имелась определенная договоренность с другим работодателем. Соответственно, пришлось отказаться. Так что имейте в виду и возможность подобной схемы развития событий.
Я то имею, но толку с этого немного. Я никак не отношусь к HR, и у нас на самом деле длинная цепочка.
Здравствуйте, Spidola, Вы писали:
S>Здравствуйте, Awaken, Вы писали:
L>>>Теперь думаю может зря поторопился (к слову, не сдлелал даже элементарной обработки исключений)?.. L>>>Какие представляются требования к решению задач в CQG или других компаниях?
A>>"Требования к решению — это должно выглядеть как хороший код production-качества, как вы его понимаете"
S>Претенденту при получении задания нужно задавать дополнительный вопрос работодателю: "Прошу вас уточнить требования такие-то и такие-то и прислать мне пример вашего хорошего кода production-качества как у вас принято его понимать"...
S>Тогда можно сделать и нормальное решение задачи, которое априори удовлетворит работодателя (ведь главное, как человек сумеет подстроиться под команду и инфраструктуру разработки, а не то, что он понимает под production-качеством и, тем более, какое production-качество было приемлемо на его старойм месте работы).
По моему вы не так меня поняли. Человек никуда не денется — подстроится под команду и инфраструктуру. Это вроде как предполагается. Оценивается инженерное мастерство. Любой дизайн и реализация — это компромисс. Важно, какое решение выберет претендент, какие алгоритмы и структуры данных применит, как раскидает функционал по классам, и, самое главное, отдает-ли он себе при этом отчет, что делает. То есть, сможет ли он (на собеседовании) аргументированно объяснить, почему он сделал именно так, а не иначе, какие у этого решения плюсы, и какие минусы. Вот что проверяется.
Смысла же давать задачи, решения которых априори нас удовлетворят, я не вижу — зачем их давать, если мы заранее (априори) знаем, что ответ нас удовлетворит? Надо ценить время кандидата, оно и так тратится на решение задач, так пусть хоть с пользой.
Здравствуйте, Spidola, Вы писали:
S>Я несколько утрировал, конечно. Однако имелось ввиду проблема с придирчивым отношением к формату кода. Если дать человеку задачу и принятые в компании правила к оформлению кода, то тогда можно сразу "двух зайцев убить". С одной стороны проверить, как человек справится с оформлением кода, с другой стороны уже оценить качество кода.
Это точно. Есть неплохие девелоперы, но которых не заставить оформлять код, так, как принято в команде. Что еще хуже — они бывает забивают на сам процесс, ради быстроты выдачи результата. Результат — печален. Такой подход с выдачей спецификаций (надеюсь они у вас есть) позволяет рассмотреть кандидата с еще одной стороны. Надо взять на вооружение.
Здравствуйте, Spidola, Вы писали:
S>Я несколько утрировал, конечно. Однако имелось ввиду проблема с придирчивым отношением к формату кода. Если дать человеку задачу и принятые в компании правила к оформлению кода, то тогда можно сразу "двух зайцев убить". С одной стороны проверить, как человек справится с оформлением кода, с другой стороны уже оценить качество кода.
Если человек привык хоть к какому-нибудь code standard, то он будет ему следовать всегда. Это привычка, и так удобнее. Это дополнительный плюс. Из-за одного отсутствия code standard никто резать кандидата не будет — хороших спецов и так не сыщешь, чтобы оказывать им из-за фсякой фигни. Так что это не смертельно.
Вроде как был я соискателем на должность 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 месяца — огромный срок, если у тебя нет работы. Но ведь не всегда так бывает. Я в это время и кушал и получал другие предложения (про запас).
доделывать задачу.
