Два вида мотивации сотрудников

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

Лично я с этим мнением категорически не согласен и считаю что сотрудник, в первую очередь, должен хотеть работать за деньги и за другие материальные ништяки. Такая позиция часто удивляет или настораживает HR, и когда на собеседовании говоришь в лоб о том, что работаешь “исключительно за деньги” они как-то странно на тебя смотрят. А зря и вот почему.
Continue reading

Remote: офис не обязателен

На днях дочитал крайне интересную книгу “Remote: офис не обязателен” от создателей небезызвестной компании 37signals (да, те самые авторы RoR). Меня давно интересует все что связанно с удаленной/частично удаленной работой, т.к. ходить в офис совсем невмоготу становится, так что книга оказалась более чем к месту и ко времени.

До прочтения Remote, мне и самому не раз приходила в голову мысль о том, что полноценно работать в офисе, особенно если это OpenSpace не возможно в принципе, т.к. там постоянно кто-то отвлекает: обсуждает прокачку танка в WoT, рыбалку, политику, да что угодно кроме работы! Хотя чем лучше обсуждение стороннего проекта у тебя под носом? В итоге, если понаблюдать за тем, как тратится время сотрудником в офисе, становится заметно что на выполнение полезной работы расходуется хорошо если 50% рабочего времени. А если сюда еще добавить кучу крайне важных и неимоверно “полезных” совещаний…
Continue reading

Собеседование как…

Думаю, ни для кого не секрет, как проходит большинство собеседований. Унылый, иногда испуганный, крайне редко уверенный в себе кандидат в сотый раз слышит порядком надоедший ему вопрос: ”Расскажите, что вы делали на прошлом месте работы?” Скучающий интервьюер (не скучать сложно, т.к. рассказчики из большинства программистов посредственные) пытается выдрать кусочки информации из этого рассказа и хоть как-то оценить полезность кандидата для проекта, что дается ему крайне нелегко.

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

Как выбрать язык программирования для нового проекта

На данный момент я кажется окончательно вывел для себя правила по выбору языка для той или иной задачи. До этого многие годы писал на C++, C, Python, Java и Objective-C. Перепробовал кучу экзотических языков, таких как OCaml, Erlang, Scala, Lisp, Clojure. Так как я не занимаюсь разработкой UI, Web-сайтов или мобильных приложений, все мои соображения актуальны исключительно для разработки системных приложений, сетевых приложений и бизнес логики. Кроме того, все что я пишу в этой заметке относится к командной разработке приложений в рамках относительно крупной компании, и будет не актуально для команд из 1-2 разработчиков или “домашних” проектов. Continue reading

Вакансии в Mac команде ЛК

У нас, в Mac команде ЛК появилась одна вакансия (работа в офисе в Мск, есть программа релокации). Условия, как всегда, отменные, коллектив прекрасный, офис замечательный и даже бассейн есть (2 минуты пешком)

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

Что самое важное, на вакансию “C++ разработчик (логика)” мы готовы рассматривать не только C++ разработчиков с опытом программирования под OSX, но и просто сильных *NIX разработчиков (BSD – предпочтительно, Linux – тоже не плохо), которых однозначно хотят перейти на OSX и готовы инвестировать в это некоторые усилия.

Со второй вакансий все проще – разыскиваются Objective-C разработчики имеющие некоторое представление о C/C++ (нулевое знание плюсов не пойдет однозначно).

C++ разработчик (логика)

Основные функции и задачи:

  • Создание программных решений в составе команды разработчиков;
  • Анализ исходных требований, уточнение поставленных задач;
  • Разработка оптимальных решений, оценка трудоемкости задач;
  • Участие в подготовке проектной и технической документацию по порученным задачам.

Позиция предполагает работы по:

  • портированию существующих Windows-компонент на Mac (включая и последующую отладку портированного кода);
  • реализации Mac-специфических компонент и сервисов (включая драйвера);
  • интеграции компонент в общий продукт.

Требования к кандидату:

Обязательно:

  • Отличное знание C и C++;
  • Отличное знание библиотек STL и BOOST;
  • Знание платформы Mac OS X ИЛИ обширный опыт разработки под *NIX системы (FreeBSD, Linux, etc.) и желание перейти в разработку под Mac OS X;
  • Знание инструментальных средств разработки под *NIX, таких как GDB, Make, CMake;
  • Знание Sh, стандартных консольных *NIX приложений и какого-либо скриптового языка (предпочтительно Python);
  • Опыт работы с логами и крэш-дампами;
  • Опыт разработки мультиплатформенных систем (Windows, UNIX).

Желательно:

  • Понимание принципов и опыт разработки многоуровневых клиент-серверных приложений;
  • Знание и опыт использования межпроцессных взаимодействий;
  • Понимание принципов основных сетевых протоколов (как минимум TCP/IP);
  • Опыт портирования приложений с Win32 и UNIX.

C++ разработчик (UI)

Основные функции и задачи:

  • Создание программных решений в составе команды разработчиков;
  • Анализ исходных требований, уточнение поставленных задач;
  • Разработка оптимальных решений, оценка трудоемкости задач;
  • Участие в подготовке проектной и технической документацию по порученным задачам.

Позиция предполагает работы по:

  • портированию существующих Windows-компонент на Mac (включая и последующую отладку портированного кода);
  • реализации Mac-специфических компонент и сервисов;
  • реализации Mac-специфического GUI;
  • интеграции компонент в общий продукт.

Требования к кандидату:

Обязательно:

  • Отличное знание Objective-C, опыт разработки на C/C++;
  • Опыт создания GUI с использованием Cocoa, знание STL и BOOST;
  • Знание платформы Mac OS X;
  • Знание инструментальных средств разработки под Mac OS X;
  • Опыт работы с логами и крэш-дампами.

Желательно:

  • Понимание принципов и опыт разработки многоуровневых клиент-серверных приложений;
  • Знание и опыт использования межпроцессных взаимодействий;
  • Опыт разработки мультиплатформенных систем (Windows, UNIX);
  • Опыт портирования приложений с Win32 и UNIX.

Писать можно мне на e-mail. Если не интересно самим, поделитесь с теми, кому может быть интересно. Заранее спасибо!

Я бы в камне высек и каждому разработчику на стол поставил…

НИКОГДА не пиши промышленной код на экзотическом и/или слабо распространенном, в компании где ты работаешь, языке программирования. Например на Perl/Haskell/Clojure или еще какой-то давно/недавно выученной тобой хреновине.

Ушел в “завязку”

Времени катастрофически ни на что не хватает, а на ближайший год очень серьезные планы. Одним из главных бессмысленных пожирателей свободного времени, до вчерашнего дня был РСДН, всё остальное давно “похерил”.
Поразмыслив на тему планирования времени, временно ушел оттуда, самозабанившись на 1 год. Жалко, конечно, но реально нужно достать еще свободного времени.

Слегка разочаровался в Scala

Когда-то, довольно давно, я взялся за поиск альтернативы для C++, который во все времена был и, как мне думается на данный момент, будет моим основным рабочим инструментом. Само собой, эта альтернатива мне была нужна не для того, что бы перейти в какую-то иную сферу, а для тех случаев, когда либо хочется написать что-то свое, либо нужно быстро создать какой-то прототип, проверить ту или иную концепцию. В такой ситуации JVM-based язык очень удобен и, по большому счету, безальтернативен, конкуренцию может составить разве что Python со своим простым синтаксисом и безграничным набором библиотек. Continue reading

Насколько полезно знание внутреннего устройства iOS

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

Я прочитал эти темы, созданные Вами:
http://www.rsdn.ru/forum/apple.os/4951747.flat
http://www.rsdn.ru/forum/apple.os/4336664.1
1) Хочу спросить у Вас, полезно ли вообще среднестатистическому программисту iOS знать все эти вещи про устройство ядра? Я никогда не видел вакансий системного iOS-программиста (может потому, что живу в Минске =) ). Большинство вакансий связаны с вэбом, GUI или играми.

Знание внутреннего устройства среднестатистическому iOS разработчику совершенно бесполезно. Вакансий системного iOS-программиста нигде, кроме как в Купертино нет и, скорей всего, не будет, так как на не разлоченом iOS устройстве установить что-либо системное не представляется возможным, а разлоченых устройств не так уж и много.
Единственный плюс в понимании внутреннего устройства iOS в том, что сама iOS ничто иное как урезанная OSX, так что если ты имеешь представление об одной системе, то эти знания помогут и со второй. Только тут возникает еще одно “но” – вакансий для системного разработчика OSX тоже по пальцам пересчитать можно, в той же Мск люди с таким знанием нужны в паре-тройке компаний. Удаленной работы по данному направлению лично я найти не смог.

 2) Я как-то встречал такое мнение, что “и Линукс и Мак являются Юникс-системами (POSIX). С одного на другой [имеется в виду программирование] перейти несложно”. Насколько это верно?

Отчасти верно. Обе системы – UNIX-like системы, но при этом внутреннее устройство Darwin (ядро Mac OS X) и Linux кардинально различаются. Хотя, в Darwin много общего с BSD системами. Если говорить точнее, схоже все кроме управления памятью, процессами и потоками.
Так что, перейти с Mac OS X на Linux, если заниматься не ядром, а низкоуровневыми сервисами довольно легко, правда аналогичный переход с Windows на Linux, при условии что на Windows занимался низкоуровневыми вещами не на много более сложен.

Тестовые задания в Яндексе. Часть 2.

Как и планировал, опробовал второй способ сортировки, а именно сортировку подсчетом. Кода в разы меньше, сам код куда проще, но… Крайне плохо масштабируемое решение с сильной зависимостью от количества доступной памяти. Так при использовании максимального количества доступной памяти в 256 Мб, приходится делать 64 прохода по файлу. Если же попытаться разнести чтение и запись (как я писал раньше, асинхронная запись дает ускорение приблизительно в 10-15%) то количество проходов вырастает до 128 и итоговая скорость оказывается даже меньше чем при последовательной обработке. Так же, мое решение не будет корректно работать в том случае, если количество одинаковых элементов превысит максимальное значение помещающееся в size_t.
Тем не менее, сортирует довольно быстро: 1 Гб, в среднем, обрабатывается за 108 секунд.

P.S. а вообще, я выдохся с данной задачкой (как делать ясно, побочные эффекты алгоритмов тоже очевидны), так что вернусь ней… через еще пару лет?