Здравствуйте, 0x7be, Вы писали:

0>Сейчас мне нужны именно "решатели проблем". Хотелось бы поинтересоваться у сообщества, какие маркеры в резюме и на собеседовании у вас есть для выявления таких кандидатов?

Шутки в сторону. Тебе нужен тот, кого называют емким словом "инженер". Это такие специально обученные люди, которые умеют находить наиболее оптимальное решение задач и проблем реального мира при помощи всего своего багажа научных и технических знаний, при необходимости углубляя и расширяя его.
Беда в том, что наш век гномиколожества настоящих инженеров в IT сфере нужно очень долго и упорно искать.

Здравствуйте, 0x7be, Вы писали:

0>Коллеги,
0>хочу вбросить вопрос тем, кто набирает разработчиков.

0>Преамбула.
0>По работе я сталкивался с разными людьми с точки зрения их отношения к работе. Сильно упрощая можно разделить их на узких технарей, которым в первую очередь интересны технологии, и на "решателей проблем", которые рассматривают технологии лишь как средство. Как правило первые имеют более глубокую техническую подготовку, но у них "провал" в soft skills. Вторые, как правило, имеют более широкую техническую подготовку и лучше в плане коммуникаций, problem solving и т.п.

0>Сейчас мне нужны именно "решатели проблем". Хотелось бы поинтересоваться у сообщества, какие маркеры в резюме и на собеседовании у вас есть для выявления таких кандидатов?
Решатели проблем обычно в программистах не засиживаются и идут либо в менеджеры, либо открывают компании. Ищите партнеров и будет вам счастье. Сам всю программистскую жизнь имел обратную проблему: был "решателем проблем", но натыкался на одно из двух:
1. Компании нужны решатели проблем, но в компании нет денег. Т.е. как подработка живущему с родителями студенту сойдет, но не более. Выбить деньги, хотя бы на уровне среднего по рынку — уже огромное достижение.
2. У компании есть деньги, но тут нужны командные люди. На практике это означает, что начальник любит руководить и ощущать себя мозгом команды/отдела, а остальных — инструментом в своих руках. Поэтому нужны люди, которые будут с неподдельным рвением дословно исполнять каждое мудрое указание, всем своим видом показывая, что без его лучезарного сиятельства сами бы до этого не додумались. Ну, пока начальник на них смотрит, разумеется. Если продемонстрировать способность решать проблемы, в вас увидят конкурента и начнут ставить палки в колеса.
Поэтому, ИМХО, если человек имеет опыт и умеет решать проблемы, он не будет искать работу программиста...

D>>Он должен быть редкостным пофигистом. Если не пофигист -- сразу отказать.
0>Глубокая мысль, я не осилил
0>Раскроешь тему?

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

Здравствуйте, 0x7be, Вы писали:
0>Сейчас мне нужны именно "решатели проблем". Хотелось бы поинтересоваться у сообщества, какие маркеры в резюме и на собеседовании у вас есть для выявления таких кандидатов?
Дать проблему и посмотреть, как человек будет ее решать?

D>А из твоей классификации получается, что "решателям проблем" похрен на инструмент, дашь им лом — они и ломом будут радостно плац подметать.

Немного не так.
"Решателям" не дают лом. Решателям дают проблему: "подмести плац". Решатель сам найдет подходящий для этого инструмент. Ему плац убрать надо. В то же время техногик изобретет супер-фреймворк супер-метлу. К сожалению, метла эта больше нигде не нужна (потому что в процессе разработки сама собой получилась заточка строго под этот плац).

Здравствуйте, 0x7be, Вы писали:

0>Сейчас мне нужны именно "решатели проблем". Хотелось бы поинтересоваться у сообщества, какие маркеры в резюме и на собеседовании у вас есть для выявления таких кандидатов?

Никакие. Решатели проблем на собеседованиях нынче оказываются очень и очень редко.

А чего это вдруг soft skills и "техническая подготовка" противопоставляются друг другу? Мне кажется все немного наоборот, большинство технарей из тех, что мне доводилось встречать, с "провалом" в soft skills — были так себе специалистами. Стереотипный гениальный программист, не умеющий внятно выражать свои мысли и общаться с людьми, это миф.

Здравствуйте, Олег К., Вы писали:

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

Так ведь выбирать нужно не по вкусу, а по необходимости. landerhigh уже сказал, что нужен инженер. Вот этот самый инженер должен будет выбирать, каким инструментом лучше решить задачу. Причём в списке требований к инструменту не только простота и скорость разработки, но и простота поддержки. Например, я бы думал так:

1. Дали задачу, ок.
   
2. А готовое решение есть?
   
3. Если есть, то насколько легко его можно применить?
   
4. Если легко применить мне, насколько лего его поддерживать другим людям?
   
5. А какое качество реализации у готового решения?
   
6. Время внедрения готового решения не будет ли больше, чем время разработки своего велосипеда?
   
7. А поддержка этого решения не сложнее ли поддержки самописного решения?
   
8. Если решения нет, то будем делать сами.
   
9. А какими инструментами пользоваться? Какой язык, фреймворк?
   
10. А если самый подходящий инструмент для разработки решения знаю только я? Может стоит взять менее подходящий инстумент, но которым владеет ещё кто-то в компании?
    
11. Или цена обучения ещё одного человека меньше, чем цена разработки на других инструментах?
    
12. А задачу решать с узкой специализацией только под один проект?
    
13. А если схожая задача стоит в других проектах, может стоит делать более универсальное решение сразу?
    
14. Или быстро слепить решение, и посмотреть, подходит ли такой метод вообще, потому что в другом проекте этот подход не подойдёт?
    
15. А если для такого типа задач есть специальные языки и фреймворки, но я их не знаю, то стоит ли их изучать?

И так далее. Чем больше и сложнее задача, тем длиннее список. Если задача на пару дней, то анализ сводится только к нескольким вопросам.

ОК>Я думаю он под пофигизмом имел в виду зрелость которая в большинстве случаев приходит с возврастом (и то не ко всем). Например пофигист не будет считать себя самым умным и сыпать тысячу левымх вопросов на интервью, пофигист не будет лепить паттерны на паттерне, пофигист не будет фигачить мега-архитектуру и прочее. Имхо в любой работе должна быть здоровая доля пофигизма. Иначе каждый непофигист будет тянуть в свою сторону, и получатся лебедь, щука и рак.
Главное не путать такой конструктивный пофигизм с пофигизмом ко всему. Ибо изначальным маркером решателя проблем именно является заинтересованность к решению проблем. Тут наверное и зарыт кенгуру: главное изначальный вектор направленности интереса индивида — на сам процесс созидания или его практический результат. Наверное еще в глубоком детстве можно заметить разницу в игре с кубиками там или еще чем...

Здравствуйте, bazis1, Вы писали:

B>Чувак купит у нас VisualGDB и будет писать под Линукс в Вижуал Студии.

А тож! Гланды через анус завсегда удобнее удалять

Самую сложную задачу я поручу решать самому ленивому программисту.
Билл Гейтс

то есть, я думаю, нужно заменить "пофигизм" на "лень в положительном смысле"
с "маркерами" такой лени, наверное, будет проще?
простое лучше сложного
готовое лучше велосипеда
минимальные переделки лучше, чем "с нуля"
YAGNI! YAGNI!! YAGNI!!!
но главное — все-таки — уметь не найти/выбрать готовое, а именно сделать (скомбинировать из частей) это самое простое решение
то есть необходимо умение хорошо комбинировать — а это уже не маркер, хотя и может выявиться в беседах о прошлых проектах, но больше все-таки на практике
подходящий тест может оказаться слишком сложным — тогда либо оплаченный тест (как вариант, с возможностью применения его результата с пользой для компании), либо уже испытательный срок

Здравствуйте, 0x7be, Вы писали:

0>Коллеги,
0>хочу вбросить вопрос тем, кто набирает разработчиков.

0>Преамбула.
0>По работе я сталкивался с разными людьми с точки зрения их отношения к работе. Сильно упрощая можно разделить их на узких технарей, которым в первую очередь интересны технологии, и на "решателей проблем", которые рассматривают технологии лишь как средство. Как правило первые имеют более глубокую техническую подготовку, но у них "провал" в soft skills. Вторые, как правило, имеют более широкую техническую подготовку и лучше в плане коммуникаций, problem solving и т.п.

0>Сейчас мне нужны именно "решатели проблем". Хотелось бы поинтересоваться у сообщества, какие маркеры в резюме и на собеседовании у вас есть для выявления таких кандидатов?

Работаю программистом-"решателем проблем" Незавидная доля для Software рынка, скажу я вам Как уже сказали выше — даже когда компании действительно нужны именно решатели — ищут все равно стандартным способом, как "копателя-в-направлении", с 10+ лет опыта в баззвордах XYZ. Решатель проблем по определению под эти требования не подходит, в итоге хорошая работа находится редко, и либо через знакомых, либо случайно после кучи попыток. А хочется как и всем — много денег, интересных проектов, и не лезть в менеджмент

Был опыт удачного собеседования в крупной амерской компании, как раз случай когда людям нужен был решатель. Что было:
— Algorithms/data structure задачки в псевдокоде, с активным обсуждением. Цель — именно обсудить/поговорить, а не компилируемый код без ошибок ровным почерком. Детали — как и что стоит имплементировать на языке XYZ — можно спросить на ходу, если это важно. Ну и не 5-6 интервью по часу, а пара задач и не больше 2х часов на все про все.
— Много бесед про предыдущие проекты и решенные проблемы соискателя, в разных плоскостях. Что и как было сделано, почему применялись такие-то инструменты итп.
— Рассказать решателю про свои проблемы, поговорить на тему как можно эти проблемы решить. Показать код, диаграммки, как работает продукт. Решателю интересно решать проблемы, он привык изучать и анализировать кучу новой информации, сразу вцепится в "свежатинку" — по его суждениям и предложениям можно будет многое понять.

Здравствуйте, SkyDance, Вы писали:

SD>В подавляющем большинстве случаев такие люди и не нужны. Швец, жнец, на дуде игрец — все это хорошо, но требуются, как правило, знания только в 1-2, реже 3 областях.

(ухмыляется) А по диким спискам требуемых скиллов в вакансиях и не скажешь...

Здравствуйте, dimgel, Вы писали:

SD>>Решатель сам найдет подходящий для этого инструмент. Ему плац убрать надо.

D>А это уже — приём демагогии под названием "доведение до абсурда".
Тем не менее, беда с овердизайном, никак не приложенным к реальной проблеме, на практике имеется. Это то, чего я не хочу получить с кандидатом.

Здравствуйте, Олег К., Вы писали:

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

D>>И? А что предлагаешь-то? Взять общий знаменатель — пхп лом какой-нибудь, чтобы все заткнулись, и писать как завещал Макконнел — "не на языке, а с использованием языка"?

ОК>Нужно уметь решать задачи в рамках технологий которые используются в компании. Например в компании вся разработка ведется под Линуксом. А тут прийдет чувак и скажет что ему проще решить задачу в Вижуал Студии и потому давайте-ка будем использовать Майкрософтовские технологии. Это как пример. Куда такое годится? И так, представь, каждый!
Чувак купит у нас VisualGDB и будет писать под Линукс в Вижуал Студии.

Здравствуйте, kaa.python, Вы писали:

KP>.... выделить тестовую задачу на неделю и дать ее, оплатив как полноценную работу, понравившемуся кандидату.

А не понравившемуся? А как кандидат заранее узнает — "понравится" он или "не понравится"? Любой вменяемый разработчик не будет просто так тратить неделю своего времени на тестовое задание, это уже стопицот раз тут обсуждали. За эту неделю — он просто найдет другую работу, у более вменяемого работодателя.

D>Логично. Зная, что после твоего ухода плац будут подметать люди, ничего кроме лома не видевшие, — юзай лом. Решай задачу, ага. Не тратиться же руководству, в самом деле, на более дорогих, прости господи, "спецов", знающих жаву?

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

D>Сказать по правде, нормально (а не вот так вот

Автор: dimgel
Дата: 25.04.14

) освоить даже PHP — тоже прорва времени нужна.

В этом и состоит умение решить задачу: изучить и применить инструмент ровно настолько, насколько это требуется. Причем изучить эффективно — с помощью тех, кто уже знаком с инструментом и знает, где разложены грабли. Это, конечно, не столь увлекательно, как пилить свои ORM'ы в собственном соку. Зато решается бизнес-проблема.

D>Короче, не надо мне тут адвокатодьявольствовать про то, что нормальный спец сможет решить задачу на любой технологии. Чаще всего наоборот: и не сможет (спец. по графическим движкам enterprise-систему не напишет), и не захочет (деградировать).

Это только в вашем собственном мире изучить другое направление программирования есть деградация. В моём же проекте я предпочту взять человека, который знает больше разных инструментов. Чем покусанного Александреску фаната единственного языка.

D>Поэтому, кстати, прозвучавшее тут где-то утверждение, что по баззвордам отбирают потому что по-другому не умеют — бред. Какой смысл искать C#-программиста в PHP-контору?

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

Здравствуйте, 0x7be, Вы писали:

0>Коллеги,
0>хочу вбросить вопрос тем, кто набирает разработчиков.

0>Преамбула.
0>По работе я сталкивался с разными людьми с точки зрения их отношения к работе. Сильно упрощая можно разделить их на узких технарей, которым в первую очередь интересны технологии, и на "решателей проблем", которые рассматривают технологии лишь как средство. Как правило первые имеют более глубокую техническую подготовку, но у них "провал" в soft skills. Вторые, как правило, имеют более широкую техническую подготовку и лучше в плане коммуникаций, problem solving и т.п.

0>Сейчас мне нужны именно "решатели проблем". Хотелось бы поинтересоваться у сообщества, какие маркеры в резюме и на собеседовании у вас есть для выявления таких кандидатов?

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

Здравствуйте, 0x7be, Вы писали:

0>Сейчас мне нужны именно "решатели проблем". Хотелось бы поинтересоваться у сообщества, какие маркеры в резюме и на собеседовании у вас есть для выявления таких кандидатов?

теперь вам нужно определиться с тем какие именно решатели проблем вам нужны и на какой срок
1. начинающие неопытные решатели проблем на постоянную ставку
2. решатели с опытом на постоянную ставку
3. решатели без опыта в качестве консультатов

вот методы поиска с нумерацией соответствующей списку выше
1. ищите людей как бы на девелоперские позиции, но в процессе серьезного личного (!) доброжелательного (!) разговора четко выясняйте, кто в будущем планирует открыть собственную компанию, у кого список интересов не заканчивается на программировании и т.д.
и вот тут резко предлагайте "а давайте мы вас прямо в нашей компании возьмем на роль решателя проблем с зарплатой в полтора раза выше той, что указана в объяве о вакансии? не хотите попробовать?" и смотрите на реакцию человека, а еще готовьте много денег на пустые траты

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

3. по рекомендациям,
и готовьте много денег на пустые траты

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

"нерешательские" варианты — кайф от того, что всё сделано идеально, красиво, правильно, удобно, по стандарту

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

Здравствуйте, 0x7be, Вы писали:

0>Сейчас мне нужны именно "решатели проблем". Хотелось бы поинтересоваться у сообщества, какие маркеры в резюме и на собеседовании у вас есть для выявления таких кандидатов?

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

Здравствуйте, kaa.python, Вы писали:

KP>Ты принципиально не читаешь пост перед тем как отвечать? Я же сказал: полностью оплачиваемое.

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

KP> выделить тестовую задачу на неделю и дать ее, оплатив как полноценную работу, понравившемуся кандидату

твои слова интерпретируются примерно так:

1. выделить задачу и дать её
   
2. оплатить, как полноценную, понравившемуся

А вот если переставить слова иначе

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

интерпретировать будет проще

Здравствуйте, 0x7be, Вы писали:

0>Сейчас мне нужны именно "решатели проблем". Хотелось бы поинтересоваться у сообщества, какие маркеры в резюме и на собеседовании у вас есть для выявления таких кандидатов?
Проблемы бывают разные, следовательно и люди могут быть разные нужны. Решатель проблем — слишком широко, даже если ты назовешь эту проблему "технической проблемой".
Поэтому прежде чем искать людей нужно определиться какие именно проблемы они будут решать.
Любая айтишная проблема может иметь различные причины сложности:
— чисто технически сложная задача,
— коммуникационная сложность (типично для крупных компаний, все знают о системе по чуть-чуть и никто ни знает систему в целом),
— сложный бизнес, нужно хорошо разобраться с бизнесом, прежде чем решать проблему,
— организационная сложность,
— операционная сложность
и т.д.

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

B>Ээээ, консалтеров с контракторами не путаем, да? А праздное теоретизирование помогает в осмыслении, если не перегибать палку. Как известно, описать проблему словами — половина ее решения.

Не путаю. Одна и та же фигня. Все тот же наемный работник, но от консалтеров/контракторов можно избавиться когда работа сделана. С постоянными работниками так просто не получится.

Здравствуйте, Олег К., Вы писали:

B>>Ээээ, консалтеров с контракторами не путаем, да? А праздное теоретизирование помогает в осмыслении, если не перегибать палку. Как известно, описать проблему словами — половина ее решения.

ОК>Не путаю. Одна и та же фигня. Все тот же наемный работник, но от консалтеров/контракторов можно избавиться когда работа сделана. С постоянными работниками так просто не получится.
Не берусь говорить за всех, т.к. сам этот этап проскочил довольно быстро. Пусть форумные консалтеры меня поправят. А что касается "избавиться", я бы это назвал преимуществом. Если реальной работы нет, а постоянники есть, их обычно заваливают всякой ненужной фигней вперемешку с офисной политикой и часто бывает, что человек осознает года через три, во что вляпался, а навыки программирования он уже забыл и нормальную работу фиг теперь найдет. И менеджмент это прекрасно понимает и унижает подобных людей с утроенной силой. Видел много подобных примеров на одном из последних мест работы...

Здравствуйте, 0x7be, Вы писали:

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

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

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

0>Сейчас мне нужны именно "решатели проблем". Хотелось бы поинтересоваться у сообщества, какие маркеры в резюме и на собеседовании у вас есть для выявления таких кандидатов?

Возьмём меня, например. Я за последние лет 5-10 ухитрился изучить одну единственную вещь: scala. С одной стороны, я теперь презираю всё, где нет ФП и МП; а с другой — я как был прикладнушником-формоклепателем, так и остался, и вот сейчас пилю себе ORM на макросах (с кучей архиполезных для меня фичей, которых в общедоступных аналогах нет) — с огромным трудом пилю, с досадой осознавая, насколько формоклёпство выело мне мозг. Но прикладнушество-формоклёпство — это и есть "решение проблем". Просто scala показала мне, насколько сильно я могу упростить себе жизнь выбором хорошего инструмента.

L>Стереотипный гениальный программист, не умеющий внятно выражать свои мысли и общаться с людьми, это миф.

Миф, не миф, но в западных странах программистов из России примерно так и воспринимают

B>Поэтому, ИМХО, если человек имеет опыт и умеет решать проблемы, он не будет искать работу программиста...

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

Здравствуйте, SkyDance, Вы писали:

B>>Можно. Только "решатель проблем в области программирования" — это консалтер. А задача именно программиста в большинстве компаний, увы, копать в направлении, показанном менеджером.

SD>Как консалтер, смею утверждать, что направление раскопок консалтера также указывается нанимателем. В общем случае разницы между консалтером и программистом нет, но есть некий дьявол в деталях. К "решению проблем" не относится.
Хм. Попробую переформулировать. Консалтера обычно ищут с формулировкой "нам нужен такой-то результат, найди способ его получить и предоставь нам результат". Программиста обычно ищут с формулировкой "мы прекрасно знаем, что надо сделать и как это надо сделать, но сделать самим — не по чину, поэтому нужен Вася с лопатой, который будет получать указания и претворять их в жизнь".

Здравствуйте, Faland, Вы писали:

F>Здравствуйте, 0x7be, Вы писали:

0>>Коллеги,
0>>хочу вбросить вопрос тем, кто набирает разработчиков.
...
более глубокую техническую подготовку, но у них "провал" в soft skills. Вторые, как правило, имеют более широкую техническую подготовку и лучше в плане коммуникаций, problem solving и т.п.

0>>Сейчас мне нужны именно "решатели проблем". Хотелось бы поинтересоваться у сообщества, какие маркеры в резюме и на собеседовании у вас есть для выявления таких кандидатов?

F>Работаю программистом-"решателем проблем" Незавидная доля для Software рынка, скажу я вам Как уже сказали выше — даже когда компании
...
F> — Рассказать решателю про свои проблемы, поговорить на тему как можно эти проблемы решить. Показать код, диаграммки, как работает продукт. Решателю интересно решать проблемы, он привык изучать и анализировать кучу новой информации, сразу вцепится в "свежатинку" — по его суждениям и предложениям можно будет многое понять.

Поддерживаваю Faland. Сам занимался решением проблем тоже больше 10 лет, на работе числюсь инженером.

0>Пробовал, просто мне интересен опыт других людей.

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

0>Только, наверное, тут надо не о технологиях говорить.

Обо всем нужно поговорить, но тут не имелось в виду что нужно спрашивать как работает сборщик мусора в .НЕТе, например. Наоборот, имелось в виду понимание что нужно а что не нужно для работы.

ОК>>В общем много о чем можно поговорить и следует помнить что интервью прежде всего должно быть высокоуровневым а не экзаменом но тонкости платформы или решения тупых задачек.
0>+1

D>И? А что предлагаешь-то? Взять общий знаменатель — пхп лом какой-нибудь, чтобы все заткнулись, и писать как завещал Макконнел — "не на языке, а с использованием языка"?


Так ведь и это тоже бывает. Зная, что после твоего ухода систему будут поддерживать люди, которые кроме как на PHP, больше ни на чем не могут — пиши на PHP. В чем проблема-то? Не осилишь освоить PHP, что ли?

Здравствуйте, Олег К., Вы писали:

ОК>С производительностью у него тоже неплохо.

У PHP-то? Согласен, на счётах медленнее было бы.

Здравствуйте, 0x7be, Вы писали:

0>Сейчас мне нужны именно "решатели проблем". Хотелось бы поинтересоваться у сообщества, какие маркеры в резюме и на собеседовании у вас есть для выявления таких кандидатов?

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

Здравствуйте, Vlad_SP, Вы писали:

V_S>А не понравившемуся?

А не понравившегося сразу в лес.

V_S>А как кандидат заранее узнает — "понравится" он или "не понравится"?

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

V_S>Любой вменяемый разработчик не будет просто так тратить неделю своего времени на тестовое задание, это уже стопицот раз тут обсуждали.

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

V_S>За эту неделю — он просто найдет другую работу, у более вменяемого работодателя.

Вменяемые работодатели такая же редкость как и вменяемые кандидаты

KP>Надеюсь ты понимаешь что мы говорим про РФ и практика тут отличается от практики в АУ?

И какая в РФ практика коротких контрактов?
Попробуй объяснить доступным языком, зачем сильному разработчику тратить неделю непонятно на что, да еще и без гарантии результата? Ему что, нечем больше заняться?

Коллеги,
хочу вбросить вопрос тем, кто набирает разработчиков.

Преамбула.
По работе я сталкивался с разными людьми с точки зрения их отношения к работе. Сильно упрощая можно разделить их на узких технарей, которым в первую очередь интересны технологии, и на "решателей проблем", которые рассматривают технологии лишь как средство. Как правило первые имеют более глубокую техническую подготовку, но у них "провал" в soft skills. Вторые, как правило, имеют более широкую техническую подготовку и лучше в плане коммуникаций, problem solving и т.п.

Сейчас мне нужны именно "решатели проблем". Хотелось бы поинтересоваться у сообщества, какие маркеры в резюме и на собеседовании у вас есть для выявления таких кандидатов?

Здравствуйте, 0x7be, Вы писали:
0>По работе я сталкивался с разными людьми с точки зрения их отношения к работе. Сильно упрощая можно разделить их на узких технарей, которым в первую очередь интересны технологии, и на "решателей проблем", которые рассматривают технологии лишь как средство. Как правило первые имеют более глубокую техническую подготовку, но у них "провал" в soft skills. Вторые, как правило, имеют более широкую техническую подготовку и лучше в плане коммуникаций, problem solving и т.п.

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

0>Сейчас мне нужны именно "решатели проблем". Хотелось бы поинтересоваться у сообщества, какие маркеры в резюме и на собеседовании у вас есть для выявления таких кандидатов?

Просто тупо поговорить не пробовали? О разработке как таковой, о последних тенденциях, что нужно для работы а что нет, что нравится и не нравится, какие архитектурные сложности есть на текущей работе, что можно улучшить в архитектуре и в процесах в компании. Можно спросить что думает о плюсах (дорогой язык) версус другие языки, спросить об отношении к Александреску (не нужна эта хрень) и о тонкостях в .НЕТе (нужно ли это помнить или нет).

В общем много о чем можно поговорить и следует помнить что интервью прежде всего должно быть высокоуровневым а не экзаменом но тонкости платформы или решения тупых задачек.

Здравствуйте, 0x7be, Вы писали:

0>Сейчас мне нужны именно "решатели проблем". Хотелось бы поинтересоваться у сообщества, какие маркеры в резюме и на собеседовании у вас есть для выявления таких кандидатов?

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

Калька с американского solve problem — значит решить задачу. Математическую или логическую (дифуры, гномики, т.п.).

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

Здравствуйте, SkyDance, Вы писали:

B>>Поэтому, ИМХО, если человек имеет опыт и умеет решать проблемы, он не будет искать работу программиста...

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

B>Можно. Только "решатель проблем в области программирования" — это консалтер. А задача именно программиста в большинстве компаний, увы, копать в направлении, показанном менеджером.

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

Здравствуйте, SkyDance, Вы писали:

D>>А из твоей классификации получается, что "решателям проблем" похрен на инструмент, дашь им лом — они и ломом будут радостно плац подметать.

SD>Немного не так.
SD>"Решателям" не дают лом. Решателям дают проблему: "подмести плац".

Ага, конечно. Что-то до сих пор мне если и давали проблему "подмести плац", то с обязательными ограничениями "php или там какая java лом в комплекте".

SD>Решатель сам найдет подходящий для этого инструмент. Ему плац убрать надо.

SD>В то же время техногик изобретет супер-фреймворк супер-метлу. К сожалению, метла эта больше нигде не нужна (потому что в процессе разработки сама собой получилась заточка строго под этот плац).

А это уже — приём демагогии под названием "доведение до абсурда".

0>Преамбула.
0>По работе я сталкивался с разными людьми с точки зрения их отношения к работе. Сильно упрощая можно разделить их на узких технарей, которым в первую очередь интересны технологии, и на "решателей проблем", которые рассматривают технологии лишь как средство. Как правило первые имеют более глубокую техническую подготовку, но у них "провал" в soft skills. Вторые, как правило, имеют более широкую техническую подготовку и лучше в плане коммуникаций, problem solving и т.п.
0>Сейчас мне нужны именно "решатели проблем". Хотелось бы поинтересоваться у сообщества, какие маркеры в резюме и на собеседовании у вас есть для выявления таких кандидатов?
фри/шаро-варщики, не?

Здравствуйте, dimgel, Вы писали:

D>А из твоей классификации получается, что "решателям проблем" похрен на инструмент, дашь им лом — они и ломом будут радостно плац подметать.

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

Здравствуйте, SkyDance, Вы писали:

SD>"Решателям" не дают лом. Решателям дают проблему: "подмести плац". Решатель сам найдет подходящий для этого инструмент. Ему плац убрать надо. В то же время техногик изобретет супер-фреймворк супер-метлу. К сожалению, метла эта больше нигде не нужна (потому что в процессе разработки сама собой получилась заточка строго под этот плац).

К этому нередко еще добавляется требование, что ничего кроме лома использовать нельзя. Завязать лом в узел при этом обычно разрешается, если никому об этом не говорить

Здравствуйте, 0x7be, Вы писали:

0>Сейчас мне нужны именно "решатели проблем". Хотелось бы поинтересоваться у сообщества, какие маркеры в резюме и на собеседовании у вас есть для выявления таких кандидатов?
Он должен быть редкостным пофигистом. Если не пофигист -- сразу отказать.

Здравствуйте, QrystaL, Вы писали:

0>>Сейчас мне нужны именно "решатели проблем". Хотелось бы поинтересоваться у сообщества, какие маркеры в резюме и на собеседовании у вас есть для выявления таких кандидатов?
QL>Дать проблему и посмотреть, как человек будет ее решать?
Теоретически — верно, но как это провести на собеседовании так, чтобы было показательно не совсем ясно.

Здравствуйте, dimgel, Вы писали:

D>А из твоей классификации получается, что "решателям проблем" похрен на инструмент, дашь им лом — они и ломом будут радостно плац подметать.
Из моей классификации ЭТО не получается

Здравствуйте, denisko, Вы писали:

0>>Сейчас мне нужны именно "решатели проблем". Хотелось бы поинтересоваться у сообщества, какие маркеры в резюме и на собеседовании у вас есть для выявления таких кандидатов?
D>Он должен быть редкостным пофигистом. Если не пофигист -- сразу отказать.

Пофигиста трудно заманить на собеседование

Здравствуйте, __kot2, Вы писали:

__>вот и проверяйте коммуникацию в том числе.
Проверяю, конечно.

__>дайте два решения одной и той же задачи (одно характерное для зауканов, второе для ковбоев) и посмотрите, что он скажет по поводу каждого из них
ПМСМ, два готовых решения — слишком закрытый вариант испытания. Скорее уж дать некую модельную проблему и попросить человека описать, как он её будет решать.

Здравствуйте, bazis1, Вы писали:

B>Решатели проблем обычно в программистах не засиживаются и идут либо в менеджеры, либо открывают компании. Ищите партнеров и будет вам счастье.
Согласен, но партнеров искать не могу — сам работаю по найму.

B>Поэтому, ИМХО, если человек имеет опыт и умеет решать проблемы, он не будет искать работу программиста...
Да, таких людей мало

Здравствуйте, Олег К., Вы писали:

ОК>Просто тупо поговорить не пробовали? О разработке как таковой, о последних тенденциях, что нужно для работы а что нет, что нравится и не нравится, какие архитектурные сложности есть на текущей работе, что можно улучшить в архитектуре и в процесах в компании. Можно спросить что думает о плюсах (дорогой язык) версус другие языки, спросить об отношении к Александреску (не нужна эта хрень) и о тонкостях в .НЕТе (нужно ли это помнить или нет).
Пробовал, просто мне интересен опыт других людей.
Только, наверное, тут надо не о технологиях говорить.

ОК>В общем много о чем можно поговорить и следует помнить что интервью прежде всего должно быть высокоуровневым а не экзаменом но тонкости платформы или решения тупых задачек.
+1

0>>Сейчас мне нужны именно "решатели проблем". Хотелось бы поинтересоваться у сообщества, какие маркеры в резюме и на собеседовании у вас есть для выявления таких кандидатов?

L>Шутки в сторону. Тебе нужен тот, кого называют емким словом "инженер". Это такие специально обученные люди, которые умеют находить наиболее оптимальное решение задач и проблем реального мира при помощи всего своего багажа научных и технических знаний, при необходимости углубляя и расширяя его.
L>Беда в том, что наш век гномиколожества настоящих инженеров в IT сфере нужно очень долго и упорно искать.

Согласен: инженер — это то что нужно.
Просто у нас все забыли наши русские названия специальностей.
И все шиворот-навыворот из-за непонимания сути этой специальности: выпускники ВУЗов по специальности "инженер" идут работать простыми программистами

0>Сейчас мне нужны именно "решатели проблем". Хотелось бы поинтересоваться у сообщества, какие маркеры в резюме и на собеседовании у вас есть для выявления таких кандидатов?

надо поискать какие-нибудь тесты,
но по опыту знаю что их найти очень трудно

Здравствуйте, ononim, Вы писали:

O>фри/шаро-варщики, не?
Не, специфика проекта и задач неподходящая.

Здравствуйте, 0x7be, Вы писали:
__>>дайте два решения одной и той же задачи (одно характерное для зауканов, второе для ковбоев) и посмотрите, что он скажет по поводу каждого из них
0>ПМСМ, два готовых решения — слишком закрытый вариант испытания. Скорее уж дать некую модельную проблему и попросить человека описать, как он её будет решать.
я могу предложить обычно минимум два способа решить задачу — по уму и по быстрому. непонятно, что ожидается услышать

Здравствуйте, denisko, Вы писали

D>Он должен быть редкостным пофигистом. Если не пофигист -- сразу отказать.
Глубокая мысль, я не осилил
Раскроешь тему?

E>надо поискать какие-нибудь тесты,
E>но по опыту знаю что их найти очень трудно

Тесты дают потому что больше ничего как дать эти тесты и не умеют.

SD>>"Решателям" не дают лом. Решателям дают проблему: "подмести плац". Решатель сам найдет подходящий для этого инструмент. Ему плац убрать надо. В то же время техногик изобретет супер-фреймворк супер-метлу. К сожалению, метла эта больше нигде не нужна (потому что в процессе разработки сама собой получилась заточка строго под этот плац).

Pzz>К этому нередко еще добавляется требование, что ничего кроме лома использовать нельзя. Завязать лом в узел при этом обычно разрешается, если никому об этом не говорить

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

SD>>Как консалтер, смею утверждать, что направление раскопок консалтера также указывается нанимателем. В общем случае разницы между консалтером и программистом нет, но есть некий дьявол в деталях. К "решению проблем" не относится.
B>Хм. Попробую переформулировать. Консалтера обычно ищут с формулировкой "нам нужен такой-то результат, найди способ его получить и предоставь нам результат". Программиста обычно ищут с формулировкой "мы прекрасно знаем, что надо сделать и как это надо сделать, но сделать самим — не по чину, поэтому нужен Вася с лопатой, который будет получать указания и претворять их в жизнь".

Ты толковый чувак, но часто, бывает, теоретизируешь. Консалтеров нанимают по одной причине — чтобы дать пинка под зад когда он больше не нужен. Это единственная разница между постоянным работником и консалтером.

Здравствуйте, Олег К., Вы писали:

Pzz>>К этому нередко еще добавляется требование, что ничего кроме лома использовать нельзя. Завязать лом в узел при этом обычно разрешается, если никому об этом не говорить

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

Ну да, я примерно про это и говорю.

Здравствуйте, bazis1, Вы писали:

B>Решатели проблем обычно в программистах не засиживаются и идут либо в менеджеры, либо открывают компании.

Это если они не пофигисты

Автор: denisko
Дата: 17.06.14

.

Здравствуйте, 0x7be, Вы писали:

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

Согласен. Но и беда с полным отсутствием дизайна не менее распространена

Автор: dimgel
Дата: 25.04.14

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

Здравствуйте, Олег К., Вы писали:

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

И? А что предлагаешь-то? Взять общий знаменатель — пхп лом какой-нибудь, чтобы все заткнулись, и писать как завещал Макконнел — "не на языке, а с использованием языка"?

Здравствуйте, 0x7be, Вы писали:

0>Здравствуйте, dimgel, Вы писали:

D>>А из твоей классификации получается, что "решателям проблем" похрен на инструмент, дашь им лом — они и ломом будут радостно плац подметать.
0>Из моей классификации ЭТО не получается

Получается-получается: ты противопоставляешь две вещи, которые должны сосуществовать вместе. Тут пишут, что мол тебе нужен инженер. Но инженер — это творческая профессия, он по определению должен иметь банальный вкус, некое эстетическое чутьё — и к решению в целом, и к выбору инструмента в частности, иначе это не инженер, а копатель-от-забора-и-до-обеда. Но ведь тебе на самом деле нужны как раз копатели, не так ли?

Здравствуйте, Олег К., Вы писали:

SD>>>Как консалтер, смею утверждать, что направление раскопок консалтера также указывается нанимателем. В общем случае разницы между консалтером и программистом нет, но есть некий дьявол в деталях. К "решению проблем" не относится.
B>>Хм. Попробую переформулировать. Консалтера обычно ищут с формулировкой "нам нужен такой-то результат, найди способ его получить и предоставь нам результат". Программиста обычно ищут с формулировкой "мы прекрасно знаем, что надо сделать и как это надо сделать, но сделать самим — не по чину, поэтому нужен Вася с лопатой, который будет получать указания и претворять их в жизнь".

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

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

D>И? А что предлагаешь-то? Взять общий знаменатель — пхп лом какой-нибудь, чтобы все заткнулись, и писать как завещал Макконнел — "не на языке, а с использованием языка"?

Нужно уметь решать задачи в рамках технологий которые используются в компании. Например в компании вся разработка ведется под Линуксом. А тут прийдет чувак и скажет что ему проще решить задачу в Вижуал Студии и потому давайте-ка будем использовать Майкрософтовские технологии. Это как пример. Куда такое годится? И так, представь, каждый!

Здравствуйте, Олег К., Вы писали:

ОК>Нужно уметь решать задачи в рамках технологий которые используются в компании. Например в компании вся разработка ведется под Линуксом. А тут прийдет чувак и скажет что ему проще решить задачу в Вижуал Студии и потому давайте-ка будем использовать Майкрософтовские технологии. Это как пример. Куда такое годится? И так, представь, каждый!

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

С другой стороны, тут же пишут, что инженеру-решателю задач, в отличие от быдлокопателя, даётся только постановка, а инструмент он вправе выбирать себе сам. Таким образом, если инструментарий зафиксирован работодателем, значит ему по определению нужен не инженер, а быдлокопатель.

Также, мне известно несколько случаев, когда с php переходили на java — хотя как по мне, хрен редьки не слаще, разве что в плане скорости в рантайме. Т.е. программисты ухитрялись убедить руководство, что инструмент говно и затраты на всё-переписывание окупятся. Хотя добитого до конца переноса кода не видел ни разу — на долгие годы растягивается эта затея, когда два проекта живут параллельно, пиная друг дружку по http.

Ну а лично я вообще про выбор с нуля инструментов для нового проекта говорю.

Здравствуйте, 0x7be, Вы писали:

[evil mode]
Попроси прислать сейвы от factorio
Если человек умеет решать задачи он любит их решать. Ибо нельзя уметь то, что не любишь. Так что он либо уже подсел на factorio либо подсядет когда ты ему ссылку дашь.
На фабрику нужно таки внимательно посмотреть, ибо, если человек любит решать задачи не значит, что он их решать умеет.
[/evil mode]

ЗЫ Уже соскочил или ещё плющит?

ОК>>Нужно уметь решать задачи в рамках технологий которые используются в компании. Например в компании вся разработка ведется под Линуксом. А тут прийдет чувак и скажет что ему проще решить задачу в Вижуал Студии и потому давайте-ка будем использовать Майкрософтовские технологии. Это как пример. Куда такое годится? И так, представь, каждый!

D>С одной стороны, ты сказал вроде как банальность, да и компании набирают людей на конкретную технологию.

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

D>С другой стороны, тут же пишут, что инженеру-решателю задач, в отличие от быдлокопателя, даётся только постановка, а инструмент он вправе выбирать себе сам. Таким образом, если инструментарий зафиксирован работодателем, значит ему по определению нужен не инженер, а быдлокопатель.

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

D>Ну а лично я вообще про выбор с нуля инструментов для нового проекта говорю.

Это пока есть возможность выбирать.

Здравствуйте, Олег К., Вы писали:

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

D>>С другой стороны, тут же пишут, что инженеру-решателю задач, в отличие от быдлокопателя, даётся только постановка, а инструмент он вправе выбирать себе сам. Таким образом, если инструментарий зафиксирован работодателем, значит ему по определению нужен не инженер, а быдлокопатель.

ОК>Неправильно. Нужен инженер который может решать любые задачи на любых технологиях. У тебя же понимание что инженер сам выбирет свою излюбленную технологию пусть даже она на все 200 процентов подходит для текущей задачи.

Ты хотел сказать "не подходит"? Утрируешь. И кроме того, я категорически не согласен с "на любых технологиях": технологии нынче зачастую гораздо сложнее подавляющего большинства прикладных задач, по крайней мере в вебе-энтерпрайзе, т.е. в формоклёпстве. И изучить новую технологию — скажем, для меня C# — это не просто язык, а ещё и библиотеки-фреймворки, коих сильно больше одного, и шишки набить — займёт не один год. А прикладные задачи — "левой пишешь — правой дрочишь" (c) пост в usenet про написание под копирку складских программ в до-1C-овскую эру.

D>>Ну а лично я вообще про выбор с нуля инструментов для нового проекта говорю.

ОК>Это пока есть возможность выбирать.

Кто бы спорил.

B>Не берусь говорить за всех, т.к. сам этот этап проскочил довольно быстро. Пусть форумные консалтеры меня поправят. А что касается "избавиться", я бы это назвал преимуществом. Если реальной работы нет, а постоянники есть, их обычно заваливают всякой ненужной фигней вперемешку с офисной политикой и часто бывает, что человек осознает года через три, во что вляпался, а навыки программирования он уже забыл и нормальную работу фиг теперь найдет. И менеджмент это прекрасно понимает и унижает подобных людей с утроенной силой. Видел много подобных примеров на одном из последних мест работы...

У меня у самого валяются визитки и с тем и с тем тайтлом и в Аутлуке в компаниях были написаны те тайтлы на тот момент. На счет "избввиться" — я тебе так и говорю, что для компании это преумущество, и это единственная разница между контракторами/консалтерами и постоянными работниками.

Здравствуйте, dimgel, Вы писали:

ОК>>Неправильно. Нужен инженер который может решать любые задачи на любых технологиях. У тебя же понимание что инженер сам выбирет свою излюбленную технологию пусть даже она на все 200 процентов подходит для текущей задачи.

D>Ты хотел сказать "не подходит"? Утрируешь.

А может и не хотел (т.к. в этом случае получается противоречие между двумя соседними предложениями "любые задачи на любых технологиях" vs "не подходит" ), тогда я не понял сказанного.

F> — Много бесед про предыдущие проекты и решенные проблемы соискателя, в разных плоскостях. Что и как было сделано, почему применялись такие-то инструменты итп.

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

Pzz>Ну в принципе, в жизни это сплошь и рядом случается, что проблема есть, а из доступных инструментов — только лом. При этом проблема должна быть репена уже вчера, но все предыдущие попытки ее решить с блеском провалились.

И такое тоже бывает.
Решается тем самым способом, которым решал проблему солдат из притчи про "Кашу из лома топора". Стороны, отмечу, расстанулся взаимно довольными друг другом.

D>И изучить новую технологию — скажем, для меня C# — это не просто язык, а ещё и библиотеки-фреймворки, коих сильно больше одного, и шишки набить — займёт не один год.

"Не уверен — не играй" (С) анекдот
Если не знаешь, как сделать ту или иную функциональность канонiчно на конкретном инструменте, не пыжься — спроси у тех, кто знает. Научись делегировать, в конце концов. Ведь цель — сделать чтоб работало, а не прокачать скиллы C# или очередного фреймворка.

Здравствуйте, SkyDance, Вы писали:

SD>Так ведь и это тоже бывает. Зная, что после твоего ухода систему будут поддерживать люди, которые кроме как на PHP, больше ни на чем не могут — пиши на PHP. В чем проблема-то?

Логично. Зная, что после твоего ухода плац будут подметать люди, ничего кроме лома не видевшие, — юзай лом. Решай задачу, ага. Не тратиться же руководству, в самом деле, на более дорогих, прости господи, "спецов", знающих жаву? (Тот факт, что такое руководство в итоге останется у полностью неработоспособного корыта и будет спамить по фрилансерским сайтам "доделать проект 90% готовности", мы скромно опустим.)

SD>Не осилишь освоить PHP, что ли?

Сказать по правде, нормально (а не вот так вот

Автор: dimgel
Дата: 25.04.14

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

Короче, не надо мне тут адвокатодьявольствовать про то, что нормальный спец сможет решить задачу на любой технологии. Чаще всего наоборот: и не сможет (спец. по графическим движкам enterprise-систему не напишет), и не захочет (деградировать). Поэтому, кстати, прозвучавшее тут где-то утверждение, что по баззвордам отбирают потому что по-другому не умеют — бред. Какой смысл искать C#-программиста в PHP-контору?

Здравствуйте, SkyDance, Вы писали:

SD>Научись делегировать, в конце концов. Ведь цель — сделать чтоб работало, а не прокачать скиллы C# или очередного фреймворка.

Ты как та сова в анекдоте с мышами. Делегировать — кому, простите? Мы про программистов-решателей проблем говорим, а не про менеджеров-делегировавщиков.

Здравствуйте, dimgel, Вы писали:

B>>Решатели проблем обычно в программистах не засиживаются и идут либо в менеджеры, либо открывают компании.

D>Это если они не пофигисты

Автор: denisko
Дата: 17.06.14

.

UPD: Кроме того, из моих наблюдений следует, что идущие в менеджеры и бизнесмены — как правило отвратительные инженеры (вернее даже не так: либо они были отвратительными инженерами, либо стали отвратительные менеджерами, но тут я буду говорить об отвратительных инженерах). Они решают проблемы, да, но в стиле "пока Петя писал правильный код, Вася наговнокодил и начал зарабатывать деньги... а потом набрал себе программистов, но было поздно: из-за огромного количества костылей начал рассыпаться и жрать огромное количество ресурсов и нервов на одно только его поддержание".

ОК>>>Неправильно. Нужен инженер который может решать любые задачи на любых технологиях. У тебя же понимание что инженер сам выбирет свою излюбленную технологию пусть даже она на все 200 процентов подходит для текущей задачи.

D>>Ты хотел сказать "не подходит"? Утрируешь.

D>А может и не хотел (т.к. в этом случае получается противоречие между двумя соседними предложениями "любые задачи на любых технологиях" vs "не подходит" ), тогда я не понял сказанного.

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

Здравствуйте, Олег К., Вы писали:

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

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

SD>>Не осилишь освоить PHP, что ли?

D>Сказать по правде, нормально (а не вот так вот

Автор: dimgel
Дата: 25.04.14

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

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

D>Короче, не надо мне тут адвокатодьявольствовать про то, что нормальный спец сможет решить задачу на любой технологии. Чаще всего наоборот: и не сможет (спец. по графическим движкам enterprise-систему не напишет), и не захочет (деградировать).

Всё сможет. Другое дело если человеку какая-то область может быть неинтересна, тогда это другое дело.

D>Поэтому, кстати, прозвучавшее тут где-то утверждение, что по баззвордам отбирают потому что по-другому не умеют — бред. Какой смысл искать C#-программиста в PHP-контору?

Опять-таки, у тебя разделение на шарпистов и пхп-шников. А на деле и тот и тот программист. Если шарпист не имеет ничего против PHP, то почему бы не нанять человека?

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

D>Согласен. Но и беда с полным отсутствием дизайна не менее распространена

Автор: dimgel
Дата: 25.04.14

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

Я оверэнжиниринга видел больше чем отсутствие дизайна.

D>Ну это всё так, разумеется. Собственно, ты даже не мнение высказываешь, а факт констатируешь. Поэтому как бы я не любил скалу и не плевался от PHP, захочется кушать — буду писать на чём предложат (из того что знаю), фигли. Вот только ORM свой допишу сначала (совмещать с работой не смог, приходится целиком голову загружать), по идее жировых запасов должно хватить.

Ну тогда о чем разговор?

Здравствуйте, Олег К., Вы писали:

ОК>Ты скажи, на PHP можно решать насущие задачи или нет? В своей нише. То что лично он тебе не нравится еще не значит что на нем нельзя решать задачи или писать нормальный код.

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

D>>Короче, не надо мне тут адвокатодьявольствовать про то, что нормальный спец сможет решить задачу на любой технологии. Чаще всего наоборот: и не сможет (спец. по графическим движкам enterprise-систему не напишет), и не захочет (деградировать).

ОК>Всё сможет. Другое дело если человеку какая-то область может быть неинтересна, тогда это другое дело.

Ну разумеется, и филолога в математика перековать тоже можно: каких-то пять лет ВУЗа — и вуаля.

ОК>Опять-таки, у тебя разделение на шарпистов и пхп-шников. А на деле и тот и тот программист. Если шарпист не имеет ничего против PHP, то почему бы не нанять человека?

И оплатить его переобучение? Зачем?

Блин, короче, надоело мне. Сколько уже этих срачей тут было, а всё одно и то же.

ОК>>Ты скажи, на PHP можно решать насущие задачи или нет? В своей нише. То что лично он тебе не нравится еще не значит что на нем нельзя решать задачи или писать нормальный код.

D>Решать задачи можно. Писать нормальный код — можно, но гораздо сложнее, чем на той же скале. А отладка, сопровождение и рефакторинг — вообще неизмеримо сложнее. А квалификация инженера, как за последние годы уже сто раз повторялось, заключается в том числе в умении выбрать подходящий инструмент. Кому и зачем может подойти PHP, также сотни раз повторялось.

ПХП прост и под него проще найти людей. Еще может существовать написанный код. С производительностью у него тоже неплохо. Чем тебе не аргументы?

D>>>Короче, не надо мне тут адвокатодьявольствовать про то, что нормальный спец сможет решить задачу на любой технологии. Чаще всего наоборот: и не сможет (спец. по графическим движкам enterprise-систему не напишет), и не захочет (деградировать).

ОК>>Всё сможет. Другое дело если человеку какая-то область может быть неинтересна, тогда это другое дело.

D>Ну разумеется, и филолога в математика перековать тоже можно: каких-то пять лет ВУЗа — и вуаля.

Не понял при чем тут это.

ОК>>Опять-таки, у тебя разделение на шарпистов и пхп-шников. А на деле и тот и тот программист. Если шарпист не имеет ничего против PHP, то почему бы не нанять человека?

D>И оплатить его переобучение? Зачем?

Какое переобучение? Любой толковый программист освоит ПХП в пять минут.

D>Блин, короче, надоело мне. Сколько уже этих срачей тут было, а всё одно и то же.

Здравствуйте, SkyDance, Вы писали:

SD>В этом и состоит умение решить задачу: изучить и применить инструмент ровно настолько, насколько это требуется. Причем изучить эффективно — с помощью тех, кто уже знаком с инструментом и знает, где разложены грабли. Это, конечно, не столь увлекательно, как пилить свои ORM'ы в собственном соку. Зато решается бизнес-проблема.

Я ждал этого ответа. И хочу напомнить тебе твоё же постом выше: "после твоего ухода систему будут поддерживать люди". Если такие "решальщики проблем" и решают чьи-то проблемы, то только свои собственные финансовые. Поддерживать и развивать PHP-код — самое поганое из известных мне занятий, а уж написанный такими вот спецами — и подавно.

Здравствуйте, Олег К., Вы писали:

ОК>Ну тогда о чем разговор?

О выявлении людей, умеющих решать проблемы. В условиях, когда заданы не только точки отправления и назначения, но и жёстко зафиксирован маршрут, и в зубы всучен конкретный автомобиль (причём в качестве примера с моей лёгкой руки фигурирует ржавый жопорожец, за который вы тут же встали горой, что характерно). На автомотовело недавно обсуждали, что за автоматизированными автомобилями будущее (аргументация лично меня вполне убедила), а в программировании водитель такой хреновины почему-то считается "инженером". Признавайся: ты ведь менеджер, и тебе пофиг, на чём кодеры пишут — не тебе ж руки марать и воевать с говнотехнологией вместо продуктивной работы?

Здравствуйте, Олег К., Вы писали:

ОК>Я оверэнжиниринга видел больше чем отсутствие дизайна.

А я предпочитаю свинину говядине, и что?

Здравствуйте, SkyDance, Вы писали:

SD>Применимость жавы в той области, где обычно используется PHP, мягко говоря, под вопросом. А уж цена поддержки решения на Java безо всяких вопросов выше.

Про цену поддержки, кстати, — бред сивой кобылы. Цена поддержки интерпретируемого языка со слабой динамической типизацией гораздо выше по сравнению со статикой (пусть даже сильно ограниченной из-за злоупотреблений всякими IoC и прочими AOP-фреймворками, ставшими в java-мире стандартом де факто). Просто уже потому, что лёгкость и надёжность проведения рефакторингов на PHP стремится к нулю. И тестов писать (и потом поддерживать) приходится в разы больше, чем на статике.

D>Я ждал этого ответа. И хочу напомнить тебе твоё же постом выше: "после твоего ухода систему будут поддерживать люди". Если такие "решальщики проблем" и решают чьи-то проблемы, то только свои собственные финансовые. Поддерживать и развивать PHP-код — самое поганое из известных мне занятий, а уж написанный такими вот спецами — и подавно.

Серьезно? Прошлый проект случился на PHP. Вообще никаких проблем с поддержкой (по крайней мере никто не тревожил, хотя видно, что какие-то изменения делаются).
Потому что сделано хорошо, по православному: с CI, unit & integration tests, все красиво лежит в git и автооткатывается при изменениях, ломающих тесты, с соответствующим стуком по инстанциям.

PHP тут только инструмент. На Java было бы сделано ровно так же.

Здравствуйте, Олег К., Вы писали:

B>>Не берусь говорить за всех, т.к. сам этот этап проскочил довольно быстро. Пусть форумные консалтеры меня поправят. А что касается "избавиться", я бы это назвал преимуществом. Если реальной работы нет, а постоянники есть, их обычно заваливают всякой ненужной фигней вперемешку с офисной политикой и часто бывает, что человек осознает года через три, во что вляпался, а навыки программирования он уже забыл и нормальную работу фиг теперь найдет. И менеджмент это прекрасно понимает и унижает подобных людей с утроенной силой. Видел много подобных примеров на одном из последних мест работы...

ОК>У меня у самого валяются визитки и с тем и с тем тайтлом и в Аутлуке в компаниях были написаны те тайтлы на тот момент. На счет "избввиться" — я тебе так и говорю, что для компании это преумущество, и это единственная разница между контракторами/консалтерами и постоянными работниками.
Не-не-не-не-не. Компании наверное а-ля Apple-Google-Microsoft? Дык там давно произошла девальвация тайтлов и в лучшем случае оный означает то, сколько лет человек провел в компании. Я встречал сениоров, работа которых состояла в исправлении падений билда после автоматического объединения веток. И principal-ов, которые забыли как код писать, но неизменно присутствовали на большей части митингов, пытаясь везде вклинить свои предложения (часто абсурдные). Давайте говорить за ехать, а не за шашечки, ок?

Здравствуйте, SkyDance, Вы писали:

SD>Серьезно? Прошлый проект случился на PHP. Вообще никаких проблем с поддержкой (по крайней мере никто не тревожил, хотя видно, что какие-то изменения делаются).
SD>Потому что сделано хорошо, по православному: с CI, unit & integration tests, все красиво лежит в git и автооткатывается при изменениях, ломающих тесты, с соответствующим стуком по инстанциям.

SD>PHP тут только инструмент. На Java было бы сделано ровно так же.

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

Вот что меня совершенно выбешивает в иных руководителях — это навязывание не только "что нужно", но и "как нужно". При этом я открыт для обсуждений конкретных архитектурных решений и меня вполне можно переубедить — аргументами, а не административным ресурсом, который задействуют обычно тогда, когда аргументов не остаётся. А потом мне же приходится убивать месяцы жизни, устраняя последствия решений этих идиотов. Если ты такой умный, то чего сам код не пишешь?

Автор: dimgel
Дата: 18.06.14

Здравствуйте, bazis1, Вы писали:

B>Чувак купит у нас VisualGDB и будет писать под Линукс в Вижуал Студии.

ААААА!!!! И ТУТ РЕКЛАМА!!!!

Здравствуйте, kaa.python, Вы писали:

KP>Ты принципиально не читаешь пост перед тем как отвечать? Я же сказал: полностью оплачиваемое. Вполне можно дать обособленную задачу из проекта, которая при успешном завершении приведет к полноценной работе. Если человек занят поиском не в "свободное от основной работы время", то потратить неделю, при условии что работодатель понравился, на мой взгляд вообще не проблема, не за даром же.

Ну, пожалуй, +1. Хотя и с оговорками (см. ниже).

KP>Вменяемые работодатели такая же редкость как и вменяемые кандидаты

ППКС. Только вот вменяемость работодателя остаётся неизвестной и в момент получения тестового задания, и в момент его сдачи. А недельные деньги — это не деньги, на такое можно согласиться только если больше вообще делать не чего (и не работаешь, и не в активном поиске — как я сейчас).

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

Здравствуйте, kaa.python, Вы писали:

А ты вообще читаешь то, что сам же пишешь?

KP> ... выделить тестовую задачу на неделю и дать ее, оплатив как полноценную работу, понравившемуся кандидату.

Да, полностью оплачиваемую, но — только понравившемуся. Одному из. Ну и обрати внимание на пост dimgel:

D> Только вот вменяемость работодателя остаётся неизвестной и в момент получения тестового задания, и в момент его сдачи.

Здравствуйте, Vlad_SP, Вы писали:

KP>> ... выделить тестовую задачу на неделю и дать ее, оплатив как полноценную работу, понравившемуся кандидату.
V_S>Да, полностью оплачиваемую, но — только понравившемуся. Одному из. Ну и обрати внимание на пост dimgel:

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

Здравствуйте, kaa.python, Вы писали:

KP>"выделить тестовую задачу на неделю и дать ее понравившемуся кандидату". Так лучше, а то реально неоднозначность вышла? Даем задание только тем, кто понравился. Всем кому дали – платим, никого за идиотов работающих за идею не держим.

А! Вот теперь — согласен. Да, это хороший способ найти "правильного" разработчика.

KP>Понравился – ему предложат тест. Не понравился, ему скажут "извините, но на данный момент нам нечего Вам предложить".

Выяснять "понравился ли" будем путём собеседования?

KP>Ты принципиально не читаешь пост перед тем как отвечать? Я же сказал: полностью оплачиваемое.

В каком конкретно объеме? Это же ультра-короткий контракт, на 1 неделю всего. Такие контракты, как правило, идут $1200+ в день. Надеюсь, ты понимаешь, почему?

Здравствуйте, SkyDance, Вы писали:

SD>Выяснять "понравился ли" будем путём собеседования?

Могу предложить гадание на шаре, если тебе такой вариант ближе

SD>В каком конкретно объеме? Это же ультра-короткий контракт, на 1 неделю всего. Такие контракты, как правило, идут $1200+ в день. Надеюсь, ты понимаешь, почему?

Надеюсь ты понимаешь что мы говорим про РФ и практика тут отличается от практики в АУ?

Здравствуйте, SkyDance, Вы писали:

KP>>Надеюсь ты понимаешь что мы говорим про РФ и практика тут отличается от практики в АУ?

SD>И какая в РФ практика коротких контрактов?

Ее по факту нет. Так что вполне можно предложить за неделю 1/4-1/3 от дальнейшей ЗП.

SD>Попробуй объяснить доступным языком, зачем сильному разработчику тратить неделю непонятно на что, да еще и без гарантии результата? Ему что, нечем больше заняться?

Объясняю. Если ты пришел в какую-то компанию на собеседование, пообщался. В итоге тебе понравились предлагаемые условия и потенциальные коллеги. После этого тебе предложили сделать оплачиваемое задание, с условием "понравится как сделали (и понравится сотрудничать с нами) – берем на постоянку". Таким образом, за эту неделю сильный разработчик ничего не теряет, т.к. он работает и при этом получает опыт работы с новой командой.

KP>Ее по факту нет. Так что вполне можно предложить за неделю 1/4-1/3 от дальнейшей ЗП.

Т.е. по сути стандартный рейт для permanent full time. Кроме как Петросянством это и не назвать.

KP>Объясняю. Если ты пришел в какую-то компанию на собеседование, пообщался. В итоге тебе понравились предлагаемые условия и потенциальные коллеги. После этого тебе предложили сделать оплачиваемое задание, с условием "понравится как сделали (и понравится сотрудничать с нами) – берем на постоянку".

1 день на тестовое задание — предел. Тогда и с оплатой всё просто (гифт-карты, ваучеры или что угодно подойдет, проще с точки зрения бухгалтерии).

KP>Таким образом, за эту неделю сильный разработчик ничего не теряет, т.к. он работает и при этом получает опыт работы с новой командой.

Погоди, так предполагается, что человек реально ходит все 7 дней на работу? Это ты придумал испытательный срок, что ли? Зачем?

Открою страшную тайну: большинство хороших кандидатов отнюдь не безработные, которым так и хочется где-нибудь просидеть неделю. Напротив, как правило, они работают. В другой компании. Фулл-тайм. Представь теперь его реакцию на предолжение взять и поработать 7 дней у вас. А что он нынешнему работодателю скажет?

Здравствуйте, SkyDance, Вы писали:

SD>И такое тоже бывает.
SD>Решается тем самым способом, которым решал проблему солдат из притчи про "Кашу из лома топора". Стороны, отмечу, расстанулся взаимно довольными друг другом.

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

Pzz>Бывает так, что у заказчика билдовая система, древняя, как г-но мамонта и сложная, как самолет. И все, кто в ней хоть что-то понимал, давно умерли или легли в психушку. Поэтому непредусмотренный в ней инструмент в нее ну никак не вписать, а руками они тоже не согласны.

В теории бывает, но на практике даже в самых древних системах есть рычажок типа "дёрнуть шелл-скрипт". Ну а дальше всё тривиально.

Здравствуйте, andyag, Вы писали:

A>На резюме смотреть бесполезно. Пригласите пообщаться, попросите рассказать про нетривиальные задачи, которые приходилось решать. Сделайте акцент на "откуда задачи взялись, можно ли было их не решать" — ИМХО, это направит разговор в правильную сторону.
Во! Первая методическая находка в этом топике, которую я знаю, как применить

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, 0x7be, Вы писали:

WH>[evil mode]
WH>Попроси прислать сейвы от factorio
WH>Если человек умеет решать задачи он любит их решать. Ибо нельзя уметь то, что не любишь. Так что он либо уже подсел на factorio либо подсядет когда ты ему ссылку дашь.
WH>На фабрику нужно таки внимательно посмотреть, ибо, если человек любит решать задачи не значит, что он их решать умеет.
WH>[/evil mode]
Шутки шутками, а я там успешно применил все свои методические наработки по части проектирования, рефакторинга и т.п.
я
WH>ЗЫ Уже соскочил или ещё плющит?
Плющит

Здравствуйте, bazis1, Вы писали:

B>Решатели проблем обычно в программистах не засиживаются и идут либо в менеджеры, либо открывают компании. Ищите партнеров и будет вам счастье. Сам всю программистскую жизнь имел обратную проблему: был "решателем проблем", но натыкался на одно из двух:
B>1. Компании нужны решатели проблем, но в компании нет денег. Т.е. как подработка живущему с родителями студенту сойдет, но не более. Выбить деньги, хотя бы на уровне среднего по рынку — уже огромное достижение.
По-моему опыту, решатели проблем всегда нужны в крупных компаниях. Просто зачастую "решатели проблем" вместо того, чтобы решать реальные проблемы пытаются решать проблемы никому кроме них самих не нужные. Иногда это напоминает девушку, которая старательно полирует тряпочкой фары у сломавшегося автомобился. Впрочем, ошибка в выборе проблемы зачастую вина не "решателя проблем", а его руководителя, который не смог донести реальную обстановку и проблематику. И так получается, что кроме решателей проблем, компании еще очень нужны хорошие "находители проблем".

B>2. У компании есть деньги, но тут нужны командные люди.
Ну это зависит от задач компании.

B>На практике это означает, что начальник любит руководить и ощущать себя мозгом команды/отдела, а остальных — инструментом в своих руках. Поэтому нужны люди, которые будут с неподдельным рвением дословно исполнять каждое мудрое указание, всем своим видом показывая, что без его лучезарного сиятельства сами бы до этого не додумались. Ну, пока начальник на них смотрит, разумеется. Если продемонстрировать способность решать проблемы, в вас увидят конкурента и начнут ставить палки в колеса.
Мне встречались разные руководители. Бывают и такие, как ты описал. С ними, конечно, "решателям проблем" будет тяжело — они заточены под другой тип задач/команд. Но на них свет клином не сошелся.

B>Поэтому, ИМХО, если человек имеет опыт и умеет решать проблемы, он не будет искать работу программиста...
Странный вывод.

Здравствуйте, Lazin, Вы писали:

L>А чего это вдруг soft skills и "техническая подготовка" противопоставляются друг другу? Мне кажется все немного наоборот, большинство технарей из тех, что мне доводилось встречать, с "провалом" в soft skills — были так себе специалистами. Стереотипный гениальный программист, не умеющий внятно выражать свои мысли и общаться с людьми, это миф.
Ты прав, эти вещи не надо противопоставлять.
Скорее надо противопоставлять интерес к средству и интерес к цели.

0>Скорее надо противопоставлять интерес к средству и интерес к цели.

На мой взгляд — тоже немного мимо. Интерес к цели или инструменту — вещь приходящая и уходящая. Ты здесь описываешь просто опытного инженера (это уже писали выше). В общем, я думаю, что следует искать не мифического "решателя проблем", а просто опытного чувака с десятком лет опыта (т.е. возраст лет эдак от 27-ми), который работал в коммерческих конторах а не сидел во всяких гос. НИИ кислых щей и тому подобных организациях, где важна не цель а процесс. Всякие опытные фрилансеры/удаленщики — тоже потенциальные кандидаты.

Здравствуйте, MaximVK, Вы писали:

MVK>Практически невозможно найти человека, который бы мог успешно решать все вышеперечисленные типы проблем.

Можно. Но, что характерно, с такими людьми необходимо делиться.

Здравствуйте, tttraveler, Вы писали:

T>Здравствуйте, 0x7be, Вы писали:

0>>Сейчас мне нужны именно "решатели проблем". Хотелось бы поинтересоваться у сообщества, какие маркеры в резюме и на собеседовании у вас есть для выявления таких кандидатов?

T>теперь вам нужно определиться с тем какие именно решатели проблем вам нужны и на какой срок
T>1. начинающие неопытные решатели проблем на постоянную ставку
T>2. решатели с опытом на постоянную ставку
T>3. решатели без опыта в качестве консультатов

здест опечатка в пункте 3
решатели с опытом разумеется имеются в виду

Здравствуйте, landerhigh, Вы писали:

L>Можно. Но, что характерно, с такими людьми необходимо делиться.

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

L>Можно. Но, что характерно, с такими людьми необходимо делиться.

В подавляющем большинстве случаев такие люди и не нужны. Швец, жнец, на дуде игрец — все это хорошо, но требуются, как правило, знания только в 1-2, реже 3 областях.

Здравствуйте, Олег К., Вы писали:

ОК>Я оверэнжиниринга видел больше чем отсутствие дизайна.

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



Фото не мое, но картина была аналогичной.

Здравствуйте, monax, Вы писали:

M>

M>
1. Дали задачу, ок.
   M>
2. А готовое решение есть?
   M>
3. Если есть, то насколько легко его можно применить?
   M>
4. Если легко применить мне, насколько лего его поддерживать другим людям?
   M>
5. А какое качество реализации у готового решения?
   M>
6. Время внедрения готового решения не будет ли больше, чем время разработки своего велосипеда?
   M>
7. А поддержка этого решения не сложнее ли поддержки самописного решения?
   M>
8. Если решения нет, то будем делать сами.
   M>
9. А какими инструментами пользоваться? Какой язык, фреймворк?
   M>
10. А если самый подходящий инструмент для разработки решения знаю только я? Может стоит взять менее подходящий инстумент, но которым владеет ещё кто-то в компании?
    M>

Так вродь разработчику наоборот выгодно, что он незаменимым станет, не?

Здравствуйте, antonio_banderas, Вы писали:

M>> А если самый подходящий инструмент для разработки решения знаю только я? Может стоит взять менее подходящий инстумент, но которым владеет ещё кто-то в компании?

_>Так вродь разработчику наоборот выгодно, что он незаменимым станет, не?

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