Здравствуйте, Кодт,

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

Бинго! В советское время такие таблички у проходных висели даже не годами, а наверное десятилетиями....

Здравствуйте, reversecode,

R>на собеседовании получаем тупой вопрос — что вы там делали в этом проекте ?
R>если собеседующий не в курсе существовании и функционале многих опенсорс проектов — то с вещами на выход — я считаю

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

V_S>Гмм. Ну, во-первых, собеседующий отнюдь не должен быть в курсе существования и функционала многих опенсорс проектов. А во-вторых, инжене(г)р должен уметь сжато, в двух-трех предложениях изложить самую суть дела. Если он этого не умеет — то no hire — я считаю

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

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


V_S>>Гмм. Ну, во-первых, собеседующий отнюдь не должен быть в курсе существования и функционала многих опенсорс проектов. А во-вторых, инжене(г)р должен уметь сжато, в двух-трех предложениях изложить самую суть дела. Если он этого не умеет — то no hire — я считаю

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

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

При нормальном полноценном Scrum'е всё немного меняется, но его реально мало где (нормального и полноценного).

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

A>Сеньёр и тимлид — это очень низкоуровневые позиции, они ни чем не рулят, их работой руководят.
A>Что и как творится за бортом, в частности текущего состояния жизненного цикла того или иного опен сорцного проекта, можно ли от туда что-то взять и насколько оно оправдано — это отсматривают продакт манагеры, системные аналитики и вице-презики по техн.направлениям.

Камрады, а можно я вмешаюсь?
У вас что, взаправду системные аналитики и вице-президенты решают какую либу заюзать мне-разработчику для, ну не знаю, для разбора json'а?
Если так, то это же компания-курорт! Можно годами нифига не делать — ждать утверждения "сверху" по каждому техническому вопросу.

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

Здравствуйте, Stanislav V. Zudin, Вы писали:

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

A>>Сеньёр и тимлид — это очень низкоуровневые позиции, они ни чем не рулят, их работой руководят.
A>>Что и как творится за бортом, в частности текущего состояния жизненного цикла того или иного опен сорцного проекта, можно ли от туда что-то взять и насколько оно оправдано — это отсматривают продакт манагеры, системные аналитики и вице-презики по техн.направлениям.

SVZ>Камрады, а можно я вмешаюсь?
SVZ>У вас что, взаправду системные аналитики и вице-президенты решают какую либу заюзать мне-разработчику для, ну не знаю, для разбора json'а?
SVZ>Если так, то это же компания-курорт! Можно годами нифига не делать — ждать утверждения "сверху" по каждому техническому вопросу.

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

А что за решение?
Если оно должно в продакшене у кастомера работать 24/7/365 годами и под хорошей нагрузкой, не мешая жить остальным на той же машине, то обычному сеньёру не дадут выбирать либы на собственное усмотрение и вкус фломастеров.

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

К>>Хуже. Модератор.
_>В данной теме ублюдок с латиноамериканским псевдонимом пытается вывести тему из русла, а ты ничего не предпринимаешь.

Вот и ответ, почему вас нигде не берут.
P.S. С ужасом перекрестился, представив такого кадра как вы у себя в команде

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

_>Чтобы уже помимо 4-5 часов на собеседование и дорогу тратить несколько дней на ТЗ, которое такие же HRюши будут предлагать просто так?

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

И самое главное — неадекватное ТЗ можно просто не делать, что сэкономит кучу времени.

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

->То, что ТЗ применяются неправильно, это не недостаток тестовых заданий как таковых.
Недостатки всё равно проявляются при нынешней положении дел, когда специалисты не нужны, а объявления висят.
Поэтому лучше уж напрасно потратить 4-5 часов, чем 2-3 дня.

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

RU>Мне кажется, надо ещё подходить по культуре. По взглядам на то, что есть правильно, а что нет.

Не нужно.

RU>Например, где-то надо, чтобы всё делалось быстро, а как не важно.

Это не культура. Это просто приоритеты, здесь и сейчас. Они легко меняются.

RU>Ещё бывают, например, люди, которые считают, что coding style соблюдать не надо.

А это банальный недостаток компетенции.

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

A>Команда проектная есть у менеджера — это пара тимлидов и несколько человек замыкающихся на них.

Два тимлида в одной команде это уже какая то шиза.

A>Т.е. проджект менеджера делегирует тимлиду следить за работой нескольких сотрудников, помогая им по мере надобности. И всё ничего больше, если тимлиду кто-то из людей не нравится, то оценивать как работает этот человека или перевести/уволить его тимлид не уполномочен.

Видишь ли какое дело, в разных компаниях разный подход. Если в твоей так, как ты описал — могу только посочувствовать. Работать в команде, разработкой в которой управляет РМ напрямую, ИМХО, ад. Это больше похоже на классический подход с линейной иерархией.

Здравствуйте, Ночной Смотрящий, Вы писали:
A>>Т.е. проджект менеджера делегирует тимлиду следить за работой нескольких сотрудников, помогая им по мере надобности.

До сих пор не понимаю, что в этом зазорного, спросить на работе у своего начальника что-то, что ты не понимаешь? Но видимо это считается верхом неприличия, задавать постоянно вопросы, даже в тех ситуациях, когда ты тупо уже не понимаешь и не справляешься. Отправляют в репозиторий, чтобы лазил там и искал ответы на свои вопросы. Сейчас конечно это не сложно лазить по большим репозиториям и то если есть хотя бы документация, какая-то архитиктура немного нарисована, но раньше!!
Вот хоть убейте, я этого не понимаю. И все хором молчат. У каждого свои задачи. Но ведь бывают такие что они захватывают всю систему сверху до низу и сквозь ядро. Какие менеджеры, какие тимлиды, помоги себе сам называется.

Я может быть конечно сейчас кого-то и задел, не хочу что б сильно пинали. Я просто не понимаю размеров действительно больших проектов и устроиства крупных IT компаний.
Три программиста на компанию из 60 человек.
10 программистов на 60 человек.
Два отдела в сумме 10 программистов на 300 человек.
А вот компания из 5000 человек и 1000 из которых программисты, это совсем другие проекты. Какие вопросы можно тут задавать, а какие нет? Лучше раз послушать и больше вообще вопросов не задавать.

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

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

Какая связь между предыдущим обсуждением и этим высказыванием?

E> Но видимо это считается верхом неприличия,

Кем считается? У меня мои подчиненные постоянно спрашивают, и незаметно чтобы кто то из них считал это зазорным. Я тебе больше скажу — я сам иногда у них спрашиваю или советуюсь.
Порвал шаблоны?

E> Отправляют в репозиторий, чтобы лазил там и искал ответы на свои вопросы.

Кто отправляет? Твой начальник?

E>Вот хоть убейте, я этого не понимаю. И все хором молчат. У каждого свои задачи.

Сочувствую тебе, дружище.

E>А вот компания из 5000 человек и 1000 из которых программисты, это совсем другие проекты.

Это разные проекты. Я вот в крупной компании сейчас работаю, но проекты сравнительно небольшие.

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

E>Здравствуйте, Ночной Смотрящий, Вы писали:
A>>>Т.е. проджект менеджера делегирует тимлиду следить за работой нескольких сотрудников, помогая им по мере надобности.

E>До сих пор не понимаю, что в этом зазорного, спросить на работе у своего начальника что-то, что ты не понимаешь? Но видимо это считается верхом неприличия, задавать постоянно вопросы, даже в тех ситуациях, когда ты тупо уже не понимаешь и не справляешься. Отправляют в репозиторий, чтобы лазил там и искал ответы на свои вопросы. Сейчас конечно это не сложно лазить по большим репозиториям и то если есть хотя бы документация, какая-то архитиктура немного нарисована, но раньше!!
E>Вот хоть убейте, я этого не понимаю. И все хором молчат. У каждого свои задачи. Но ведь бывают такие что они захватывают всю систему сверху до низу и сквозь ядро. Какие менеджеры, какие тимлиды, помоги себе сам называется.

E>Я может быть конечно сейчас кого-то и задел, не хочу что б сильно пинали. Я просто не понимаю размеров действительно больших проектов и устроиства крупных IT компаний.
E>Три программиста на компанию из 60 человек.
E>10 программистов на 60 человек.
E>Два отдела в сумме 10 программистов на 300 человек.
E>А вот компания из 5000 человек и 1000 из которых программисты, это совсем другие проекты. Какие вопросы можно тут задавать, а какие нет? Лучше раз послушать и больше вообще вопросов не задавать.
В моей компании несколько тысяч программистов. На проекте несколько сотен. В подпроекте — около 50 человек. Спрашивать можно все главное найти у кого Если непонятно у кого, можно у менеджера спросить контакты. Есть чатики для обсуждения. И естественно, что задачи затрагивающие несколько компонент просто не дают людям которые в них не разбираются. Самое неприятное — когда ответили, а ты так и не понял

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

L>Вы описали картинку которая существует в книжках по управлению проектами

Нет в современных книжках таких проектов. Современные книжки и современная практика все больше тяготеет к SCRUM, а там описанная роль тимлида нежизнеспособна. Там и РМ то никакого явно не выделено. Там есть stakeholders и они ниже PBI залазить не должны. Все что ниже PBI как раз епархия тимлида и его команды. Ну или devmanager, если термин тимлид не те ассоциации вызывает.
А вот ситуация когда "тимлид" это такой странный товарищ, который горшки за молодыми выносит, это не из книжек, а из попытки натянуть старую добрую иерархию на разработку. Когда есть РrojectМ, он же начальник отдела, он же зачастую ProductM и аналитик, и ниже него никаких руководителей нет.

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

R>- нафига я набиваю цв если потом звучат тупые вопросы — а расскажите что вы там делали в проектах

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

R>собеседующий не может понять в цв сложность проекта ?

А с чего ты взял что собеседующему важна именно сложность проекта?

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

А ты уверен, что твоя способность написать какой то код это единственное, что интересует тех, кто ищет работника?

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

A>А что за решение?
A>Если оно должно в продакшене у кастомера работать 24/7/365 годами и под хорошей нагрузкой, не мешая жить остальным на той же машине, то обычному сеньёру не дадут выбирать либы на собственное усмотрение и вкус фломастеров.
Если сеньор разработчик не может грамотно выбрать решение для "продакшене у кастомера работать 24/7/365 годами и под хорошей нагрузкой", то это не сеньор это просто начинающий разработчик.
Сеньор девелопер, работающий в конкретной проблемной области, сделает выбор на порядки лучше, чем любой VP of engineering. Именно поэтому лучшие из VP сами не принимают таких решений, потому как не могут обладать экспертными знаниями в каждой из областей, в которых ведется разработка в их компании. Они знают как делегировать такие вопросы на уровень сеньор разработчиков и как потом с юристами грамотно решить вопрос о возможности использования той или иной библиотеки в компании.
Если же мне как разработчику топ-менеджеры будут сверху в приказном порядке библиотеки указывать, потому что считают меня за безмозглого барана, не способного принимать решения в интересах проекта, то я останусь работать в компании, только если космическая зарплата будет перекрывать этот ужас. В этом случае, я постараюсь убедить себя что мне абсолютно все равно на результат моей работы.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Нет в современных книжках таких проектов. Современные книжки и современная практика все больше тяготеет к SCRUM, а там описанная роль тимлида нежизнеспособна.
Описанная в книжках SCRUM, в принципе, нежизнеспособна именно поэтому ее и нет в реальной разработке в нормальных компаниях. Я не могу себе представить серьезных разработчиков, которых скрам мастер каждое утро выстраивает в кружок, чтобы они отчитались о том, что делали вчера. При этом, согласно скрам, все должны сами себя убедить что это они не отчитываются перед другими, а просто общаются. Так же необходимо делать вид, что тебе действительно интересно каждое утро выслушивать что там вчера сделали другие 3-4 человека.
Больше всего скрам любят менеджеры всех уровней, не смотря на то, что их как бы в скрам процессе нет. Потому как если раньше перед ними отчитывались раз в неделю/месяц руководитель группы, то теперь каждый разработчик делает это каждое утро.
Самые эпические ежедневные митинги, которые я видел состояли из 15+ разработчиков в кругу. Да, все понимают, что это SCRUM BUT, но зато менеджерам, которых как бы нет, так удобнее.

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

_>И описанные 20 фирм — это только те фирмы, где я проходил собеседование, на самом же деле их больше.

_>P.S. добавил в заглавное сообщение.

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

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

RU>Мне кажется, надо ещё подходить по культуре. По взглядам на то, что есть правильно, а что нет.
RU>Например, где-то надо, чтобы всё делалось быстро, а как не важно.
RU>И человек, проработавший в подобной команде, может не вписаться туда, где хотят, чтобы у них код был приличный.
RU>Там, посмотрев на то, как он пишет код, решат, что ничего важного доверять ему не стоит. Будут давать какие-нибудь второстепенные модули, где можно смириться с тем, как оно сделано. Потом, мол, если потребуется что-то с ними делать, просто его говнокод перепишем. Человек оттуда потом сам уволится, т.к. ему не понравится, что ему ничего интересного не дают.

1. Очень многие люди переучиваются. Надо лабать код, они смогут. Надо сделать качественно, тоже сделают. А многие поработают где-то, потом их оттуда выгоняют, и они уже с опытом идут в другую фирму, и правильные базфорды они знают.

2. К вам HR часто забегал и спрашивал как вы пишете код? Зачем фантазировать. Почему процесс найма такой объяснить сложно, но это точно не потому, что кто-то разбирается в корпоративной культуре.