Вариант оценки потенциального работодателя для ITшника на этапе собеседований.

Интересный вариант оценки IT компании вычитал на RSDNe. Кое-что субъективно, но есть здравые мысли:

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

Итак, начнём с собеседования с hr-менеджером

— с вами пытается торговаться о зарплате HR-менеджер и/или первым делом пытаются выяснить "минимальную сумму, за которую Вы согласны работать"

Сразу отметаем подобные организации. Дело в том что организация может искать человека с целью 1) закрыть вакансию 2) найти человека, который будет реально помогать делать продукт. В чём же отличие, спросит пытливый читатель? А отличие в том, что первый вариант предполагает менеджмент уровня "получить деньги на старт/продолжение проекта и набрать 'ресурс' за минимальный бюджет", в то время как второй вариант предполагает менеджмент уровня "собрать сильную команду на годы, для успешного создания и развития продукта". В результате разница разительная. В первом случае получается команда в среднем слабо компетентных разработчиков, просиживающих большую часть рабочего дня за интернетами, чаепитиями либо беседами "за жизнь". При этом над ними с кислыми минами и претензиями как коршуны вьются менеджеры проектов, которые являются в таких организациях first-class citizens. Что в принципе обосновано, т.к. вся работа по обеспечению притока капитала лежит на менеджерах. Во втором случае получается команда сильных профессионалов, которые большую часть рабочего времени делают продукт, обеспечивают качество продукта, и связь между притоком капитала и качеством продукта самая непосредственная. В этом случае именно инженеры являются first-class citizens. Подытоживая — во всех организациях, о которых я могу сказать что они ищут людей по схеме №2, вопрос о зарплате задавался после всех собеседований.

Вариант №1 практически всегда (пресловутые 95%) встречается у "интеграторов", "аутсорсеров", "стартапов", а также примерно в половине случаев она встречается у продуктовых компаний, причём чем крупнее компания — тем вероятность выше.Вариант №2 в 95% случаев встречается у небольших компаний со штатом инженеров в пределах дюжины, имеющих свой продукт который приносит стабильный доход.
— hr-менеджер даёт вам "психологические тесты"hr-менеджер действительно может оценивать кандидата в плане психологии, являясь фильтром для очевидно неадекватных кандидатов, однако тесты это уход hr-менеджера от ответственности в принятии решения, а так как работа hr-менеджера есть отражение менеджмента в целом, готовьтесь к тому что в организации весь менеджмент избегает ответственности любыми доступными средствами


Собеседование с техническим менеджментом ( тимлид/техдир )— в качестве системы контроля версий используется git ( исключение — open-source проекты )это может показаться забавным, но именно этот пункт является ярким индикатором незрелости/неадекватности команды инженеров. Дело в том что идеальной для подавляющего числа организаций является централизованная vcs, в частности svn ( в купе с vpn-доступом). Так как распределённая vcs вносит дополнительный уровень сложности, а количество инструментов для работы с тем же svn в разы больше чем для работы с другими vcs, то должна быть очень веская инженерная причина для использования git/mercurial/etc. Если вы поинтересуетесь причиной и вам в ответ скажут что-то пространное ( вроде "в git легко делать бранчи" либо "весь мир давно перешёл на git", "в git можно коммитить локально" ), то с вероятностью 95% вы имеете дело с молодой порослью — читателями ксакеп.ру, хабрахабр, лор, которые далеки от инженерии как Линус от балета.
— вам дают тесты на техническом собеседовании или "тестовое задание" на домздесь одно из двух, либо вы — молодой, подающий надежды специалист, которого не о чем спросить кроме как о виртуальных деструкторах, либо собеседующий вас — некомпетентен и опять же ( как в случае с hr ) избегает ответственности в принятии решений. Человека с опытом можно распознать в простой беседе о двух вещах: 1) зашипленных проектах и его роли в них 2) беседой о том как бы человек решил инженерную задачу ( реально существующую в компании или выдуманную — не суть ). В рассказе по этим двум пунктам важно услышать всё — и собранные требования и выбранные инструменты и примерный дизайн решения. Предложение же сделать домашнее тестовое задание — это моветон в чистом виде. Максимум что от вас могут попросить вменяемые технари — это пример кода.

Поле боя— у разработчиков один мониторБез комментариев. Просто бегите.
— рабочее место сильно ограничено по площадиЛюди цепляются локтями/спинками кресел? Вам здесь не рады."

Обзор: Don’t Overwhelm Yourself Trying to Learn Too Much

"Don’t Overwhelm Yourself Trying to Learn Too Much". В трех словах: "Нельзя объять необъятное". В данном случае — в приложении к самообучению программистов. Держать себя в тонусе конечно нужно, но если наброситься на все новости, инструменты, языки, методики, то специалистом все равно во всех областях не станешь, а сил и времени не вернешь. Походу к этим мыслям приходят со временем все. И Козьма Прутков тоже был не первым.

Обзор: What Makes a Good Check-in?

В статье "What Makes a Good Check-in?", как ни странно, обсуждается не Forsquare, а SVN. Потому я бы назвал статью в "What Makes a Good Submit?", но что есть, то есть. В статье рассуждается про пользу систем контроля версий, про то, как должен оформляться сабмит для того, чтобы нести реальную пользу для его автора и всех последующих пользователей. В общем, ничего особо нового, но освежить знания и понимание необходимости правильных самитов помогает.

Рабочее соглашение для фрилансера

Наткнулся на Work Agreement, предложенное одним из фрилансеров для использования его в качестве предварительной договоренности с работодателями на Odesk. Как по мне — неплохая "рыба", которую можно отсылать перед началом сотрудничества.
Решил сохранить у себя:

Work agreement

0.Preamble:   Please read this agreement carefully. This will help you make a decision about my hiring and will give some understanding of ​​the workflow. This agreement applies to hourly jobs. 1.Workflow:   Most projects consist of the following stages:      1.1. Interview:        It's time for acquaintance and general discussion about the project. You can ask me any questions and give a small tests to confirm my skills. I will ask you general questions about the project to understand what it is and what can I do. If all goes well, this step ends my hiring.      1.2. Requirements and large design:        The objectives of this step is clarification of requirements, creating and approving of the statements of work (problem). And then building a comprehension of ​​what should be the result of this work (solution). At this step we will discuss in detail: the functional requirements ("what and how it should do"), the user interface ("look and feel"), the internal architecture ("what be inside") etc. This step not will be included in the time track (i.e., it is free). But it is a significant part of the work so it will be make only after you hire me (I want to be sure that you are serious about the project).      1.3. Development:        It's the longest step. Here I will do small design, coding and test your solution. Usually this step induce a small amount of questions so we will do not communicate very often. I highly recommend watch my work diary and notify me immediately if you find any problems or you have any questions or any suggestions, it's will save our time. Upon completion this step you will get a turnkey solution for testing.      1.4. Integration and testing:        Here you will make test of turnkey solution, and make conclusions about suitability or about necessity do some changes (that will take us back to 1.2). If you satisfied we close this contract.      1.5. Maintenance:        If after ends contract you will have any questions or you found a bug, you can contact me and get help. 2.Warranty:   2.1. Money back:          You can get your money back within the first week after start the contract.      2.2. Maintenance:          After completion of the contact you get a free 1 month (2 months for regular customers) of maintenance. 3.Regular customers:   I really appreciate regular customers, so if you back within next 3 months after ends contract you will get additional bonuses:      3.1. 15% discount.      3.2. Additional month of maintenance. 4.Additionally:   By the accumulation of experience I will be change this agreement, but it has no effect on current customers.

Обзор: Vim for people who think things like Vim are weird and hard

Статья "Vim для тех, кто думает, что Vim уродлив и непонятен" (Vim for people who think things like Vim are weird and hard).

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

• diw is delete inside word.
• cat is change around tags.
• f> is go forward to a closing chevron (>).
• vi" is visualise inside quotes (").

Интересное замечание, которое может значительно помочь в освоении программы.