Напишу свое ИМХО. Причина всех срачей одна — разным компаниям требуются различные специалисты. Например:
1) Компании, продающие человеко часы в конкретной технологии, то есть максимально тупой аутсорсинг.
Нужны люди, которым можно сплавить говнокод. В их задачу входит написание костылей и подпорок к существующим подпоркам. Так как костыли приходится применять весьма заковыристые и все написано таким образом, что тронешь в одном месте, отвалится в другом, то действительно зачастую экспертные знания именно в технологии. Рекомендуемый возраст сотрудников — до 25 лет.
2) Более продвинутый аутсорсинг — разработка чего то на заказ по техзаданию. Нужны люди, которые хорошо знают предметную область и могут кодировать, а также хорошо умеют читать спецификацию. Знания технологий требуются меньше, чем в компаниях E, и максимум востребован средний уровень знания, зато требуется становиться экспертом в предметной области. Рекомендуемый возраст сотрудников от 25 до 30 лет;
3) Разработка собственного продукта, рассчитанного на большое время жизни и непрерывное изменение. Нужны люди, которые в состоянии спроектировать нормальный костяк системы и при развитии и изменениях требований удерживать приемлемое качество. Знания технологий востребованы мало, а опыт разработки очень и очень важен. На первое место выходит интуиция, умение предугадывать изменения, умение изолировать разные части системы, умение быстро рефакторить, умение недопускать копипаста и умение не привязываться к технологиям, делая их взаимозаменяемыми. Рекомендуемый возраст сотрудников от 30 до 40 лет;
4) Компании, разрабатывающие технологии, являющиеся стандартом. Например Google, Microsoft. Нужны те, кто в состоянии написать универсальную технологию общего назначения. Уперевшись сразу во все возможные ограничения — максимальная гибкость, максимальное быстродействие, заранее на годы вперед. Огромный опыт, широкий кругозор. Рекомендуемый возраст — выше 40 лет, которые шли вместе с индустрией и поддерживали приемлемую квалификацию, стремясь развиваться именно в этом направлении.
Я привел здесь наиболее важные навыки для различных типов компаний для ключевых специалистов.
Итого, в чем проблема? Проблема в том, что наиболее естественно для разработчика развиваться именно в этом порядке, начиная с компаний первого типа и стремясь перейти в компанию четвертого типа. Не переходя в начальство, но с серьезным ростом зарплаты, которые в последних может достигать огого каких значений. Сначала упор на технологии, потом востребовано умение читать спеки и понимать что требуется, далее умение работать на большом промежутке времени, и наконец уровень, где требуется все воедино и важен черти какой опыт и неплохие знания.
Если же посмотреть количество компаний, то они отсортированы здесь в порядке убывания их количества. Больше всего контор первого типа, меньше второго, еще меньше третьего, и практически нет четвертого. Как результат, развитие большинства специалистов останавливается на первых компаниях. Компании третьего и четвертого типа уже даже не надеятся найти тех, кто им действительно нужен, потому берут спецов по технологиям, и надеятся что они справятся. Качество продукта от этого страдает, но никто ничего не может сделать. Ибо во первых, те, навыки которых востребованы, они весьма редко приходят на собеседование. А во вторых, если придут, то их зачастую зарубают вопросами по поводу деталей, а по поводу того, в чем требуемые спецы наиболее продвинуты и тах навыков, за счет чего они очень и очень нужны компании, не будет вообще никаких вопросов. Или просто не поверят, ибо 99% кандидатов говорят что круче них только скалы, пишут превосходный код всегда правильно, без костылей, но эти навыки проверяются в лучшем случае разворотом списка.
Все это я к тому, что не нужно грести всех под одну гребенку. Далеко не факт, что тот, у кого опыт из пункта 3, будет бесполезен в пункте 1 — он ведь может за счет навыков и умения изолировать детали тоже выполнять задачи вполне хорошо. Ему единственное, что не нужно вставлять палки в колеса в виде ограничений на рефакторинг. И наоборот, человек с опытом из пункта 1 может оказаться полезным в компаниях третьего типа, хоть и не на ключевых позициях. Соответственно нужно не тупо фильтровать, а смотреть, где человек может принести пользу, искать сильные стороны, а не слабые. Ибо на практике недостатки могут оказаться достоинствами. Если так делать, то выгодно будет всем.
Здравствуйте, elmal, Вы писали:
E>Рекомендуемый возраст сотрудников E>Рекомендуемый возраст сотрудников E>Рекомендуемый возраст сотрудников E>Рекомендуемый возраст
На помоечку такие рекомендации.
E>Все это я к тому, что не нужно грести всех под одну гребенку.
Сам же только что сгреб под одну гребенку тестировщиков, перешедших в кодеры в 30 лет, 45-летних электронщиков, начавших писать на C#. Хорошие компании не просто не смотрят на возраст, а даже просят не указывать его в резюме вообще.
Здравствуйте, Кодёнок, Вы писали:
Кё>Сам же только что сгреб под одну гребенку тестировщиков, перешедших в кодеры в 30 лет, 45-летних электронщиков, начавших писать на C#. Хорошие компании не просто не смотрят на возраст, а даже просят не указывать его в резюме вообще.
Имеется в виду, что требуемую квалификацию весьма и весьма проблематично получить к указанному возрасту. Соответственно если человеку 23 года, он сеньер в аутсорсе, то вызывают большие сомнения то, что он обладает требуемой квалификацией для ключевого сотрудника продуктовой компании.
Здравствуйте, elmal, Вы писали:
E>Напишу свое ИМХО. Причина всех срачей одна — разным компаниям требуются различные специалисты. Например:
E>1) Компании, продающие человеко часы в конкретной технологии, то есть максимально тупой аутсорсинг. E>2) Более продвинутый аутсорсинг — разработка чего то на заказ по техзаданию. E>3) Разработка собственного продукта, рассчитанного на большое время жизни и непрерывное изменение. E>4) Компании, разрабатывающие технологии, являющиеся стандартом.
Я для себя вывел более простое разделение:
1) Продуктовые компании, или компании которые годами работают над одним продуктом.
2) Сделал-проект-и-забыл компании. в основном аутсосинг.
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Здравствуйте, elmal, Вы писали:
E>4) Компании, разрабатывающие технологии, являющиеся стандартом. Например Google, Microsoft. Нужны те, кто в состоянии написать универсальную технологию общего назначения. Уперевшись сразу во все возможные ограничения — максимальная гибкость, максимальное быстродействие, заранее на годы вперед. Огромный опыт, широкий кругозор. Рекомендуемый возраст — выше 40 лет, которые шли вместе с индустрией и поддерживали приемлемую квалификацию, стремясь развиваться именно в этом направлении.
Отчего же тогда недавние выпускники вузов успешно справляются с алгоритмическими задачами и проходят интервью в указанных компаниях? Здесь больше проверяются фундаментальные знания, чем опыт.
Описанные качества важны для позиций Senior и Principal. Есть еще много позиций ниже — SDET, SDE, SDE II.
А с учетом все усиливающейся конкуренции, "заранее на годы вперед" все менее актуально. Нужно успеть первым и отхватить кусок рынка, а уже потом заниматься оптимизацией. Иначе, пока будешь заниматься оптимизацией, рынок займут другие. Нужен некий баланс.
Я бы расставил акценты по-другому.
1. Компании, создающие индустрию — Microsoft, Google, Amazon, Apple. Они сами разрабатывают технологии и выпускают продукты на собственных технологиях. Важны в первую очередь фундаментальные знания — структуры данных, алгоритмы, архитектуры систем. Знание технологий маловажно, т.к. у каждой компании собственные технологии и нужны универсальные солдаты. Опыт полезен, но необязателен — зависит от уровня. Конкретным технологиям можно обучить и внутри компании.
2. Enterprise-сектор. Используют технологии и продукты компаний первого типа, и на базе них создают специализированные решения. Тут очень важно знание конкретных технологий и опыт, позволяющий сориентироваться среди их многообразия, чтобы не изобретать велосипед. Могут себе позволить повышение квалификации сотрудников, поэтому возможны нюансы.
3. Инди-разработчики приложений и сервисов. Также используют наработки компаний первого типа и пишут под их платформы собственные решения. Опять же, важнее знание технологий и опыт, чем внутреннее устройство структур данных и алгоритмы, т.к. они уже реализованы компаниями первого типа. Очень много зависит от каждого члена команды, результат нужен сразу, времени на обучение сотрудников нет.
Вот и получается, что в компаниях первого типа важнее фундаментальные знания, а в компаниях третьего типа главное — владение технологиями. Enterprise-сектор — нечто среднее.
Здравствуйте, AndrewJD, Вы писали:
AJD>1) Продуктовые компании, или компании которые годами работают над одним продуктом. AJD>2) Сделал-проект-и-забыл компании. в основном аутсосинг.
Аутсорсинг тоже может годами работать над одним проектом. Причем лет 10. Отличие такого аутсорса от продуктового — что клиент один, продукт массовым не будет никогда. И в основном идет поддержка, спеки спускаются сверху, думать о будущем не требуется. Сделал все по спеке — тебе заплатили. Сделано все криво и костылями — это никого не волнует, волнуют только фичи. Даже зачастую приветствуется запутывание кода, ибо если запутаем все так, что саппортить сможем только мы — хрен заказчик передаст проект на аутсорс к другим. Будешь стремиться сделать все максимально прямо, будешь выправлять всякие костыли — это тебе плюсов не добавит с точки зрения руководства. А могут добавиться и минусы, так как в результате вместо планового расширения штата, заказчик увидит что и так неплохо справляются, и не будет платить дополнительные деньги. В случае же продуктовой компании, то если ты сэкономил кучу ресурсов, сделал один то, что рассчитывали делать силами 10 человек, и потом твое решение легко саппортить — это гарантированное признание и уважение начальства. Соответственно если ты делаешь все максимально прямо, то компания получит дополнительную прибыль, а не убытки.
Здравствуйте, nile, Вы писали:
N>Отчего же тогда недавние выпускники вузов успешно справляются с алгоритмическими задачами и проходят интервью в указанных компаниях? Здесь больше проверяются фундаментальные знания, чем опыт.
Они оттого успешно справляются, что идут на младшие неключевые позиции. Рутину нужно делать везде, в любой компании. N>Описанные качества важны для позиций Senior и Principal. Есть еще много позиций ниже — SDET, SDE, SDE II.
Вот только в компаниях четвертого типа такое понятие, как Principal, есть. В аутсорсе же таких позиций быть не может, ибо вся политика построена на то, чтоб все были легкозаменяемыми винтиками. N>А с учетом все усиливающейся конкуренции, "заранее на годы вперед" все менее актуально. Нужно успеть первым и отхватить кусок рынка, а уже потом заниматься оптимизацией. Иначе, пока будешь заниматься оптимизацией, рынок займут другие. Нужен некий баланс.
А вот чтоб соблюдать этот баланс, как раз и нужен опыт. Чтоб хоть и сделать прототип не за месяц, а за полгода, но зато этот прототип потом за месяц пойдет сразу в продажи, и мы не потеряем 2 года на избавление написанного за месяц прототипа от багов. N>Вот и получается, что в компаниях первого типа важнее фундаментальные знания, а в компаниях третьего типа главное — владение технологиями. Enterprise-сектор — нечто среднее.
Важны для чего? Я писал требования для ключевых людей. Фундаметнальные знания, технологии — это важно для недавних студентов, на рядовые и младшие позиции, в качестве замены опыта.
Здравствуйте, elmal, Вы писали:
E>Важны для чего? Я писал требования для ключевых людей. Фундаметнальные знания, технологии — это важно для недавних студентов, на рядовые и младшие позиции, в качестве замены опыта.
Тогда все ваши рассуждения мимо "срача про собеседования", т.к. в основном как раз обсуждают и критикуют собеседования на рядовые позиции.
On 20.03.2013 13:50, nile wrote:
> E>Важны для чего? Я писал требования для ключевых людей. Фундаметнальные > знания, технологии — это важно для недавних студентов, на рядовые и > младшие позиции, в качестве замены опыта. > Тогда все ваши рассуждения мимо "срача про собеседования", т.к. в > основном как раз обсуждают и критикуют собеседования на рядовые позиции.
Да ладно. Недавно тут только было про каких-то архитекторов и палиндромы
на бумажке проверять.
Я кстати кажется придумал как это сделать — берёшь бумажку в клеточку,
пишешь слово на последней строчке, складываешь бумажку пополам (по
половине слова), разрываешь по сгибу и переворачиваешь вторую часть
вверх ногами, так, чтобы первая буква в первой части совпала с последней
со второй.
Осталось придумать как на бумажке перевернуть список, но боюсь без
оригами тут не обойтись.
Здравствуйте, nile, Вы писали:
N>Вот и получается, что в компаниях первого типа важнее фундаментальные знания, а в компаниях третьего типа главное — владение технологиями. Enterprise-сектор — нечто среднее.
Этот список составлен не из того, что реально важно, а из того, что спрашивают на собеседованиях. Все эти Гуглы и Микрософты, их собеседование — это скорее традиция, нежели показатель реальных требований. Почему? Да потому что как только возник серьезный конкурент в лице Apple, спасители гномов не помогли MS слить рынок. Так что мое мнение, по-крайней мере Микрософту надо менять свою систему, делать ее гибче. Отбирать людей не только за умение строить красно-черные деревья, но еще и, как минимум, обеспечивать высокое качество итоговой продукции. А то порой поглядишь, чего понаделали в WPF, так и фигеешь, какой толк аж в четырех интервьюерах.
Здравствуйте, elmal, Вы писали:
E>Напишу свое ИМХО. Причина всех срачей одна — разным компаниям требуются различные специалисты.
И при этом у многих компаний не хватает технологического развития, бизнесс процессов, репутации и денег, что бы нанимать "различных специалистов". Ожидания работодатели и работника не находятся в соответствии, что порождает срач. Были тут обсуждения о том, что хотят квалифицированных людей, а сами комитят всё в транк свн всей толпой и потом ругаются друг с другом. А вроде и денег готовы платить.
Здравствуйте, elmal, Вы писали:
E>Напишу свое ИМХО. Причина всех срачей одна — разным компаниям требуются различные специалисты. Например:
... E>Все это я к тому, что не нужно грести всех под одну гребенку. Далеко не факт, что тот, у кого опыт из пункта 3, будет бесполезен в пункте 1 — он ведь может за счет навыков и умения изолировать детали тоже выполнять задачи вполне хорошо. Ему единственное, что не нужно вставлять палки в колеса в виде ограничений на рефакторинг. И наоборот, человек с опытом из пункта 1 может оказаться полезным в компаниях третьего типа, хоть и не на ключевых позициях. Соответственно нужно не тупо фильтровать, а смотреть, где человек может принести пользу, искать сильные стороны, а не слабые. Ибо на практике недостатки могут оказаться достоинствами. Если так делать, то выгодно будет всем.
Судя по выделенному все опять свелось к неправильным собеседователям.
У меня же есть другое обьяснение.
На самом деле нет проблемы неправильных собеседователей. Там где не надо тупо фильтровать там и не фильтруют.
Есть другая проблема — проблема прохождения собеседования некоторыми вполне конкретными людьми.
Ну и конечно же есть проблема поиска хороших работников, так как хорошего всегда мало и на всех не хватает
А вот попытка связать эти две проблемы вместе дает видимость некоего парадокса и почву для бурного обсуждения.
А обьяснение тут очень простое — опыт и умение чего-то делать еще не означает того, что человек будет это делать и будет это делать хорошо.
С ростом опыта мотивировать человека все сложнее а опухшее ЧСВ может этот опыт сделать никому не нужным.
Ну не нужен работник, которого на коленях надо упрашивать что-то сделать, даже если он самый лучший спец. Безотносительно к технике.
Исключения конечно бывают, но это именно исключения.
Здравствуйте, nile, Вы писали:
N>Тогда все ваши рассуждения мимо "срача про собеседования", т.к. в основном как раз обсуждают и критикуют собеседования на рядовые позиции.
Под рядовыми я подразумеваю случай, когда нужен человек выполнять грязную рутинную работу. С материальными претензиями тысяч 50 рублей максимум, и с соответствующим опытом. И за которым нужно следить.
По идее, зарплата штук эдак от 100 предполагает, что человек будет самостоятельный. Соответственно предполагается, что он будет сидеть не на рутине, а выполнять достаточно ответственную работу. И если он ошибется концептуально, то там для фикса будет нужно не реплейс LinkedList на ArrayList сделать или функцию хешкода поправить, а полсистемы переписывать, причем с нуля. И таких людей, у которых должна быть привычка думать о том, как не допускать концептуальных ошибок, должно быть большинство — один мегагуру за всеми хрен уследит, ему тоже работать нужно.
Вот пример могу привести. Тот, кто в совершенстве умеет переворачивать список, какого то черта начал играть в битовыжималку, и вместо сначала отдельной сериализации, а потом в унифицированной обработке этой последовательности байт, захреначил это все вместе логикой на куче ifов. И при этом нагородил абстрактных фабрик, в результате на ровном месте черт ногу сломит. И вот понадобилось небольшое изменение, когда я хочу сначала руками сериализовать, потом к этой последовательности байт еще несколько байтов добавить, а потом обработать — какого то черта я не могу это сделать несмотря на эти все фабрики. Хорошо еще что это в маловажном модуле, который написал раз и забыл, в результате это не так уж и критично. Но дай самостоятельность в рамках всей системы, и будет полный капец, через год проще будет все с нуля переписывать.
Здравствуйте, elmal, Вы писали:
AJD>>1) Продуктовые компании, или компании которые годами работают над одним продуктом. AJD>>2) Сделал-проект-и-забыл компании. в основном аутсосинг. E>Аутсорсинг тоже может годами работать над одним проектом. Причем лет 10. Отличие такого аутсорса от продуктового — что клиент один, продукт массовым не будет никогда.
Нет там никакой разницы. Точнее она может и есть но не в этом. Сколько клиентов заботит в основном в смысле ЧСВ.
Ну вот для примера: пилят люжи какую-то нишевая утилиту.
Одни ну оооочень коробочно продают лицензии всем желающим (обоим) и выкатывают фичи по просьбым оного комьюнити — а куда деваться то?
А другие мерзко-гадко-опенсорсно делают её для конечного клиента(миллион инсталяций в каждом офисе) а спеки спускаются сверху.
Разница колосальная!
E>В случае же продуктовой компании, то если ты сэкономил кучу ресурсов, сделал один то, что рассчитывали делать силами 10 человек, и потом твое решение легко саппортить — это гарантированное признание и уважение начальства. Соответственно если ты делаешь все максимально прямо, то компания получит дополнительную прибыль, а не убытки.
У вас аутсорс жопочасов находится в реальном мире, а отдел "продуктовой" компании — в стране эльфов.
Если мы поместим и первых в Волшебную страну, то за экономию ресурсов растроганный закачик завалит их бонусами, рекомендациями а рейт часа мнгновенно превысит все мыслимые пределы.
Ну а если оба у нас, Нео, окажутся в реальном мире, то манагеры/сейлзы запоют соловьями, рассказывая приёмщку/заказчику/начальнику какая была тяжёлая задача и как им пришлось нанять еще 100 прогеров, а раз так, то неплохо было бы увеличить бюджеты, дать бонусы и профсоюзную путёвку на воды в Баден для поправки нервов.
Поэтому в "продуктовых" компаниях сплошь и рядом один отдел сидит на бобах, потому что у них и так всё Ок а начальство другого с макаронным монстром вместо проекта впереди планеты всей, ведь там штат over 9K и то не справляются. Но работа кипит, овертаймы, гвозди бы делать из. Как не поощрить таких молодцов?
А вообще мысль "смотреть, где человек может принести пользу, искать сильные стороны, а не слабые" она абстрактно правильная и правильная весьма. В бесконечно большой компании для абсолютно круглого кандидата найдётся подходящее место. Как только это на практику положить?..
Здравствуйте, MxMsk, Вы писали:
MM>Почему? Да потому что как только возник серьезный конкурент в лице Apple, спасители гномов не помогли MS слить рынок.
Рынок чего? У MS никогда не было большой доли на мобильном рынке. На рынке операционок Apple не конкурент.
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Здравствуйте, elmal, Вы писали:
E>Имеется в виду, что требуемую квалификацию весьма и весьма проблематично получить к указанному возрасту. Соответственно если человеку 23 года, он сеньер в аутсорсе, то вызывают большие сомнения то, что он обладает требуемой квалификацией для ключевого сотрудника продуктовой компании.
На каждый случай, когда возраст 23 намекает на недостаток скилов для сеньора и тем самым помогает тебе, приходится другой случай, когда возраст 33 активно маскирует точно такой же недостаток и обманывает тебя. А также третий случай, когда возраст 43 совершенно несправедливо подсказывает отказать “все еще джуниору”. Не надо смотреть на возраст вообще.
Тот, кто прибегает к оценке возраста, пола, национальности и тому подобным деревенским эвристикам, просто не умеет эффективно анализировать опыт и проверять скилы.
1. Различие между продуктовыми компаниями и аутсорсом ортогонально всему чему только можно.
2. Майкрософт опустим, но гугловые продукты, судя по тому как они работают и релизятся, делают студенты и гномики. Не могут 40-летние такое делать, нет, я не верю в это.
MM>Да потому что как только возник серьезный конкурент в лице Apple, спасители гномов не помогли MS слить рынок. Так что мое мнение, по-крайней мере Микрософту надо менять свою систему, делать ее гибче. Отбирать людей не только за умение строить красно-черные деревья, но еще и, как минимум, обеспечивать высокое качество итоговой продукции. А то порой поглядишь, чего понаделали в WPF, так и фигеешь, какой толк аж в четырех интервьюерах.
Проблемы Microsoft отнюдь не в том, что у нее плохие программисты. Ну измените вы собеседование. Наберут других людей. Но... это не сделает опоздавшую к разделу пирога Win8 Phone более успешной.
Поймите простую вещь: программисты (качество, количество, крутизна) перестали быть определяющим фактором. Мода, маркетинг, впаривание, зомбирование, фанатизм и прочие подобные материи — вот он, ключик к квартире, где деньги лежат.
А программисты... да какая разница, гномиков они переворачивают, или в уме дифуры решают. Каких бы вы программистов не дали в Симбиан, он как был г...ом, так им и останется, потому что не программисты определяют направление развития.
