Как стать автором
Обновить

Разработчик! Прекрати считать себя недостаточно хорошим специалистом, это неправда

Время на прочтение 7 мин
Количество просмотров 62K
Всего голосов 74: ↑66 и ↓8 +58
Комментарии 184

Комментарии 184

Все описание слишком правда, слишком… и от этого становится грусновато, но зато как-то более менее объяснимо.
Недооценивать себя — это плохо.
Но когда на позицию мидла приходят с резюме сеньора и знаниями джуна — это тоже не ок.
По моему личному опыту на 5 собеседуемых — 4 себя переоценивают.
Если Вам за себя стыдно — Вы себя не любите!
Если Вам за себя не стыдно — Вы плохо себя знаете.

Так и пожалуйста — пусть переоценивают. Обстоятельства все расставят на свои места. А вот робкий и недооценивающий себя просто не попадет в обстоятельства.

Во фронте все кругом сеньоры, а на вопрос про то, что такое SOLID никто ответить не может :(

''Сплошной', конечно же

SOLID — это культ карго от мира программистов.
Как по мне, так SOLID — это великолепный и удобный набора принципов проектирования. Слепо ему следовать конечно же не стоит, но отклонения стоит очень хорошо обосновывать. Многие отклонения в любом случае будут лютейшим говнокодом, например любое нарушение SRP.
А я вижу в нем набор букв, который бесполезен, если ты заранее не знаешь как делать. Стаким же успехом момжно ввести принципе «Не быдлокодь!». А что, он куда более универсален. Зачем нам dry, solid, kiss, если он уже все это в себя включает?

А загвоздка в том, что правила solid сформулированы весьма абстрактно. И потому без практического опыта их применения они бесполезны и даже вредны (если закрутить гайки и следовать написанному в абсолюте, проект становится фрагментированным, нечитабельным и никогда не заканчивается).
А я вижу в нем набор букв, который бесполезен, если ты заранее не знаешь как делать.

Заранее можно знать, если у тебя есть какой-то опыт. У этого набора букв есть значение. Есть множество книг, которые объясняют что и как, причём с примерами. А сама аббревиатура, это больше запоминалка что ли.
Это довольно очевидно, что просто прочитав расшифровку, сколь бы то ни было эффективно применять вы этот набор принципов не научитесь. Нужно читать книги, общаться с другими разработчиками, практиковаться и т.п. И да, на этом пути будет куча ошибок. Но ведь есть менторство, допустим, есть позиции начинающих разработчиков. Так что я считаю, что лучше пытаться применять лучшие практики с самого начала, чем вообще не обращать на них внимания и не знать о существовании. А то потом у людей с десятилетним стажем наступает прозрение вроде: «Оу, а это уже унифицировано и так нужно делать, да?».

Стаким же успехом момжно ввести принципе «Не быдлокодь!». А что, он куда более универсален. Зачем нам dry, solid, kiss, если он уже все это в себя включает?

Очень странно, что приходится это объяснять, но «Не быдлокодь!» — это абстракное высказывание, которое не подразумевает конкретного набора практик и т.п. К тому же ещё и понятие строго не детерминировано. Т.е. абсолютно бесполезное наставление. А вот всякие там dry, kiss, yagni, solid и т.д. подразумевают набор вполне конкретных практик.

А загвоздка в том, что правила solid сформулированы весьма абстрактно.

Да, опыт практического применения важен, и без него никак. Но я бы не сказал, что все правила SOLID сформулированы абстрактно. Наверно всё, кроме Open/Closed сформулировано очень даже конкретно. Да и то, потому что стабильность API — дискуссионная тема.
Возьмём хотя бы SRP: "The single responsibility principles is a computer programming principle that states that every module or class should have responsibility over a single part of the functionality provided by the software, and that responsibility should be entirely encapsulated by the class.". Что тут абстрактного-то? Конечно всегда есть простор для фантазии, но как по мне, так вполне себе конкретно.

И потому без практического опыта их применения они бесполезны и даже вредны (если закрутить гайки и следовать написанному в абсолюте, проект становится фрагментированным, нечитабельным и никогда не заканчивается).

Хотелось бы увидеть примеры, если это возможно.
Заранее можно знать, если у тебя есть какой-то опыт. У этого набора букв есть значение. Есть множество книг, которые объясняют что и как, причём с примерами. А сама аббревиатура, это больше запоминалка что ли.
Тут такая вещь. Ее видят не как запоминалку, а как центр мироздания и откровение с небес. Соответственно, если ты класть хотел на красивые аббривеатуры, то ты другой религии и предан анафеме.
Т.е. важно не умение применять эти принципы, а умение помнить аббривеатуру.

Очень странно, что приходится это объяснять, но «Не быдлокодь!» — это абстракное высказывание, которое не подразумевает конкретного набора практик и т.п.
Как в некоторой степени и SOLID. Просто уровень абстракции разный.

А вот всякие там dry, kiss, yagni, solid и т.д. подразумевают набор вполне конкретных практик.
Я мог бы согласиться с dry. Но даже тот же kiss требует дополнительных разъяснений и опыта. С одной стороны, вот что такого сложного в том, чтобы все упростить? А с другой, просто это как? Фрагментировать приложение на крохотные модули, от которых черех минуту начинает рябить в глазах потому что их слишком много? Но они простые, да. И разобраться в них можно тоже просто. Только если надо сделать более-менее значимое изменение коммит получится файлов на 100 (автор применяет прием гипербола, не пытайтесь повторить в домашних условиях).

Что тут абстрактного-то? Конечно всегда есть простор для фантазии, но как по мне, так вполне себе конкретно.
Думаю, вполне можно найти людей, которые скажут «вот у этого класса единственная задача — обслуживать REST API». И вкатают туда и логику, и работу с базой и еще Гейтс знает что. Чо, апи ж надо. Да, это опять гипербола. Все-таки реальные примеры будут куда тоньше.
Много раз проводил собеседования, спрашивал и про SOLID в том числе. Спрашивал не для того, чтобы «завалить» на этом, а чтобы понять, насколько интересуется теорией человек. Нанимали несколько раз ребят, которые отвечали на часть вопросов только, но имели большое желание работать. Но в итоге их увольняли через несколько месяцев, т.к. за ними приходилось все переделывать. Простые сайты они то без проблем сделают и пофиксят какие-то мелкие ошибки. Но вот разработку, где нужно все продумать заранее, сделать абстрактные классы (чтобы 10 раз одно и то же не писать и ограничить возможности ошибок) они не могли.

Самая ГЛАВНАЯ проблема с ними в том, что без использования этих правил/принципов они писали код, который попросту нормально не работал — куча ошибок и непродуманных ситуаций. Причем в этой компании бизнесу без разницы какие они клевые, а главное, чтобы задача была выполнена и работала. Но частые ошибки приводили к возврату задач, а далее топы увольняли их, и потом мы переписывали все сами.

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

Все эти теоретические знания, шаблоны, принципы не просто так придумываются, а для решения многих проблем разработки. И если человек этого не знает, он будет вновь и вновь сам для себя их открывать по мере развития.
Я думаю все-таки надо сделать акцент на основу моей мысли: SOLID это одно из тысячи имен дьявола. Но при этом там, где хотят умение пользоваться правилами, почему-то хотят услышать именно название, а не его суть.

Ну а остальное это анекдот. Его, увы, за правило нельзя принять.
Вообще это показывает как минимум что человек темой интересовался.
Просто этот знающий SOLID, знает И ЕГО в том числе. А не знающие не знали и остального. :)
Никакой корелляции вообще-то нет.
А тут и не про корреляцию.
Вот как раз про нее родимую. Корелляция звучит так: знание SOLID — знает как писать. Не знает SOLID — не знает как писать.

Корелляции нет.
Да нет же. Речь идёт про ОДНОГО человека, который знал SOLID и оказался специалистом. А знал он SOLID, вероятнее всего, в комплекте со всем остальным. А другие кандидаты не знали не только SOLID, но и всего остального. Вот и всё.
А… Тогда я тупая вафелька.
Всегда писал по принципам SOLID и только недавно, пройдя курс по C++, узнал, что это называется SOLID. Знание «теории» НИЧЕГО не говорит о квалификации программиста, если эти принципы уже «в крови», в навыках. Смотрите на код, тесты и т.п.
Это набор метрик, которые не должны использоваться как принципы проектирования.

Я согласен, что эти принципы проектирования можно частично рассматривать как метрики качества кода. Т.е. приложение, спроектированное с учётом этих принципов обладает определённым качеством. Но почему вы решили, что это только метрики?

Потому что невозможно строить ООП модель, думая: Куда бы положить эту функцию? А не много ли я функций положил в этот объект? Ах тут еще одна функция появилась, куда бы ее приткнуть, чтобы не нарушить solid? Solid это очередной пересказ истории про coupling и cohesion. Только у него бОльшие амбиции благодаря маркетинговому шиту от Дяди Боба. Я уже про это писал, посмотрите у меня в комментариях, если интересна противоположная тз.
Потому что невозможно строить ООП модель, думая: ...

Почему вы так считаете? Можете ли привести примеры, когда SOLID явно мешает проектированию модели? Или всё что вы написали — это только ваше личное мнение?
Я бы даже сказал, что этот набор принципов даже помогает строить хорошо декомпозированную модель, хотя бы за счёт SRP. Ну и за счёт остальных принципов простота поддержки и расширяемости только улучшится.

Solid это очередной пересказ истории про coupling и cohesion

Вообще, про это ну от силы три из принципов SOLID. Но опять же, никто не мешает вам воспринимать эти вещи, как взаимодополняющие.

Только у него бОльшие амбиции благодаря маркетинговому шиту от Дяди Боба. Я уже про это писал, посмотрите у меня в комментариях, если интересна противоположная тз.

Ну вы хоть ссылку дайте, не буду же я ради этого все ваши комментарии пролистывать…
Можете ли привести примеры, когда SOLID явно мешает проектированию модели?
По-моему вам явно написали, что он не помогает это сделать, а не мешает. Я так уверен, если применить несколько других инструментов, можно и размахивая СОЛИДолом что-то наварганить. Только зачем вам СОЛИДол, если есть другие инструменты?
Не, выше в комментарии не то, что мешает сказано, а делает невозможным. Как по мне, то в худшем случае SOLID именно не помогает построить хорошую объектную модель.
Наверное потому, что принципы, описанные в SOLID и так очевидны любому разработчику с опытом и головой и заучивать чьи-то спасибо-кэп-ные формулировки никому особо не нужно.
Чет отличается SOLID от KISS?
Первый второму прямо противоречит
Когда я вижу, что собеседование ведёт неадекватный человек и валит меня ради того, чтобы завалить, я валю его в ответ. На каждый тупой вопрос с его стороны у меня найдётся ещё более тупой контрвопрос. Да, на работу меня уже в эту контору не возьмут, но и слава богу.
Я бы в такой ситуации просто завершил бы собеседование. Зачем тратить свое и чужое время?

PS Было у меня как-то забавное собеседование, не знаю толи меня завлить пытались, толи просто собеседующий тупил (имхо, этот вариант был более вероятен). В общем, спросили у меня алгоритмическую сложность поиска элемента в двоичном дереве. Я ответил, что логарифмическая, собеседующий же спросил основание логарифма. Я попытался объяснить, что основание логарифма в данном случае роли не играет, т.к. дает просто мультипликативную константу. На что мне начали рассказывать, что это очень важно, даже приводили какие-то лютые примеры типа вот мы увеличили входные данные в 10 раз, значит время работы увеличится в log_2(10) раз. В итоге, когда меня позвали на второй этап я тупо отказался. В общем, к чему я это всё — собеседование процесс обоюдоострый — не только работодатель оценивает работника, но и работник оценивает работодателя.

Такое поведение контр-продуктивно, но иногда позволяет сохранить нервную систему когда потратил много сил на дорогу, например.(я про кейс выше а не про ваш)

Зачем тратить свое и чужое время?

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

Может я «Робин Гуд» или, наоборот, моральный урод — какая тепереча разница, когда я потратил время на то, что как-то готовился к собеседованию, в том числе морально, приехал, нервничал, всё такое… а вместо ожидаемого адекватного обсуждения меня встречает неадекват. Ну чёрт с ним, потрачу ещё час, но дам сдачи.

Кстати, как бы ни было удивительно (хотя, я наоборот считаю, что это логично), на все работы, куда меня брали легко и непринуждённо, — были такие же и собеседования без занудства и идиотских вопросов, скорее в формате неформального трёпа о жизни и IT.
были такие же и собеседования без занудства и идиотских вопросов, скорее в формате неформального трёпа о жизни и IT.
Это лучшие компании! :)

Точно также нанимался сам и осуществлял найм.
Успешность диалога не просто неудивительна, она очевидна(должна быть).


На мой взгляд, самое ценное в соискателе — его опыт: послушать про косяки, интересы, технологии, рассказать о компании, о команде, сформулировать задачи из реального опыта и требований к вакансии.


Самое интересное (думаю, большинство согласится), что даже уровень оклада становится менее принципиальным вопросом, если собеседование действительно к себе располагает.


Встречи по 40 минут с задачками из интернета кажутся какой-то шуткой, ведь самое худшее в задачках то, что при желании их можно выучить наизусть, делая их полностью бесполезными для отсеивания плохих программистов, но заставляя отсеивать хороших, а 10-15 минут "обсудить детали" ну никак не может хватить для создания обоюдного, здорового впечатления о работе.

На что мне начали рассказывать, что это очень важно, даже приводили какие-то лютые примеры типа вот мы увеличили входные данные в 10 раз, значит время работы увеличится в log_2(10) раз.
Тоже неоднократно сталкивался с подобным бредом. Это справочный материал, нас учили где и как это можно найти. Если занимаешься подобным ежедневно, то — да: ты это помнишь, ценишь и знаешь разницу log2(n) и ln(n). А так всегда можно подсмотреть за 2-3 мин в википедии.

Но кому-то возможно такое собеседование подходит: либо хорошо запоминают, либо сразу занижают требования и нанимаются на позицию джуна, где требования ниже, а потом растут до сеньора по результатам работы без дурацких собеседований. У нас так несколько джунов получили работу в компании, куда я пяток раз не смог попасть на должность сеньора. :) Но гордость и уверенность в себе не позволяла снижать планку ни по уровню проекта ни по зп, потому эту компанию и ей подобные послал давно далеко и на долго.
Если занимаешься подобным ежедневно, то — да: ты это помнишь, ценишь и знаешь разницу log2(n) и ln(n).
В том-то и дело, что тут разницы нет. Когда говорят логарифмическая сложность алгоритма то имеют ввиду, что время работы алгоритма равно O(ln(n)). А O(ln(n)) = O(log_a(n)) при любом положительном a не равном 1. Отсюда и получаем, что в данном случае основание лографма роли не играет. Так что это не справочный материал, это не понимание человеком сложности алгоритма.
Скорее это непонимание человеком что есть логарифм :)
Гораздо больше времени потрачено на дорогу и подготовку к собеседованию, почему бы не развлечься в данном случае по крайней мере? Заодно и на реакцию посмотреть.
А вот на следующий этап время тратить уже точно смысла нет.
Ну если вас такие вещи действительно развлекают, то почему бы и нет. Только потом не обижаетесь, что кто-то развлекался уже на вас.
Может быть это в вас проблема, если вы не можете убедить человека, что O(N) обозначает относительную сложность?
Не относительная, а асимптотическая. И убеждать в ней не надо, это определение, его либо знаешь, либо не знаешь. Но в любом случае — собеседование это не то место на котором собеседуемый обучает собеседующего в базовых вещах. А это чертовски базовая вещь в алгоритмике.

ИМХО если человек спросил более точную оценку О() то нет необходимости объяснять ему как соотносятся логарифмы с разными основаниями.

Что значит более точная оценка О()? Я не озвучивал никаких оценок, я озвучил асимптотическую сложность. В любом случае я не видел и до сих пор не вижу причин давать бессмысленный ответ на бессмысленный вопрос.

Это значит более широкий класс функций под О(), например включить менее бастрорастущие множители или константы входящие в оценку сложности. Могу сильно ошибиться (не смог сейчас нигде найти это) но в вашем случае точнее это — "пол" log2(n), причём аргумент логарифма тоже можно усилить. Имхо не стоит гнать на интервьюера, его вопрос не технический а скорее на кругозор или даже культуру программиста.

НЛО прилетело и опубликовало эту надпись здесь

Ну я вроде это и написал) только не соглашусь про безграмотность. О() нотация позволяет "ограничиться" самым быстрорастущим множителем (и константное слогаемое идёт первым на вылет), но интервьюер попросил уточнить и там есть что уточнять.

Нечего там уточнять, в О-нотации не пишут мультипликативный множитель. Уточнять основание логарифма — это безграмотность, если вы этого не понимаете, то вы просто не понимаете О-нотации.
Ну вот, например, возьми два цикла, каждый проходит по массиву, то есть сложность алгоритма O(n). Вам же хотят сказать и тут, и возможно, интервьюер тоже, что вопрос был в том, как вы вычислили O(n). На что ожидаемый ответ такой —
O(n) — это сложность каждого for, а так как тут 2 раза, то O(2n), но константу отбрасываем, поэтому O(n).
Это как в школе на уроке математики — просто ответа не достаточно, интересен путь, каким вы получили этот ответ.
Если интервьюер хочет спросить почему именно такая сложность, то пусть спрашивает «почему именно такая сложность». Ну и если вы прочтёте мой изначальный комментарий целиком, то увидете пример неправильного вычисления увеличения времени работы алгоритма при увеличении данных, что говорит либо о непонимании человеком алгоритмической сложности, либо о неумении выполнять операции над логарифмами.

И да, O(n) + O(n) = O(n) без всяких дополнительных шагов в виде O(2n). Необходимость вводить O(2n) — это как раз неумение оперировать O-нотацией напрямую. Все равно что писать 2 + 2 = 4 + 0 = 4.
Все равно что писать 2 + 2 = 4 + 0 = 4.
Как-то у вас сразу получилось.
Разве не так будет:
2 + 2 = 2 + (1 + 1) = (2 + 1) + 1 = 3 + 1 = 4?
Вы не понимаете О-нотацию, ибо O(log2(n)) = O(ln(n)). Вне зависимости от основания логарифма — это одно и то же.

Тут скорее непонимание логарифма, ведь можно перейти от основания к основанию путем добавления вполне константного множителя.

Время проведенное с удовольствием не считается потраченным.

У меня как-то раз был спор на собеседовании, где я быстро понял, что мне сбивают цену. Я проявил упрямство, попросил дать ноутбук чтобы продемонстрировать что я прав (если не ошибаюсь, про инлайнинг и RVO спорили). На что директор начал психовать, мол что вы тут за цирк устраиваете и т.п. Пришлось в лоб сказать, что если враньё начинается уже на собеседовании, то работать я сюда не пойду. После чего ушёл. Через пару месяцев, когда я уже успешно работал в другой фирме мне позвонили эти ребята и сделали оффер. От которого я конечно же отказался. Оффер к тому же был на 50% серый.

Давно бы сделали платный сервис, который генерирует CV для умеющих писать Hello world на нужном языке и прочие красивые слова, которые помогают устроиться на низшую должность в компанию из которой можно расти. Т.к. всегда устроиться на работу или поступить на учёбу сложнее, чем дальше работать/учиться.
Генератор CV на основе исходников :)
Только локально, скармливаете утилите папку с разнородными проектами, а она вам выдаёт CV с описанием того, насколько изощрённые подходы вы умеете использовать в работе.
Заодно, прогоняет статический анализ кода, вычисляя качество кода в вакууме :)
Воу-воу, тянет на идею для стартапа)
Не могу найти сейчас ссылку на сервис. Но как то раз наткнулся на подобный сервис (свой ник загуглил) генерирующий что-то в стиле CV на основе github аккаунта.
В расчет видимо шли использованные в репозиториях языки, что-то более конкретное уже не помню.
На основе акка на гитхабе делать неверно.
У меня, например, на гитхабе только питонячий скрипт для бэкапа серваков, а занимаюсь я разработкой под андроид.
Бейте HR их же оружием.

Вполне возможно, что это был getcoder.io. Только почему-то их сайт больше не открывается, хотя они мне как-то писали. http://www.innopolis.com/business/residents/getcode/

Если судить по страницам из гуглкеша, то не оно.
На том сервисе текста-воды (на удивление он мне тогда осмысленным показался) было на 1-1.5 экрана. Довольно забавно было, что в то время я практически не разбирался в гите и залил в один репозиторий консольной утилиты на 5 строк (в буквальном смысле) исходники ru.wikipedia.org/wiki/Tiny_C_Compiler и в итоге большая часть текста описывала какой я крутой с разработчик.

На getcode (опять же судя по страницам из кеша) просто перечисление проектов.

есть такая штука уже для github

Скажите пожалуйста, а вы только с разработчиками имеете дело?
Или вот, например, я — SAP Basis Administrator.

Разработчиком тоже был. Но как то не срослось.
НЛО прилетело и опубликовало эту надпись здесь
Наши Hiring турниры — дело сугубо добровольное и проводятся скорее для того, чтобы в режиме реального времени дать ответы на все интересующие вопросы. На любые наши позиции можно устроиться удаленно, никаких ограничений и «золотых» вакансий для турниров не было. Дело исключительно в консультации кандидатов.
Дело то добровольное, но не удивляйтесь, что его обзывают тем, чем оно по факту является ))
Я постоянно считал себя недостаточно хорошим верстальщиком, пытался работать на себя, искал фрилансики, еле еле концы с концами связывал. В итоге решил устроиться на фирму, а меня там определили сеньором. Вот это поворот…
Вопрос какой еще сеньер. Я вот по бумажке старший программист. Но:
1) В 1с, что сами понимаете… Из не 1с опыта то что работает в продакшене это только крошечная компонента на плюсах и нативное приложение под андроид которое работает как довесок к 1сной мобилке. И то и то на пару сотен строк.
2) Из парадигм программирования знаком только с процедурным подходом и немного с ООП. Функциональное? Аспектное? Логическое? Еще какие то? Не а.
3) Познания в алгоритмах на уровне книжек «грокаем алгоритмы» и «теоретический минимум по CS», при этом нельзя даже сказать что я действительно их до конца понял, например с динамическим программированием почти никак, да и вообще.
4) Познания в математике на уровне выпускника сельской школы. В школе то мне математика нравилась, да и егэ сдал неплохо, вот только выбрал экономический факультет с/х академии и в итоге и там ничего почти не изучил, и школу подзабыл.

В итоге записан как старший программист 1с, а по факту джун (и то, сейчас начал активно учиться так как хочу уйти джуном в андроид, но просто по требованиям не пройду).
Да и даже в 1с самый большой проект над которым работал в команде был на 3-4к часов, команда из всего 6 программистов, а пользователей всего 1000 обычных и 2к мобильных (спасибо тому что нужно было мобилку писать, как раз там немного еще разобрался в работе с http, рест api и именно там покодил маленько на плюсах под винду и java под андроид.). Даже по меркам 1с это скорее средний проект чем крупный.

P.S. Ушел в аргументацию, но основной тезис наверно не очень явно виден: Не всяк сеньер что на бумажке сеньер.

Вы довольно часто себя хайрите в комментариях к постараюсь подобной тематики, перестаньте это делать и перечитайте статью

Я всего лишь хочу немного отрезвить тех кто начитавшись подобных статей будет думать: раз я себя низко ценю — значит я на самом деле хорош. Как по мне очень много программистов себя переоценивают. Я кстати в том числе, поэтому стараюсь найти как можно больше негативных черт и спустить с небес на землю.
Кстати спасибо, добавлю плюсик к своей черте эгоцентризм, я о ней и так знал, но почти не акцентировался.
P.S. По поводу часто — по моему комментарии такого рода статьям к трем оставлял, что на фоне моих 1.3к каментов не так уж много. Просто они все проскакивали недавно)
P.P.S. До меня дошло что вы имели в виду под словом «хайрите») Не тот случай, возможно нотки тщеславия в посыле моем и были, но точно не по этой причине, а как раз из эгоцентризма, о чем я выше писал. «Хайриться» мне нет смысла из за недостаточности навыков и очень ограниченной локации. Вероятность что это сообщение увидит кто то из моего города занятый в той сфере куда собираюсь валить, да еще и заинтересовавшийся джуном-свитчером — ну такая, около нуля где то).
Ну как бы об этом и статья.
Если жители НЕ СНГ идут на работу с лозунгами «Не сцать! Если чего-то не знаю, то по ходу дела научусь!», и в большинстве случаев примерно так и получается.
То жители СНГ постоянно думают «Ну вот ещё чуть-чуть подучу и можно попробовать пройти собес на джуна», что в итоге даёт 20-30 лет опыта на одном месте и карьерное загнивание.
На самом деле я согласен с посылом статьи что даже если себя оцениваешь невысоко (хотя в моем случае ситуация запутанная, в голове считаю себя мидлом начинающим, но сравниваю с реальными мидлами и в итоге сравнения оказываюсь недоджуном)))) на собеседования стоит сходить (если работодателей много или они дают повторные шансы), даже если требуемому уровню не соответствуешь могут взять по какой либо причине. Но я все равно считаю что очень многие себя переоценивают (как раз мой случай, в голове мидл в сравнении джун).
И еще я против того чтобы оценивать себя так как записан в трудовой. Потому что сеньер где нибудь в провинции и джун/мидл в jetBrains или яндекс это 2 большие разницы.
Так не просто так же. Не на пустом месте. Приходишь на собеседование, а там сессия, по объёму — как по всем предметам за все пять лет в вузе. И смотрят на тебя так… оценивающе-снисходительно.
Не всяк сеньер что на бумажке сеньер.

Вы сделаете этому миру просто огроменное одолжение, если строго формализуете понятие «сеньёр», чтобы ни у кого больше не оставалось сомнений, кем такового называть и как его выделить из толпы.
Увы, вряд ли это когда выйдет формализовать. Как по мне это человек поработавший на нескольких стеках, с проектами с большой кодовой базой и большими командами. Желательна степень в CS или аналогичные знания, навыки архитектора и руководства.
По крайней мере мои оценки крутятся вокруг этого. Да, я по своим критериям до сеньерства не доберусь никогда. Но есть у меня подозрение что и многие «сеньеры» по трудовой тоже.
Лично я по своим критериям хорошо если до мидла доползу. При том что сравнивая себя просто со средним программистом на рынке я где то между джуном и начинающим мидлом кручусь возможно, если просто по рынку прикидывать — то это трудно, я пока за всю жизнь всего на одном собеседовании был, 4 года назад.

Стандарта в этой градации нет. Каждый называет, как ему хочется. Оттого и постоянные срачи.


Мне нравится разделение по уровню ответственности:


  • Джуниор — тот, кого нельзя оставить без присмотра. Задачу надо разжевать, код придирчиво отревьюить, время от времени узнавать, как дела и поправлять на ходу. Выхлопа от работы джуна ожидать не стоит (т.е. времени он не сэкономит, скорее потратит), но на него можно сгрузить рутину и через некоторое время он подтянется и выхлоп будет.
  • Миддл — работает работу сам. В задачах тоже разбирается сам, где не может, сам задаёт релевантные вопросы. Кроме ревью кода пригляда за ним не требуется, но и помощи в определении курса тоже не ожидается.
  • Сеньёр — автономная боевая единица. Если в него кинуть размытой формулировкой проекта, то он её сам уточнит, ещё и укажет на слабые места и покритикует, подберёт рабочий стек технологий (без оглядки на хайп) и сам в одиночку всё запрограммирует (и за джунами присмотрит). Ещё и заказчика пнёт (возможно, через прокладку-менеджера, если таковая зачем-то есть), что тот ему ещё вчера обещал уточнения к ТЗ прислать.
А вот интересно, в такой классификации люди, в одиночку разрабатывающие достаточно сложные проекты от и до (скажем, тот же редактор карт для Doom — т.е. архитектура и стек технологий полностью выбор и творение одного человека), они куда попадают? В Сеньёры? Но код их проектов может быть самым разным: от великолепного до ужасного, причём, даже в рамках одного их проекта (где-то хотелось быстрее сделать, где-то нахлынул перфекционизм).

Сеньёры могут говнокодить. Как бы вот, почему нет? Их код тоже нужно ревьюить.

В одиночку по собственному ТЗ — он может и сеньор в теории и отлично справится, получив позицию сеньора, но нет этому доказательств.
А куда тут идут мобильные разработчики если:
— может быть разработчик бэка (а может и не быть а ТЗ требует хоть чего то похожего на бэк)
— есть дизайнер
— есть менеджер
— и есть — я как разработчик мобильной части. Все технические решения по проекту (или все кроме бэка) — на мне, и приходится заказчику иногда говорить что работать не будет по какой то причине.

А если это мой личный пет-проект (которым тем не менее люди пользуются)? -:)

Вы кажетесь типичным примером того, что написано в статье. начиная с… «Я вот по бумажке старший программист. Но:1) В 1с, что сами понимаете…»

Я не понимаю… Что плохого в 1С? Замечательная среда разработки, логичная и удобная. Начиная с экзаменов на специалиста учат писать правильный эффективный код, делать правильные эффективные sql запросы к БД. Система сделана по майкрософтовским стандартам, от нее не возникает ощущения сделанности на коленке, как от большинства фронтэнд и бекэнд фреймворков, кроме опять же майкрософтовских.

У вас непонятные комплексы начинаются уже со среды только потому, что какие-то умственно отсталые сказали вам, что программист 1С не программист.
Я не понимаю… Что плохого в 1С? Замечательная среда разработки, логичная и удобная.

Гм, что плохого в 1с я еще и чуть дальше опишу, пока могу лишь сказать что она слишком ограничена и чрезмерно заточена на решение определенного круга задач. На счет «удобная» — это же такой сарказм был?

Начиная с экзаменов на специалиста учат писать правильный эффективный код, делать правильные эффективные sql запросы к БД.

Я что то пропустил и в 1сных учебных центрах и на разных курсах (не от серебряной пули, которые даже сами себя гиками называют) теперь рассказывают про построение архитектуры, грамотную декомпозицию, абстракцию, юнит и интеграционные тесты, управление зависимостями, CI/CD процессы, о чистом коде, паттернах «обычных» и архитектурных и парадигмах программирования? Недавно коллега эксперта получил — рассказывал что во время подготовки он почти никак не продвинулся как программист, все что он изучил это детали работы 1с и по сути стал ближе к DBA.
Сам спец тоже всему чему учит это не программировать а решать конкретный набор задач, крайне ограниченной сферы.
По сути в 1с мы ограничены одной парадигмой программирования: процедурной. Есть там пара элементов ООП, но именно что пара элементов. Сколько 1сников (кроме опять же серебряной пули и ее коммьюнити, небольшого очень) способны взять и написать что то не на 1с? Не на коленке а поддерживаемое, с грамотной архитектурой и т.п.? Подозреваю число это около нуля. Я вообще не приемлю подхода когда программист должен в первую очередь понимать только один фреймворк и предметную область, а на технические навыки, алгоритмы, архитектуры просто забить. Это получается не нормальный программист, а программист «на языке», даже скорее «на фреймворке». Что раздражает — многие из таких программистов почему то себя считают сеньерами.
Вот снова взять меня: я первые 2-3 года работы как раз и думал что все нормально и так и должно быть, учился себе 1с, иногда на хабр заглядывал, правда редко в технические статьи. Все казалось веселым и радужным. А потом вот решил почитать грамотных книг которые как говорится «must read» для любых программистов, начал более активно читать хабр, слушать подкасты (Радио-Т, The Art of Programming, Podlodka, Solo on .Net, devzen, SDCast, hexlet), и понял насколько же сильно заблуждаюсь что чему то научился или что в 1с что то крутое делают. Да из того что я сделал за свои 4 года работы я могу ограниченно гордиться всего парой вещей. И обе были написаны в порыве вдохновения в сумме за несколько дней, и то в них куча всего что можно было бы улучшить, а одна из них и вовсе бы не понадобилась будь архитектура решения другой (мыж1сники? — сказал мне менеджер, некогда писавший код, — ну значит ты фигней страдаешь когда говоришь что нужен грамотный человек желательно работавший с мобилками или писавший api для них. 3к мобильных пользователей — ну значит будет 3к узлов плана обмена).
пока могу лишь сказать что она слишком ограничена и чрезмерно заточена на решение определенного круга задач


Мне непонятна эта фраза. 1С — это полноценная среда разработки учетных приложений любых видов с оконным и вэб-интерфейсом. В чем именно оно вас ограничивает? Длл на нем писать не можете? 3D Игры? Любой вэб-сайт, связанный с продажами, например стандартный интернет-магазин, это учетное приложение, и создание его серверной логики на 1С в разы быстрее, чем на любом из известных мне фреймворков, потому что:
1) Чтобы создать иерархический список, вам нужно просто несколько раз ткнуть мышкой в конструкторе, задав поля и определив уровень иерархии. Время — 5 минут, после чего вы получаете:
а) дефолтную форму списка с иерархическим деревом, со всеми возможными отборами, сортировками, а в управляемом приложении еще и с группировками
б) дефолтную форму элемента
в) автоматический контроль ссылочной целостности
и т.д. и т.п., не знаю что еще сейчас есть в 1С, 4 года ею не занимаюсь

2) Чтобы создать связанный список достаточно в конструкторе добавить табличную часть и определить ее поля… Никаких дополнительных моделей, никаких миграций, никакого прописывания отношений, никакого прописывания связей в интерфейсе на вэб-странице в админке. Ничего. Просто несколько кликов и все готово.

То же самое с отчетами, то же самое с контролем остатков. Весь «определенный круг» учетных задач, присутствующих, а чаще всего составляющих основу любого крупного сайта, делается на 1С быстрее, чем в любой системе. Именно поэтому за ними 90% российского рынка.

Это я называю удобством без всякого сарказма. Если вы считаете это сарказмом, попробуйте простенький интернет-магазин написать на 1С и на любом допустим PHP фреймворке и сравните затраченное время. Не знаю в чью сторону вы будете после этого саркастировать.

По остальным тезисам из вашего винеггрета:

По сути в 1с мы ограничены одной парадигмой программирования: процедурной.


Вы зачем это пишете? Весь 1С построен на объектах… Запрос.Выполнить().Выгрузить().НайтиСтроки(Новый Структура(«Товар», Товар) это по вашему процедурная парадигма? Очень интересно… При процедурной парадигме вы бы писали НайтиСтроки(Выгрузить(ВыполнитьЗапрос(ТекстЗапроса, Параметры), ТипВыгрузки.Иерархически), «Товар», Товар)

Да, там нет полноценного ООП — от встроенных предметных объектов вы можете унаследовать лишь один класс, остальное через костыли, но далеко не все языки следуют стандартам ООП, заданным в с++, и javascript с php также могут считаться как вы написали «Есть там пара элементов ООП, но именно что пара элементов.»

У каждого языка есть свои особенности и недостатки в сравнении с иными языками, это не делает их неполноценными. Для любителей какого-нибудь Scala все прочие языки неполноценны. После скл-образного linq синтаксиса в С# все прочие языки, не имеющие этого синтаксиса, неполноценны. И т.д. и т.п. Если меньше читать понты на хабре, подобных комплексов может и не возникать. Еще раз повторяю — 1С это сверхудобая и сверхбыстрая среда разработки учетных (в том числе и мобильных) приложений, очень грамотно выстроенная.

А что там могут и не могут одинэсники меня вообще мало волнует. Они очень разные, кто-то спокойно пишет на С++, кто-то даже на 1С написать вменяемый код не может.
Никаких дополнительных моделей, никаких миграций, никакого прописывания отношений, никакого прописывания связей в интерфейсе на вэб-странице в админке. Ничего. Просто несколько кликов и все готово.

Думаю в этом и проблема. Платформа слишком сильно прячет некоторые моменты разработки под капотом, поэтому нет возможности полноценно изучить все эти вещи нa практике.

Любой вэб-сайт, связанный с продажами, например стандартный интернет-магазин, это учетное приложение, и создание его серверной логики на 1С в разы быстрее, чем на любом из известных мне фреймворков

Только в конце 2018го года, интернет магазин — это не такой уж «популярный» нa рынке проект.
Писал большой ответ, но случайно его потерял, а второй раз писать лень, отвечу кратко:
1) Если нужно быстро набросать учетную систему — 1с наверно действительно лучшее решение. Проблема в том что для остальных целей она не подходит ни разу.
2) Для ооп нет главного, возможности на уровне кода определять свои объекты. И не нужно рассказывать что можно делать обработки или в модуль менеджера/объекта писать, это совсем не о том.
3) Про мобильные приложения лучше не вспоминайте, мобильный клиент очень крут как концепция и решение, но мобильная платформа как средство создания мобильных приложений — очень уныло из за кучи ограничений на дизайн и функциональность.
4) Коммьюнити которому программирование почти не интересно, а интересен учет и типовые конфигурациии.
5) Политика вендора (плати за каждый чих, программисты идиоты).
6) Неудобные средства разработки (EDT когда еще доползет, да и то эклипс ни в какое сравнение с идеей не идет).
7) Отсутствие ООП ведет к тому что логика часто от данных отделена, а динамическая типизация при этом заставляет слишком много знать и позволяет допускать много ошибок.
Можно на самом деле продолжать и дальше но не вижу смысла, все равно каждый останется при своем мнении.
Можно на самом деле продолжать и дальше но не вижу смысла, все равно каждый останется при своем мнении.


Потому что то вы пишете это на 90% субъективизм типа не хочу создавать обработку, хочу создать класс из кода...(В 7й версии кстати был проект 1С++, который реализовывал полноценное ООП, это к вашим словам, что 1С-ники не интересуются программированием.), а объективность это пункт 1, и рынок потребностей в учетных программах настолько велик, разнообразен и перекликается со всем чем только можно, в том числе и с вэбом, что вобщем-то непонятно что у вас за цели, для которых 1С не предназначен.

Из недостатков 1С:
— Да, отсутствие культуры юнит тестов
— Отсутствие простых и удобных языковых конструкций вроде инкремента через ++ и += или анонимных функций, а так все для удобной разработки на мой взгляд есть.
Не вы один.
У меня почти в самом начале было что официально назвали Senior <язык> Developer. По результатам интервью. При этом, по моей личной оценке на тот момент, это было не вполне незаслуженно.
Правда фирма была прямо заинтересована иметь побольше Senior'ов (и требовать больше ставку на одеске, они как agency работали но деньги платили официально и с оформлением).
Недавно же — на интервью (должность не требовала <язык>) спросили — а вы с <язык> какой версии работали? Пришлось честно ответить что два последних стандарта знаю на уровне «ну помню основные новые фичи, вроде бы».
Еще одна проблема — повальная стыдливость. Любой провал на собеседовании расценивается описываемым нами индивидом, как личное поражение, особенно если он годами сидел в одной компании и тянул свою лямку.
в десяточку!
Самый простой алгоритм повышения самооценки: каждый раз, когда вам кажется, что вы плохой разработчик — смотрите на обновления большей части продуктов гугла и тешьте свое ЧСВ. Когда вам кажется, что вы слишком зазнались — зайдите на гитхаб и отсортируйте проекты по звездам и любимому языку, почитайте код и поплачьте в углу. Если желание поплакать в углу с определенного момента не возникает, то возможно ваше ЧСВ оправданно.
Я как-то устраивался в одну игровую контору серверным разработчиком на C#. Не буду называть имён и тыкать пальцем. Беседовал с замечательнейшим программистом, с которым тут же нашёл общий язык и диалог вылился не в испытание меня, а скорее дружеское обсуждение технологий по теме и рядом. И я был в восторге, что мне предстоит работать с таким человеком, и я надеялся, что и другие будут не хуже, а если и хуже, то не на много. Но тимлидом мне поставили другого парня, который писал просто отстойнейший код. И когда я стал писать свои первые робкие фичи в проекте, он их нещадно критиковал, потому что сам просто не рубил в шарпе от слова «совсем» и каждое моё отступление от его «практик» считалось в его понимании неправильным. Когда я мимоходом, исправляя один баг, заменил ворох массивов, списков и циклов несколькими строчками на LINQ, — он уже откровенно начал бесноваться, что оно будет тормозить и всё рухнет, и вообще он не понимает, что я тут понаписал. Я сделал несколько тестов на производительность, которые показали, что просадка идёт на пару процентах в совершенно некритических для скорости местах, но сокращает код в десятки раз и исправляет баги. На следующий день он просто не пришёл, а вместо этого меня вызвал начальник местного отдела, в котором мы работали, и сказал, что я не подхожу для этой должности.
Подобное притягивает подобное. Тут видимо единственный выход — это снижать своё ЧСВ в перспективе до нуля, и тогда начинаешь встречать подобных людей: душевных открытых, не пытающихся выставить себя умнее других (с последними труднее всего проходить собеседования), и тогда собеседования проходят легко и приятно. А когда уже наняли, особенно важно и дальше снижать своё ЧСВ, чтобы спокойно воспринимать всех остальных и не нарваться на описанного «другого» парня — у меня такой же случай был: с непосредственным руководителем отличные отношения, а один из работников, у которого видимо было авторитетное положение в компании, за что-то невзлюбил и привет…
Это как раз последствие того, что вас не тестировали, а дружески потрепались. Если бы было тестирование, они не смогли бы сказать, что вы что-то не так пишете.
Хм, если проседание производительности всё же было — нельзя однозначно сказать, что Вы были правы, а он нет. У начальства могут быть свои резоны и виденье перспективы. То, что Вам показалось некритичным местом — могло оказаться критичным при других условиях. Занимать столь кардинальную позицию можно только И улучшая код И поднимая производительность. А если есть выбор между одним и другим — то этот выбор вправе сделать тимлид или РМ, но не рядовой разработчик.
Надо было тестировать с исправленным багом. Возможно, рост производительности обуславливался какой-то неисполнявшейся веткой с неверным результатом в итоге. А, может, с исправленным багом оригинальный код летал бы значительно быстрее.
Перспектива очень ясна — на проект пришёл человек с горящими глазами, который любит свою профессию и разбирается в предметной области лучше, чем тимлид. Зачем тимлиду такой нужен?

Статья как раз попала в моё текущее настроение. Проходил собеседование в понравившейся мне компании, после чего понял, что на вопросы, которые мне задавали у меня был ответ примерно в двух из трёх случаев. В итоге подумал, что недостаточно крут для такой компании и ушёл в другую, как оказалось позже — шарагу (чтоб описать весь масштаб катастрофы — скажу, что про Git они не слышали, всё по FTP, что и вышло боком однажды и пришлось более четырёх сотен документов исправлять вручную), где отстрадал два месяца и вернулся обратно. Подготовился, прошёл собеседование, но помня свою первую неудачу запросил зарплату намного меньше желаемой, соответствующую уровню, так сказать… Следующее некоторое время работал над задачами уровня джуна, пока не попросил лидера команды разработки дать мне задачи посложнее, потому что у меня уже начала полным темпом развиваться депрессия. И вроде опыт в разработке у меня есть довольно большой, сталкивался с разным кошмаром и разной сложностью задач, но не могу перестать занижать свою планку на собеседованиях.

Я считаю себя хорошим специалистом, умеющим успешно решать поставленные задачи и быстро учиться новому. К сожалению во многих компаниях, включая Crossover, где процесс найма особенно(!!!) странен, нужен не специалист, а ходячий справочник. В реальной работе используется десятки если не сотни различных технологий и вспомнить на собеседовании все тонкости, ньансы, аббревиатуры, детали и технологии, особенно если не пользовался ими некоторое время бывает затруднительно. А при наличии справочных материалов под рукой всё можно легко вспомнить, научиться, восстановить навык и т.п. от 2-3 мин до 2-3 дней реальной работы, а за неделю и новую технологию освоить.

К счастью нормальные компании нанимают и разговаривают с разработчиком напрямую, минуя HR и сразу по собеседованию, навыкам или по тестовому заданию выясняют уровень человека. Хорошо ещё когда на тестовое задание дают от 24 часов до недели, а не эти новомодные тесты, где нетривиальные задачки нужно решить за 30 мин.
И тут возникает проблема причины и следствия.
Представьте, что в значительном числе компаний России, Украины, etc работают такие недооцененные работники. Часто именно они принимают решение брать нового коллегу к себе в команду или нет. И получается ситуация, когда недооцененный собеседует недооцененного. Это я к тому, что есть уж очень много примеров, когда такой недооцененный, или даже уволенный кандидат на ура устраивается в более пристижную компанию и оттуда машет ручкой, с вершины более высокой ЗП и даже должности. Говорю про своих бывших коллег и тех, кого приходилось собеседовать в команду. Сделал для себя вывод что наши разрабы, админы, девопсы, поголовно недооценены. Но не могу выкинуть из головы, что где то тут есть подвох…
Это я к тому, что есть уж очень много примеров, когда такой недооцененный, или даже уволенный кандидат на ура устраивается в более пристижную компанию и оттуда машет ручкой, с вершины более высокой ЗП и даже должности.
Так и есть!
Недооцененный недооцененного видит издалека :) Вообще на месте руководителей, поручая технарю оценить уровень знаний другого технаря, я бы просил оценки по сравнению с собой: примерно моего уровня, заметно ниже, заметно выше. А уж как руководитель я должен знать кого я прошу оценить: переоцененного сына гендира или недооцененную звезду, на которой я экономлю :)

Уважаемый Crossover. А вы можете расписать вашу иерархию квалификаций разработчиков? Начиная от джуна, заканчивая супер пупер архитектором (или выше).
Часто натыкаюсь на ваши вакансии и улыбаюсь от указанных там позиций. Складывается впечатление, что у вас на всех позициях работают только тех директора и тому подобные.

Конечно, сейчас объясним.

Мы не нанимает исключительно директоров и синьоров, это было весьма странно. У нас есть самые разные позиции, простейшие стартуют от 15$/час и требуют 2 года опыта работы, бакалавра инженера или в CS и определенный стек технологий. Например, вот вакансия для молодого фронтэндщика, можете ознакомиться. Полный перечень позиций, на которые мы нанимаем специалистов, лежит тут. К сожалению, мы не практикуем найм вообще без опыта, так как у нас полностью удаленные распределенные команды, которые работают над корпоративными коммерческими продуктами, обучать людей с нуля возможности нет.

Теперь почему вы видите чаще всего «супер-пупер» вакансии. Очевидно, что высококвалифицированных специалистов намного меньше, чем разработчиков со стажем работы в 2-3 года. Для того, чтобы найти таких высококлассных специалистов уровня ведущего архитектора или CTO мы рекламируем наши вакансии, размещаем информацию на различных ресурсах, проводим Hiring Tournaments по определенным направлениям (обычно это зп от 50$/час, чаще 100$+/час) и так далее. Но даже это не всегда помогает покрыть потребности холдинга ESW Capital в кадрах, так как постоянно покупаются новые компании, которым нужны команды разработки. Поэтому в публичном поле информации о таких позициях намного больше, чем о позициях на 15-30$/час, которые закрыть намного проще в сравнению с условной вакансией SVP of Engineering с зп 200$/час.

Благодарю за пояснения.

Всегда пожалуйста, обращайтесь.
В каждой вашей джунской вакансии в обязательном — год работы с aws. И вот тут то да, грустняшка :(
И Amazon ровно на год дает его бесплатно. Что мешает получить этот год работы на домашних проектах?
Сдайте несколько экзаменов associate level и, думаю, никто не будет приставать больше

Год работы с AWS в переводе с бодишопного на русский означает развернул на ней 3 пет-проекта.

Спасибо за интереснейшую статью!
Можно такой вопрос к вам, от студента разочаровавшегося в формальном образовании: люди без диплома бакалавра не рассматриваются как кандидаты в принципе, или всё же можно попробовать имея опыт, знания etc.?
Кто так верстает?
Screenshot-2018-11-10-00-49-13

Десять процентов экрана на контент тратить не слишком ли расточительно?
Насколько я понимаю, это типовая работа по контракту, т.е. нет оплачиваемых отпусков, пенсионных отчислений, бонусов и т.п. Так ли это? Помимо этого, я читал, что присутствует какой-то параноидальный тайм трекинг.
Т.е., по факту, если ты находишся в одной из стран с высоким уровнем жизни (куда обычно уезжают программисты), то зарплаты кажутся просто смешными, а отсутствие плюшек только делает всё хуже. Архитектор с з/п в $60k в год, или ведущий/старший архитектор с з/п в $100k, да это просто издевательство. Я бы даже сказал, что в Мск/Спб люди с такими скилами и на аналогичных должностях не меньше получают, если не больше, а ещё и учитывая бонусы… Можете ли поделиться статистикой, откуда у вас люди в основном работают? Просто ради интереса спрашиваю.
Мск/Спб люди с такими скилами и на аналогичных должностях не меньше получают,

Не все хотят/могут переехать в МСК/СПБ, а для провинции — это очень хорошие деньги.
Деньги-то может быть и хорошие, но вот многие навыки будет проблематичнее получить существенно, исключительно в силу того, что меньше возможностей. Я полагаю, что никто не будет спорить с тем, что любая должность равная или выше должности старшего разработчика уже требует хорошего набора социальных навыков (soft skills) и широкого кругозора. И чем выше должность, читай, шире сфера ответственности и выше степень вовлечённости в развитие компании, тем всего этого добра требуется больше. Я думаю, что подобный набор навыков можно получить и на удалёной работе, но мне, к сожалению, такие случаи неизвестны. Полагаю, что ни есть, но единичны.
Просто сравните какого-нибудь архитектора Васю из Воронежа, который работает в НПО «Развитие», и допустим архитектора Джима из Сиэтла, который работает, в Амазон. Всё сразу станет понятно, я думаю.
Вот и получается, что с одной стороны, компания хочет нанять, допустим архитектора за небольшие деньги, а с другой стороны, люди, которые реально обладают таким набором навыков, за эти деньги работать не пойдут (скорее всего, я видел на хабре упоминание пары исключений), просто потому, что у них уже обычно есть и опционы в компании и хорошая з/п и прочие бонусы. Ну а если нет по каким-то странным причинам, то проще компанию сменить и получить их.
Просто сравните какого-нибудь архитектора Васю из Воронежа, который работает в НПО «Развитие», и допустим архитектора Джима из Сиэтла, который работает, в Амазон. Всё сразу станет понятно, я думаю.

Вот благодаря подобной удаленной работе, у Васи из Воронежа, есть шанс получать хорошие деньги. Т.к. туда не пойдет Джим из Сиэтла, а работодателям остаются как раз «Васи».
Полностью с этим согласен.
Загвоздка только в том, что реальный опыт в разработке у архитектора Васи, скорее всего будет соответствовать уровню, который требуется для обычного разработчика в Кроссовер. Вася возможно и сменит работу, и будет получать больше денег и набирать опыт, но вот архитектором он не будет.
Вот и получается, что придётся нанимать «архитекторов» и сильно терять в качестве, выращивать своих, или искать годами и не находить. Пример конечно абстрактный, но всё-таки.
Года полтора-два назад люди были в основном из Индии, Восточной Европы (Румыния, Украина, Греция и т.п.), Латинской Америки. Из США не видел никого, кроме самого Энди (основателя), из остальной Европы были единицы.

Спасибо, звучит вполне логично. Если ситуация и изменилась, то, думаю что, незначительно.

Было бы ради любопытства интересно взглянуть на вакансию в дефолтсити, где бы предлагали $100к в год сеньору.
Да, мне бы тоже. Я думаю, что такие варианты возможны, но они не в открытом доступе. По 50-70 после (!) вычета налогов в открытом доступе есть на hh.ru
В любом случае, мы же обсуждаем сейчас позицию ведущего архитектора. Как раз эту должность я и упомянул. А раз уж для старшего разработчика возможно 50-70, то думаю, что и для старшего архитектора возможны 100.
чиф архитектом в кроссовере называют сеньоров, так что речь как раз о них
У вас возможно есть какая-то инсайдекская информация, но на сайте, в требованиях для старшего архитектора, написано:
«8 + years of hands on development experience with 2 + years in an architect or similar position».
Или в этом случае, мы под архитектором понимают обычного разработчика, а под разработчиком начинающего специалиста? Тогда конечно всё не так плохо… Для всех кроме заказчиков, которым в очередной раз продают разработчика по цене двух архитекторов :)
У нас есть самые разные позиции, простейшие стартуют от 15$/час и требуют 2 года опыта работы… К сожалению, мы не практикуем найм вообще без опыта


То есть требуются не знания, не умения, а 2 года опыта? Что вы подразумеваете под «опытом» и как вы можете его проверить? Если я делал сложные проекты для себя, в стол в целях самообучения, но не проработал на оплачиваемой должности ни дня, я изначально не подхожу под ваши минимальные требования? А если я при этом напишу, что проработал 3 года — как вы проверите?
Как по мне выставлять требования в годах как то тоже не очень, но за одним исключением: опыт работы с требованиями, опыт работы в команде, опыт работы над большими проектами которые в одиночку не запилишь соблюдая архитектуру и т.п. — подобное в одиночку наработать крайне трудно.
То есть не-менеджерских позиций дальше 30$/час нет?

Мне кстати не очевидно, почему людей с опытом меньше. Ведь они никуда не деваются, только накапливается. Для примера, взрослых и стариков же больше, чем детей (в любой стране), почему тут это не работает? Мол, молодая индустрия? Даже в РФ уже лет 20 как минимум активно развивается IT, где все те разработчики, у кого должно быть по 15-20 лет опыта?

Часть из нас ушла в той или иной степени в руководство (сам уже задумываюсь), часть из индустрии, часть продолжает работать на сеньорских позициях (если считать их высшими для «чистых» разработчиков), кто-то ушёл совсем — инфаркт в 40 лет вполне можно получить работая по 60 часов в неделю :(. Но нас мало даже не из-за уходов, а просто потому что, субъективно, 20-25 лет назад вся индустрия коммерческой разработки СНГ была меньше чем сейчас ежегодно в неё приходит новичков.

Описанное в статье явление имеет научное название — "эффект Даннинга-Крюгера"

Дочитал до «Ведь, вроде бы, работадателям выгодно держать», поперхнулся.
Я не граммар-наци, но как может сотрудник Crossover писать «работАдателям»? Они же не производством деревянной мебели занимаются, а наймом!

Мне кажется в нашей профессии очень сильно демотивирует постоянно растущее количество технологий, которое к тому же полностью обновляется раз в два года. Всего не выучишь, за всем не уследишь, а ощущение того, что ты не на гребне волны или есть что-то чего-то не знаешь, сбивает самооценку. Тем более, что вероятно вам никогда не приведется пощупать очередной хайповый тренд, по которому следующие два года будут делать запросы HR-ы. Кроме того немаловажную роль здесь играют всевозможноые расхайпованные на конференциях и соцсетях "гуру", таким образом задающие планку. Наш специалист, сидя в зале, пытается оценить себя по навязанной шкале и то, на что он может претендовать в сравнении с выступающим.


А теперь разложим все "по понятиям".


90% "новых" хайповых технологий на деле является дерьмом, потому как:


  • это либо топтание на месте: а давайте все вместе будем дружно использовать новую парадигму/язык/платформу, потому что это сейчас будет модно.
  • либо переизобретение велосипеда на другом стеке — происходит периодически каждые 5-10 лет, когда подрастает новое поколение, использующее новые средства разработки. Все эти "новые" идеи уже были когда-то реализованы раньше, либо заимствованы из другого стека. Причем, как правило, "раньше было лучше".
  • иногда имеет очень специфическую область применения, с которой вы вряд ли столкнетесь, как например блокчейн или бигдата, но тем не менее расхайповано как средство первой необходимости
  • выглядят привлекательно только на презентации. Нормальная технология содержит не столько абстрактную идею, сколько реальный опыт ее применения. При внедрении же новых технологий всегда внезапно вылазит стопицот побочных проблем разного характера.
  • есть попытка продать собственный продукт или поддержку.
  • выйдут из моды через 2 года или будут заменены другими.

Гуру, выступающие на конференциях или публичных площадках:


  • обычно представляют труд большого числа людей "за сценой"
  • как правило являются достаточно узкими специалистами в своей области
  • многие из них уже давно не пишут код (когда активность в твиттере становится выше, чем активность в репозитории собственной компании)
  • редко являются финальными пользователями своих изобретений
  • выступают в роли шоуменов для раскрутки собственной компании и продуктов
  • так или иначе получают за это деньги

Вы реально классный специалист, если:


  • можете с нуля без посторонней помощи написать бизнес-приложение
  • владеете определенным стеком технологий для реализации данной задачи
  • способны к самостоятельному обучению
  • стараетесь быть "в теме": интересуетесь последними веяниями и разработками
  • обладаете здравым смыслом и критикой
  • несмотря ни на что вам нравится ваша работа, и вы в ней не только из-за денег

Вы должны осознавать:


  • большинство HR-ов некомпетентно в IT (а некоторые и в HR)
  • универсальный специалист, подобный швейцарскому ножу — это хреновый специалист, не делающий нормально ни одну из функций
  • есть люди, которые лучше умеют себя продавать. Это не делает их лучше как специалистов.
  • наша работа должа приносить удовлетворение
  • если вы не прошли собеседование, то возможно это не вы не подходите компании, а компания не подходит вам
очень сильно демотивирует постоянно растущее количество технологий

Зависит. Меня наоборот мотивирует, т.к. можно ничего не знать, но быть быстро обучаемым. Для каких-то людей (вероятно, иррационалов) это наоборот больше по нраву.
НЛО прилетело и опубликовало эту надпись здесь
универсальный специалист, подобный швейцарскому ножу — это хреновый специалист, не делающий нормально ни одну из функций


Но узкий подобен флюсу. И странно, что он не трогает другие области, вне своей обычной работы. Может быть, ему они не интересны? А вот как быть, если интересна разработка приложений самой разной направленности? Вот, скажем, сейчас мне крайне интересно, как общаться с видеокамерой по ieee1394 из сишной программы под Windows с помощью совершенно непонятных мне SetupDiGetClassDevs и SetupDiEnumDeviceInterfaces. Информации я нашёл практически ноль. Единственная книжка («Программирование аппаратных средств для Windows») содержит серьёзные ошибки кода, а вот эта самая SetupDiEnumDeviceInterfaces перечисляет платы в компьютере, а не видеокамеры (а в книжке она подаётся, как перечисляющая именно устройства с ieee1394). А год назад мне было интересно (и нужно) сделать драйвер USB-устройства для Windows. Книжка по написанию таких драйверов огромна и сложна. Но есть пример от Microsoft в их DDK. Так же была интересна 3D графика в лице OpenGL, 2D графика, звук и видео в лице DirectDraw и DirectShow. А для QNX нужны были также фишки про создание драйверов и программирование под Unix и Photon Micro GUI в частности. Месяц назад мне потребовалась именованная разделяемая память в QNX. Для Linux когда-то пробовал Qt. А ещё были интересны и нужны сокеты. Ах да, есть ещё приставка PSP с её собственными аппаратными средствами. И STM32, и Atmega и PIC. Для этих штук я тоже писал различное ПО.
Я никогда всего перечисленного не использовал по десять лет каждое и, естественно, не помню/не знаю тонкостей. Более того, все понятые и запомненные тонкости частенько забываются. Это почему-то удивляет некоторых людей. В одной из веток мне написали, что раз я забыл точную реализацию альфа-бета алгоритма, написав на ней шахматную программу, значит, я этот алгоритм никогда и не понимал. Удивительная наивность! В 2011 я разбирался со сжатием, используемым в JPG (потребовалось для одного проекта). Практически вывел алгоритм AA&N (Y.Arai,T.Agui,M.Nakajima). Но вот именно сейчас я не помню уже ничего, кроме того, что я это делал. Это просто вытеснилось из памяти. Но это совершенно нормально, если вы занимаетесь (и это вам нравится) многими вещами. Даже собственные статьи забываются и требуют усилий для понимания заново, как оно так было сделано.

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


В резюме важно, чтобы это все смотрелось органично и не вызывало дополнительных вопросов. Вот добавьте в свое резюме рядом с C/C++ строчку JS/Node, и сразу появится куча вопросов. Вы втихаря пилите свой JS-движок? Участвуете в разработке Node? Или просто ищите вакансию, которая вам поможет в освоении фронтенда? А вот с резюме фронтэндера таких вопросов не возникнет.


Есть люди, у которых баланс нарушен от освоения в сторону лишь изучения нового материала. В этом случае, даже имея официальный сертификат, все их знания будут поверхностны, ибо для освоения технологии требуется более глубокая и объемная работа, нежели написание "Hello World"-ов. А для этого требуется время, которого сверхурочно нигде не возьмешь. Поэтому когда в резюме стоит строчка типа: С/C++, Java, Python, C#, JS, PHP, Go, Rust, то скорей всего он не владеет в достаточной степени ни одним из этих языков.


Более того, все понятые и запомненные тонкости частенько забываются

А это огромный плюс нашей памяти — делать автоматическую очистку мусора. Основной скилл для HR в этом случае не само знание, а то, что чел однажды смог хорошо разобраться с данной технологией.

Вот поэтому я ориентируюсь на вот это.
Если какая-то технология/алгоритм/тонкости языка программирования потребуется работодателю, то с ней можно разобраться за некоторое время с требуемым уровнем погружения, если есть способность и желание разбираться. А не помнить наизусть всё содержимое учебника.
Я тут недавно пробовал сделать такое. (под qnx и gcc 2.95 компилируется (с предупреждением «pointer to member cast from virtual base 'CErrorsAcs' will only work if you are very careful»), но с приведением типа указателя на метод класса к классу CAcsErrors с вызовом функции SetState из CErrorsBased, а не CErrors со всеми вытекающими ) Ну а чего? Дом унаследовал дверь, значит, ручка двери теперь компонент дома. Логично? А вот компиляторы так не думают. Я про такую тонкость и не знал никогда. Теперь знаю. :)
А что такое «достаточная степень» владения?

У меня в резюме:
Programming languages:
Assembler, Bash, C, C++, Erlang, Javascript, Pascal, Perl, PHP, Python, Ruby (+Rails), and more (in passive state).
(кстати, наверное надо обновить — Ruby и Pascal ушли в passive, не трогал уже пять лет).

И ни одного сертификата. (доисторические онлайн не считаются).

Всё, мне пора в утиль?
А что такое «достаточная степень» владения?

Степень, достаточная для того, чтобы быть полезным потенциальному работодателю для решения поставленных бизнес-задач.


Сама строчка о языках ничего не говорит. В тайтле вы должны четко дать понять кто вы, и чем конкретно вы можете быть полезны работодателю. Стоит акцентировать внимание не столько на языках, сколько целевых на технологиях, платформах или бизнес-областях, в которых вы работаете. Никому не нужен просто assembler, зато требуется запрограммировать конкретный микроконтроллер или написать драйвер ядра Linux. Вместо bash-а будут искать администрирование Unix/Linux. Что вы делаете на C/C++: программирование под Win32, под Linux, геймдев или еще что? JavaScript тоже ни о чем. Вы фронтендер? Разрабатываете под ключ вебприложения?


Не бойтесь выбрасывать мусор из резюме — больше не лучше. Вы будете реже выходить в поиске, зато более целенаправленно.


P.S. Технологии и языки хорошо указывать в своем портфолио, когда они связаны с конкретными проектами. Так у HR-а создается представление о вашем профиле.

— Налево умные, направо красивые.
— А мне что, разорваться?

C/C++: программирование под Win32? да. под Linux? да. геймдев? очень давно, тут сорри. драйвера? да. микросервисы? да. ускорение узких мест для erlang-приложения? да.
JS: фронтендер? если придётся. под ключ? если придётся. серверная часть? если уже написано на нем, то остальное тоже допишу, да.

Я к чему — я тот самый ненужный швейцарский нож. Для меня full-stack начинается в hardware и заканчивается в бизнесе, и да, я понимаю на всём протяжении, и могу отлаживать и на уровне ICE'а если понадобится.

Просто когда кто-то говорит что это невозможно или бесполезно… Ну вы или не знаете что так таки бывает, либо вы просто настолько узкоспециализированы, что не знаете когда это бывает надо.

"Подумаешь… Я еще и вышивать могу… И на машинке… тоже..." ;)


Это все очень хорошо, поздравляю. Однако постоянно растущее количество технологий и областей применения так или иначе требует более узкой специализации. Если вы во всех достигли уровня "бог", то снимаю шляпу — тут не о чем разговаривать.


Мне лично попадались за всю практику "специалисты широкого профиля" или "просто программисты" — человеки, которые в 201x на Java итерируют списки при помощи for (int i = 0; i < list.size(); i++) list.get(i). Им впринципе все-равно на чем писать — все языки похожи, а stackoverflow и google всегда под рукой. Требуемую задачу они решают методом копипейста или точечного патчинга чужого кода. Их обычно ставят в проект, чтобы они были вкурсе, и чтобы потом их можно было оставить на саппорте, когда основной девелопмент уже завершен.


Но тем не менее так или иначе на рынке труда все-равно будет необходимо позиционировать себя в какой-то одной области, либо паре смежных областей. Но иногда в некоторых стартапах действительно бывает необходимо хороший специалист, компетентный сразу во многих областях.

О, тут прекрасный срачик рядом — habr.com/post/429612, как раз на эту тему.
Да, нельзя держать up-to-date десяток параллельных технологий в голове.
Но любой даже «классический» сеньёр требует минимум несколько — основной ЯП (например, C# / Java / Python / C++ / etc), зачастую — еще дополнительный ЯП или DSL (JS, HTML, XSLT, CSS), обязательно SQL и/или NoSQL и их обертки для основного ЯП, плюс неплохой снапшот Posix API и/или WinAPI и/или X и/или Wayland и/или GTK и/или…

То есть чистых «фокусистов»-то и нет. Даже в эмбедде, чистый программист эмбедда — бесполезен, если он вообще ничего не понимает в железе.

Итого? Синглтоны — тоже никто. Возникает вопрос исключительно в балансе и обучабельности.

А дальше… Если это стартап — то надо человека который может максимум прямо здесь и сейчас. Если крупный фин.институт — надо вообще чтоб финансисто-математик был. Или как в 1С — с неплохими знаниями бухгалтерии, например. То есть… Так или иначе универсал.

Ну вот под термином "классический сеньор" вы примерно и описали типичный стек, необходимый для решения большого числа бизнес-задач. Но вот например меня лично насторожило бы, если бы я увидел рядом C# и Java, т.к. это совершенно два разных стека, призванных решать сходные задачи. Вы реально хорошо разбираетесь в экосистеме каждого из них и знаете типичные решения, которые там используются? Я не отрицаю, что есть спецы, которые в совершенстве владеют обеими технологиями, но какая практическая цель этого? Просто интересно знать? Получить больше предложений на рынке? На работе заставляют писать на чем угодно? Но любой реальный проект никогда не будет совмещать в себе обе эти технологии, поэтому половина навыков так или иначе останется невостребованной.


С другой стороны, есть специалисты по Oracle, SAP или 1C, которые в гробу видели все эти WinAPI, GTK, C++ и прочее вместе взятое. "Их и так неплохо кормят". Есть дата-аналитики, и у них свои инструменты: Excel, R, Kafa, Hadoop, etc… Есть специалисты по конкретному продукту, и они ценятся на рынке гораздо выше, и их отрывают с руками. Никто их не будет спрашивать что они там еще могут делать, помимо основной работы, потому как странно подписать жутко дорогого спеца по "Супер Пупер Бизнес Платформе (тм)", и заставлять его пописывать на досуге на C/C++.


И естественно, любой специалист ценится, если у него помимо навыков программирования есть определенные знания предметной области.

Практическая цель? Продукт растёт, и вместо одного стека там вырастают независимые части. Например, бэкенд на C++ & C# & MSSQL, к нему рядом биллинг на Java, всё это приправлено фронтендом на PHP+JS+MySQL и пронизано всё его высочество SOAP'ом. Как так получилось? А кого это уже волнует, бизнес волнует как теперь это всё развивать дальше.

Ну и без кросс-человека договориться между отделами становится всё сложней и сложней.
А можно не гнаться за хайпом, а исповедовать вечные ценности (С++, например) и не страдать. Разве что от необщения с некоторыми HR.
Хотя сам знаю и использовал/использую многие технологии, поскольку за годы довелось поработать в самых разных областях (и не по году-два). Даже наногалеру удалось увидеть (единственное место, которое я покинул быстро).
Не знаю как вас, а меня на собеседновании выбешивают всякие психологические и прочие зодиак-тесты. -___-
Типичный овен
Гордый телец.

Вместе мы — суровый энтерпрайзец)

Чтобы иметь адекватную оценку себя на рынке, надо просто регулярно ходить на собеседования, вот и все :) Профилактика застревания в своем болотце, вроде как зубы чистить по утрам. Многие собеседующие будут задавать довольно неадекватные вопросы — здесь не надо спорить, вы этого человека видите первый и последний раз в своей жизни. Многие завалят на довольно важных вещах — вот их и стоит проработать плотнее в ближайшие 2-3 месяца. Когда вас будут звать на адекватную зарплату в адекватные компании в 20%-30% случаев — значит, вы хороши и адекватно себя оцениваете. Если зовут реже — надо подтягивать знания и опыт. Если чаще — похоже, вы мало просите :)
Можно заработать плохую славу… Люди ведь тратят время не просто так, а с целью найти себе кого-то. Смысл им приглашать человека, который регулярно ходит на собеседования для упражнений? Они, может, и не против, но в реальности нужно закрывать таски и вакантные места, а не тренироваться.
Это сказки HRов, полагаю
В Москве можно ходить смело. Про миллионники не скажу. В маленьких городах, конечно, рискованно, да и смысла нет. Все всех знают :)

Поверьте — если даже в Москве все хорошие специалисты друг друга знают, то что говорить о городах поменьше. Я не ожидал, но айти тусовка в РФ не такая большая....

Вы не поверите, но тусовка ещё не весь рынок.

НЛО прилетело и опубликовало эту надпись здесь
Я думаю, что нужно уточнить, что в рамках одной компании люди могут работать по разным направлениям и специальностям. И условному админу из отдела инфраструктуры общаться с условным дата инженером из отдела поддержки datalake не нужно.
Но вот есть необходимость внутреннего общения и обмена опытом и поэтому — почему бы не проводить внутренние митапы/семинары по конкретным тематикам, по отдельным направлениям?
Так же и взаимоотношения между сотрудниками разных компаний. Сколько хороших DS в РФ? Вряд ли десятки тысяч, скорее тысячи. Сколько хороших спецов по k8s? Да тоже самое. И т.п. Поэтому сообщество действительно не очень большое.
НЛО прилетело и опубликовало эту надпись здесь
А когда ходить? Работодатели как-то не очень адвекватно воспринимают, что я раз в месяц денёк возьму (да и нафиг не сдалось такое «развлечение»). Это у всяких стартаповых хипстеров приходи-уходи когда хочешь, а на производстве как-то не очень любят.

> завалят на довольно важных вещах — вот их и стоит проработать плотнее в ближайшие 2-3 месяца

Даже если вы их видите в первый и последний раз в жизни, как того собеседующего? И такому ходящему, пожалуй, не стоит давать серьёзный проект в управление.
Значит, интересы вашего работодателя идут вразрез с вашими, если вы не планируете работать на одном месте всю жизнь, как японцы :) Брать отгул не обязательно — в зависимости от графика работы, можно договориться на собеседование ДО или ПОСЛЕ работы, либо ВМЕСТО обеда по Skype.
Особенно забавно договариваться о собеседовании после рабочего дня в компании, которая утверждает, что у них нет сверхурочных, что работают с 9 до 18 (например), а договариваешься на 19, потому что сам работаешь с 9 до 18.

Кстати, бывший коллега рассказывал про интересное интервью с ним (оно было недавно, буквально неделю назад, в четверг).


В нем интервьювер еще раз уточнил, какие языки знает собеседуемый (в его случае был C#, Java и Python). Далее он открыл на планшете сайт govnokod.ru и просто выбирал более-менее интересные примеры кода, а потом просил рассказать, что там не так.


С моей точки зрения всё было очень необычно, однако сама задумка довольно интересная: примеры из жизни, они свежие, не выдуманные. И собеседники находятся в равной позиции, так как оба не до конца готовы к этому коду.

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

Я не вполне согласен с использованием прямо сайта на собеседованиях (просто решение ну очень необычное).


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


Как бы вы "закрыли глаза и переписали нормально" буквально одну строчку ниже?


if (market.Handicap != null && market.Name.ToUpper().ToLower().Contains("HANDICAP".ToLower()))
{
    ............
}
Бывает перевожу статьи по IT с medium (до того, как это стало трендом:) и выкладываю их там же. Самая популярная статья на данный момент «Вопросы по React на собеседовании». Встречаю много статей, про кадровый голод в IT и как пройти собеседование в одну из кампаний. И одно другому противоречит.

Считаю что никакого голода в IT нет и, по крайней мере, не будет. А вот в космическая отрасль другое дело. Для IT отрасли даже если сейчас претендент не дотягивает до джуна, то ничего страшного, научится. А вот во втором случае часто учиться некому. И скоро будет уже не у кого…
НЛО прилетело и опубликовало эту надпись здесь

Кажется, в России уже можно делать бизнес с психотерапией, направленной строго на IT. А что – публика платежеспособная, проблемы у каждого второго, да и примерно одного характера. Когнитивная терапия многим будет по душе со своей "отладкой" процесса мышления и постоянным поиском багов.

Не знаю как с психотерапевтами, но психологи зачастую учились по аналогу курсов «говнокодин на пыхыпы» и не вызывают у айтишника с инженерным образованием доверия (потому как их представление о мире где-то между гарипоттером и каналом ХренТВ).

Хороший психотерапевт обычно имеет медицинское образование, курсы переподготовки (или что-то такое) в каких-нибудь зарубежных институтах, и научную картину мира. Я бы даже сказал, что хороший терапевт имеет более научную картину мира чем средний программист.

Хороший, вот только даже имеющих звание не всех можно считать хорошими. Если там иконы и средства, которые не имеют доказанного эффекта вообще, то научной картины там быть не может. А нехороших (абы каких) вообще толпы, со всякими семейными и прочимии доморощенными психологами всё ещё хуже.
Узнал в статье себя.

Достаточно долго изучал и обучался всему, перед тем, как решиться сходить на собеседования. Буквально недавно просто случайно открыл резюме на хедхантере для работодателей. Пришло достаточно много откликов, прошел 2 собеседования. После второго перезвонили через 2 часа и предложили работу, я согласился и отменил еще 7 собеседований следующих, т.к. кампания понравилась. Через неделю позвонили с первого и тоже предложили работу. Что забавно — просил я небольшую сумму, но предложили мне почти в 2 раза больше.

Непосредственно перед собеседованиями я морально готовился к тому, что меня развернут, и утешал себя тем, что узнаю свои пробелы и смогу их закрыть и уже потом когда-нибудь таки устроюсь на работу. Также несмотря на достаточно хорошую теоретическую подготовку и наличие пары своих проектов — очень был не уверен в том, что это кому-то понравится, и что моих знаний достаточно даже для работы за еду. Я даже думал о том, чтобы начать с какой-нибудь совсем приземленной и небольшой конторы, но в итоге попал в достаточно крупную кампанию с интересными внутренними проектами.
Тут еще вот какой момент: больший уровень — большая ответственность. А люди из СНГ очень не любят ответственности.
Самый неприятный момент конкретно с кроссовер — это программа шпион, которая будет шпионить, где ты сидишь и чем занимаешься. Обычно на работе я работаю и не сижу в соцсетях, но делаю это потому что я так привык работать и ощущаю ответственность, если у меня будет работать такая программа, это будет психологически напрягать. По моему программирование это область где ты выдаешь результат в разумные сроки, а не где ты изображаешь активность. Например Миша с утра сел за работу, написал код — получилась фигня, стер код, пошел подумать, понял как можно переделать, написал новый код, тесты валятся, понял что опять фигня, снова написал код, на этот раз вроде все работает, Миша работал 8 часов, выполнил задание, Миша молодец. Коля встал утром, заварил кофе, обдумывая попутно задачу. Отвез детей в садик, обдумывая попутно задачу. В 11 утра сел за ноутбук, написал хорошо продуманный оптимальный код за 2 часа, в 13-00 закрыл ноутбук. Коля прогульщик, он не отработал положенные 8 часов и не получит вожделенные 240 долларов за день от кроссовер, хотя сделал тот же объем работы, что и Миша, и выдал результат быстрей.
Да, скорость разработчиков в режиме написания кода может отличаться в 5 раз (а на корпоративных задачах, как мы знаем, и в 100 раз может отличаться).
Ок, пусть Коля справляется за 2 часа, Миша за 6.
Но коммуникация, исправление мелких ошибок, различная рутинная работа, code review, refactoring — происходят примерно с одинаковой скоростью и у Миши и у Коли, и может занимать у них обоих по 2 часа в день (И получаем 2 из 8 часов и 2 из 4 часов, соотвественно. Забавно, да? У Коли половина или больше половины работы — вовсе не программирование!).
И в итоге это лишь значит, что Коле нужно работать по гораздо более высокому рейту, пусть и формально на халф-тайм, это будет честнее для всех. К сожалению, мало какие крупные компании умеют такое правильно оценивать, им проще усреднять всех и делить на уровни «по выслуге лет» или «по размеру задач».
У того же Crossover, если я правильно понял, не бывает разработчиков за $60/час, а бывают только «архитекторы».
Ищите заказчиков сами, вместо того, чтобы пытаться обмануть систему работы в подобной компании. Искать заказчиков долго, сложно, но в итоге тот найденный редкий понимающий заказчик будет в восторге от скорости решения Колей проблем и будет платить за это очень хорошие деньги.
Да, спасибо.
Слово «заказчик» подразумевает не работу, а бизнес.

{От не разработчика ПО, а научного работника, R&D}
есть и другая крайность, когда аналог Team Lead в небольшой компании постоянно выражает желание создать аналог windows10 "быстро и дёшево".

Разработчик! Прекрати вестись на всякие мутные лозунги, это неправда
«Я сам такой разработчик», а вдруг нет? А вдруг я, действительно, недостаточно компетентен? Хотя, постойте, об этом ведь…
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре , чтобы оставить комментарий