В продолжение разговоров о тестовых заданиях перед собеседованием (часть I, часть II, часть III) публикую решение той задачи, которую я до недавнего времени давал всем кандидатам на должность C++ программиста. Спецификация задачи в том виде, в котором я ее отсылал кандидатам, находится под катом.
Через один-два дня я опубликую свои комментарии по этой задаче: почему она мне нравится, что она показывает, какие качества разработчика она, на самом-то деле, раскрывает и т.д.
С огромным удивлением для себя обнаружил, что в Windows (XPsp3, по крайней мере) и в Linux-е в именах файлов можно использовать несколько идущих подряд слешей. И это не приводит к ошибкам. Т.е. имена ./this.file, .//this.file, .///this.file, .////this.file являются вполне себе корректными именами.
RSDN-овское обсуждение темы тестовые задания, на которую я разродился большой заметкой (благодаря Роману Орышко, заметка засветилась в данной теме) производит на меня следующие впечатления:
Вообще, само обсуждение данной темы наводит меня на следующую аналогию. В некоторых районах городов в темное время суток случайных прохожих грабят и бьют. Можно, конечно, озадачиться вопросом: “А зачем это делают?” И получить, например, ответ: “Очень деньги нужны”. А потом долго обсуждать, какие все-таки грабители лохи и какой бред они говорят. Деньги, мол, им нужны. Так пусть получат хорошее образование, устроятся на хорошую должность или откроют свой бизнес. Всяко будет больше толку.
Да, наверное, такое обсуждение будет интересным. Толку от него не будет. Поскольку важно не то, почему гопники дают прохожим в бубен. Важно не получить в бубен самому :)
Но больше всего меня умиляют реплики вроде:
Наниматель, который заставляет соискателя прыгать по его правилам — должен явно выделяться среди остальных. Например, быть представительством Гугла в большом городе
В переводе на русский матерный это выглядит так: “Я не позволю себя ебать! Хотя, если это будет Гугл или Мелкософт, то пусть ебет, один разочек можно и потерпеть…”
Утро, заварил чаю, просмотрел несколько новостей. Чтобы окончательно проснуться, решил глянуть на статью “Лисп — философия разработки” из пятого номера журнала Теория Практика Функционального Программирования. Дошел до абзаца:
Синтаксис этого языка — это единообразная префиксная нотация (S-выражения). Вот простейший пример Лисп-кода: (defun sum (a b) (+ a b)), эквивалентом которого в языке Алгол-семейства был бы function sum(a, b) { return a + b; }. Благодаря этому исходный код гомоморфен синтаксическому дереву, используемому компилятором. Языки, обладающие таким свойством, называются также гомоиконными языками.
После прочтение выделенного курсивом я выпал в осадок. Нет, нельзя нормальных людей с утра долбить словами “гомоморфен” и “гомоиконными”.
На статью забил. Она явно написано лисперами для лисперов. Все остальные люди им пофиг. Впрочем, не пофиг. Программисты на других языках им нужны для организации эпических флеймов, в которых пара-тройка убежденных лисперов будут доказывать всему остальному миру, что Lisp не мертв.
Выпустил MxxRu версии 1.5.2. В ней реализовано использование разных имен Qt4-библиотек для Release и Debug режимов. Например, в Release режиме к проекту подключается библиотека QtCore, а в Debug режиме – QtCored4. Применяется такой выбор имен только на платформе Windows.
Спасибо Николаю Гродзицкому за обнаружение таких различий в именах Qt4-библиотек. Сам я Debug режимом практически никогда не пользуюсь, поэтому для меня это было, к сожалению, не актуально.
Взять новую версию MxxRu можно либо вручную с RubyForge, либо выполнив команду gem install Mxx_ru (для обновления с предыдущих версий следует выполнить gem update Mxx_ru).
На RSDN затронули тему, которая некоторое время назад меня изрядно беспокоила: тестовые задания для соискателей. Тов.Gradient интересуется, зачем нужны задания, зачем нужны объемные задания и т.д.
К моменту начала написания данных строк в теме не засветился ни один работодатель (upd. очень толково там отписался ув.тов.Коденок). А я недавно в этом качестве выступал. Поэтому скажу пару-тройку своих слов на эту тему.
Довольно подробно я освещал вопрос тестовых задач, которые выдаются соискателю до собеседования, в прошлом году. Но там упор сделан на противопоставлении маленькой задачки на собеседовании и более объемной задачи перед собеседованием. Поэтому тема не совсем раскрыта.
Итак, зачем нужны тестовые задания?
Тестовые задания нужны для того, чтобы узнать:
Я считаю, что ни собеседование, ни конкретная маленькая задача на собеседовании не могут дать ответы на эти вопросы. Если взять человека на испытательный срок, то все нужные ответы будут получены.
Но что делать, если вакансия одна, а соискателей пять человек и каждый из них более-менее одинаково отвечает на вопросы на собеседовании?
Что делать, если мы предлагаем на испытательный срок сумму в N денежек, а человек хочет N+M?
Как оценить затраты на испытательный срок новичка, который с испытательным сроком не справляется? Это же не только его зарплата. Это время коллег, которое тратится на введение нового человека в курс дела. Это время, которое было упущено компанией на плохого соискателя. В конце-концов, когда человек не справляется с испытательным сроком – это стресс. Например, для меня, как для принимающего решение об увольнении.
Резюмируя. Когда я получаю решение тестового задания, я уже вижу, плохой ли это программист или нет. Если не плохой, то на собеседовании остается выяснить только его вменяемость. Если он вменяемый, то путь к испытательному сроку открыт. При этом я уже могу приблизительно оценить, сколько этому человеку нужно платить на время испытательного срока (чтобы и человека не обидеть, и не переплачивать).
Следующий вопрос: разве поиск сотрудника не заходит в тупик, отпугивая большинство претендентов заданиями?
Есть два подхода к найму сотрудника. Первый – это переманивание. Кто-то работал с кем-то, дал хорошую рекомендацию, взял на себя ответственность. Тут тестовые задания не нужны и не применяются.
Второй подход – это объявление о вакансии. Приходят совершенно незнакомые люди, о некоторых из которых даже нет возможности навести справки. Их нужно проверять. Посему даются тестовые задания. Может быть какой-то процент слишком дорого ценящих себя супер-пупер программистов или, напротив, недооценивающих себя, не отзываются на вакансию из-за тестового задания.
Ну и фиг с ними. Лично мне не нужны ни “звезды”, ни “задроты”. Нужны нормальные, адекватные люди. Которые умеют программировать, любят это делать и не боятся свои умения продемонстрировать.
Тем более, что есть еще один фактор: мы работаем в провинции. Не самые последние работодатели в своем городе. Можем ставить условия. Не нравится – ну походи по рынку, поищи более выгодные предложения.
Практика показывает, что в тупик не заходим. Вакансии закрываем. Работали бы мы в Москве или Питере, возможно, поступали бы по другому. А может и нет.
Следующий вопрос: зачем нужны объемные задания (8+ часов)?
Затем, что нельзя оценить человека на программе из 50-100 строк. Должно быть, как минимум, строк 300-500 (речь о C++). А программу в 300 строк, с нормальным дизайном, с тестами и комментариями, за пару часов не напишешь. Даже не спроектируешь. Поэтому лучше дать человеку побольше времени, чтобы он потом не мог оправдываться аргументами вроде “мне времени не хватило”.
Ну и затрону еще несколько вопросов, которые не были озвучены Gradient-ом.
Присваивают ли работодатели результаты труда соискателя? Т.е. дали тестовую задачку, человек ее решил, мы взяли решение и использовали у себя в продакшене, а человеку сказали: “Спасибо, но вы нам не подходите!”
Мы так не делаем. Тестовое задание я даю такое, которое нам в работе нигде не нужно. Это чистая тестовая задачка, без какой-либо перспективы промышленного применения.
Является ли выполнение тестового задания показателем того, что человек готов быть рабом компании?
А человек сам для себя решить это в состоянии? Допустим, тестовое задание он выполняет хорошо и мы делаем ему предложение. Конкретное. Он что, не может выдвинуть свои условия или не согласиться с чем-то?
Когда он уже работает, он что не может принимать решения сам? Браться за какой-то кусок работы или нет. Соглашаться с озвученными строками или нет. Выходить в выходные на работу в случае аврала или нет, например. Отказываться от очередного отпуска или нет. Просить повышение зарплаты или нет.
Как все это коррелирует с тестовым заданием? Если подразумевается, что человек, который соглашается на выполнение тестового задания, это безропотная скотинка, то я лично так не считаю. Я даю тестовое задание, чтобы оценить человека как программиста. Способность к “прогибанию” и “работе за гроши” я не оцениваю.
Брать безропотных людей, не имеющих собственного мнения или не способных его донести и защитить, очень стремно. Они будут делать только то, что им скажешь. А не скажешь, не будут. Лучше в своей команде их не держать.
Вот как-то так. Еще раз повторю: условия у нас специфические. Возможно, в крупном городе с большим рынком специалистов, мы вели бы себя иначе. Возможно. Но не факт.
В конце-концов, глупо брать в цирк жонглера, не убедившись в том, что он умеет жонглировать. А программирование – это не цирк, здесь способности кандидата за пару часов не проверишь. И лично я считаю странным, что человек, умеющий программировать, не хочет продемонстрировать свои умения при таком важном и нечастом событии, как смена работы.
И работа на сегодня, похоже, отменяется :)
Сравнив цены на прибамбасы для дартса в Москве и в Англии (интернет-магазин a180), мы с коллегами решили заказать себе дротики, хвостовики и оперения в Англии. Что и проделали 7-го мая. А сегодня посылка уже оказалась у нас в руках:
Заказывали на троих и с запасом, поэтому барахла так много.
Я себе заказал Unicorn Gripper – 90% вольфрама, 25 грамм:
плюс еще всякой лабуды:
Все это удовольствие мне обошлось в $50, включая расходы на доставку.
Что можно сказать? Восторг! Качество попаданий не улучшилось :) Зато удовольствие от бросков – на порядок, а то и больше.
Новые дротики реально тонкие. Вот сравнение нового вольфрамового дротика и старого латунного:
Так что все условия уже созданы (сизалевая мишень, вольфрамовые дротики). Осталось научиться выбивать 180 очков :) К чему, собственно, я и собираюсь прямо сейчас и приступить :)))
Пользуясь случаем хочу еще раз высказать огромную благодарность Дмитрию Елисееву за помощь в оформлении, оплате и получении заказа!
В снукере есть максимальный брейк – 147 очков в одном подходе. В дартсе аналогичным достижением является списывание 501 очка (лег) всего 9-ью дротиками (т.н. nine darts finish). Явление это весьма редкое. Многие игроки не делают такого за всю свою карьеру.
А вот Фил “The Power” Тейлор совсем недавно, 24 мая 2010, в финале White & Mackay Premier League сделал два(!) девяти-дартсовых лега! В одном матче. В финале.
Вот как это было:
…окончательно угробив при этом и так изрядно поношенные перышки :)
Пишу сейчас на работе документацию. Потребовалось найти пример сервиса, который активизируется командой сотового телефона (в терминологии GSM-овских стандартов это называется supplementary services). Вроде того, что сменить PIN-код можно командой **05*PUK*NewPIN*NewPIN#.
Удалось нарыть вот что:
Кроме знаменитого и непонятно что меряющего индекса TIOBE, оказывается, существует еще и langpop.com. Лично мне показалось, что он более адекватный. Поскольку замеряет популярность по разным источникам: количество найденных страниц в Yahoo, статистика по вакансиям, статистика по продажам книг, статистика по проектам на Freshmeat и Google Code, информация с Del.icio.us, Ohloh, а так же статистика с Lambda the Ultimate, programming.reddit.com, Slashdot, Freenode IRC.
То, что показано на нормализованном общем графике очень хорошо укладывается в мое представление о востребованности и популярности языков:
Тоже самое я могу сказать и о популярности языков в разговорах о программировании (поскольку программирование и разговоры о программировании это две большие разницы):
Мой пересказ главы “The Professional Programmer” из книги “97 Things Every Programmer Should Know”. Главу написал Роберт Мартин.
Что такое профессиональный программист?
Единственным основным качеством профессионального программиста является персональная ответственность. Профессиональные программисты берут на себя ответственность за свою карьеру, за свои экспертные оценки, за свои календарные планы, за свои ошибки и за свое мастерство. Профессиональный программист не перекладывает свою ответственность на других.
- Если вы профессионал, то вы отвечаете за свою карьеру. Вы отвечаете за собственное обучение. Вы отвечаете за то, чтобы идти в ногу с индустрией и технологией. Слишком много программистов считают, что их обучение является задачей их работодателей. Извините, но это совершенно не так. Как вы думаете, поступают ли так врачи? Как вы думаете, поступают ли так юристы? Нет, они занимаются собственным образованием, тратя на это свое время и собственные деньги. Они тратят изрядную часть своего свободного времени на изучение журналов и судебных решений. Они сами поддерживают собственный уровень. Тоже самое должны делать и мы. Отношения между вами и вашим работодателем четко прописаны в вашем контракте. Вкратце: ваш работодатель обещает вам платить, а вы обещаете хорошо делать свою работу.
- Профессионалы отвечают за код, который они пишут. Они не отдают код до тех пор, пока они не убедятся, что он работает. Задумайтесь об этом на минуту. Можете ли вы представить себя профессионалом, если вы собираетесь зарелизить код, в котором вы сами не уверены? Профессиональные программисты ожидают, что отдел тестирования ничего не обнаружит, потому, что они не отдают код до тех пор, пока тщательнейшим образом не оттестируют его. Конечно, отдел тестирования найдет какие-нибудь проблемы, поскольку никто не совершенен. Но у вас, как у профессионала, должно быть стремление к тому, чтобы ничего не оставлять отделу тестирования.
- Профессионалы являются командными игроками. Они берут на себя ответственность за результат работы всей команды, а не только за свою собственную часть. Они помогают друг другу, они учат друг друга, они даже прикрывают друг друга, если это необходимо. Если кто-то из команды срывается и выпадает, то остальные делают его работу, зная о том, что в один прекрасный день им самим потребуется прикрытие коллег.
- Профессионалы не могут мириться с большими списками багов. Большущий список багов – это небрежность. Системы с тысячами багов в баг-трекерах – это трагические следствия недобросовестности. В самом деле, в большинстве проектов сама необходимость баг-трекера – это симптом недобросовестности. Только очень громадные системы могут иметь настолько большие списки дефектов, что для их обслуживания требуются автоматизированные инструменты.
- Профессионалы не производят беспорядок. Они гордятся своим мастерством. Они поддерживают свой код чистым, хорошо структурированным и простым для изучения. Они следуют общепринятым стандартам и устоявшимся best practices. Они никогда не суетятся. Представьте себе, что вы можете наблюдать за тем, как врач проводит хирургическую операцию на открытом сердце – вашем сердце. У этого врача есть дедлайн (в прямом смысле слова). Он должен закончить операцию до того, как аппарат искусственного кровообращения уничтожит слишком много клеток вашей крови. Как вы хотите, чтобы врач вел себя? Хотите ли вы, чтобы он действовал как типичный разработчик софта – суетясь и производя дерьмовый код? Хотите ли вы, чтобы он сказал: “Я исправлю это попозже”? Или же вы хотите, чтобы он аккуратно следовал правилам, не торопясь, будучи уверенным в том, что он тщательно выбрал наилучший способ проведения операции. Хотите ли вы беспорядка или профессионализма?
Профессионалы ответственны. Они отвечают за собственную карьеру. Они отвечают за то, что их код работает так, как нужно. Они отвечают за качество своего мастерства. Они не отбрасывают свои принципы даже в условиях дедлайнов. Более того, именно под прессом сроков они еще строже следуют правилам, в правильности которых они уверены.
PS. Свое мнение по поводу этого описания профессиональных программистов я выскажу в комментарии.
Временами очень сильно вставляет понимание того, что в технике фотографии ничего не понимаешь. Знания, которые когда-то давным-давно были получены, успешно выветриваются. Остается только способность нажимать на кнопку фотоаппарата в режиме полного автомата. И хорошо, если при этом я умудряюсь не завалить горизонт :(
В общем, остро чувствую необходимость подучить матчасть. Поскольку выдержку от диафрагмы я еще отличаю, но есть подозрение, что это временно.
Посему прошу уважаемых читателей посоветовать хорошую книгу для начинающих фотолюбителей. Желательно с упором на цифровую фотографию. Если будет с какими-то базовыми уроками по постобработке цифровых снимков – вообще замечательно.
Главное требование к книге – упор на практику с большим количеством примеров. Вроде такого: вот мы снимаем портрет, здесь мы выставили такую диафрагму и выдержку и вот что получилось, а здесь мы выставили такую экспозицию и вот разница.
Очень хорошо то, что хотелось бы найти, сформулировано в веселой книжке “Непотопляемый Тиликум”:
Слава "Боудичу", все получалось довольно складно. Конечно, похвастаться доскональным изучением этого отличного руководства было бы с моей стороны большим нахальством. Я и прочитать его до конца не успел, не то что освоить. А получалось все единственно только благодаря самой американской системе обучения. У них ведь как: сперва практика, затем разные приемы, облегчающие эту практику, а уж потом, под конец, очень кратко - теория.
Позднее я купил себе немецкий учебник по навигации. Там с самого начала шла математика, каждое положение было обстоятельно аргументировано. Ежели бедный матросик, вознамерившийся сдать штурманский экзамен, от всего этого не впадал в полное уныние и не отказывался от своей затеи, его снова ждала математика, а уж где-то в самом конце говорилось кое-что и о практике. Что же касается всевозможных приемов, облегчающих практику, то такого раздела в немецкой книге просто не было.
В детстве мне доводилось читать книги о фотографии, написанные по немецкой системе – теория, еще раз теория и чуть-чуть практики. Сейчас хочется почитать что-то из американской системы :)
Неделю назад в рубрике “Знакомство с фотомастером” были представлены швейцарские пейзажи Дмитрия Кузнецова. А сегодня отечественный симметричный ответ ;) от Константина Хорошилова.
Это далеко не все классные снимки Константина Хорошилова, которые я бы хотел показать. Поэтому рекомендую посмотреть его фотографии на photosight или photoline.
А желающим самому побродить по Алтаю есть смысл посетить сайт pohodnik.info.
