Добрый день

Интересует участвовал ли кто из присутствующих в больших опенсорсных проектах (Linux, открытые СУБД и пр.) насколько это было полезно, принесло ли какие-то дивиденды, в плане работы или непосредственно финансов? Уже не однократно встречал мнение, что те, кто котрибъютят в основную ветку linux ядра, PostgreSQL и пр, резко увеличивают свой вес как разработчика для работодателя.

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

JR>Добрый день

JR>Интересует участвовал ли кто из присутствующих в больших опенсорсных проектах (Linux, открытые СУБД и пр.) насколько это было полезно, принесло ли какие-то дивиденды, в плане работы или непосредственно финансов? Уже не однократно встречал мнение, что те, кто котрибъютят в основную ветку linux ядра, PostgreSQL и пр, резко увеличивают свой вес как разработчика для работодателя.

контрибутил — эффекта зеро. всем плевать. на собеседовании всегда одно и тоже — на кого вы до этого работали и можете ли вы ... за О(Н)

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

JR>Добрый день

JR>Интересует участвовал ли кто из присутствующих в больших опенсорсных проектах (Linux, открытые СУБД и пр.) насколько это было полезно, принесло ли какие-то дивиденды, в плане работы или непосредственно финансов? Уже не однократно встречал мнение, что те, кто котрибъютят в основную ветку linux ядра, PostgreSQL и пр, резко увеличивают свой вес как разработчика для работодателя.

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

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

JR>Добрый день

JR>Интересует участвовал ли кто из присутствующих в больших опенсорсных проектах (Linux, открытые СУБД и пр.) насколько это было полезно, принесло ли какие-то дивиденды, в плане работы или непосредственно финансов? Уже не однократно встречал мнение, что те, кто котрибъютят в основную ветку linux ядра, PostgreSQL и пр, резко увеличивают свой вес как разработчика для работодателя.

В плане финансов — заказчик заплатил за работу, попросив кое-что улучшить в опенсоурс продукте. В плане работы наверное можно преподнести как стремление улучшать вещи, которые тебе нравятся, но не до конца устраивают. Хотя не уверен, who would buy this.

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

JR>Интересует участвовал ли кто из присутствующих в больших опенсорсных проектах (Linux, открытые СУБД и пр.) насколько это было полезно, принесло ли какие-то дивиденды, в плане работы или непосредственно финансов? Уже не однократно встречал мнение, что те, кто котрибъютят в основную ветку linux ядра, PostgreSQL и пр, резко увеличивают свой вес как разработчика для работодателя.

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

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

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


M>Не уверен, что большинству работодателей это интересно. Но тут скорее для себя самого важно. Некий такой тест на профпригодность: если сможешь туда регулярно контрибутить, значит вероятно сможешь и работать.

M>Вообще, слышал и такой совет для "молодых". Что если хотите оценить свои возможности, зайдите на багтрекер какого-нибудь не самого маленького OpenSource проекта и попробуйте позакрывать баги в нем. Желательно регулярно и установив какие-то сроки. Это примерно то, чем будете заниматься за деньги...

я собеседовался в компанию которая высоко оценивала участие в опен OpenSource
но вовремя собеседования стало ясно, что они хотя человека который будет закрывать баги и допиливать функционал в OpenSource проектах которые им нужны
как я понял закрытие багов будет 90% времени и в месяц работа над 3-4 проектами

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

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

JR>Добрый день

JR>Интересует участвовал ли кто из присутствующих в больших опенсорсных проектах (Linux, открытые СУБД и пр.) насколько это было полезно, принесло ли какие-то дивиденды, в плане работы или непосредственно финансов? Уже не однократно встречал мнение, что те, кто котрибъютят в основную ветку linux ядра, PostgreSQL и пр, резко увеличивают свой вес как разработчика для работодателя.

Контрибьютил в Google Cloud Platform https://github.com/andrey-qlogic
Определенные положительные дивиденды приносло.

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

JR>Добрый день

Дратути

JR>насколько это было полезно, принесло ли какие-то дивиденды, в плане работы или непосредственно финансов?

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

В high-tech индустрии обычно высоко оценивают такой опыт. Особенно если он по тематике работы подходит. Твой открытый код — это часть твоей visibility в проф сообществе.

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

JR>Интересует участвовал ли кто из присутствующих в больших опенсорсных проектах (Linux, открытые СУБД и пр.) насколько это было полезно, принесло ли какие-то дивиденды, в плане работы или непосредственно финансов?

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

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

А им не все равно?

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

JR>Интересует участвовал ли кто из присутствующих в больших опенсорсных проектах (Linux, открытые СУБД и пр.) насколько это было полезно, принесло ли какие-то дивиденды, в плане работы или непосредственно финансов? Уже не однократно встречал мнение, что те, кто котрибъютят в основную ветку linux ядра, PostgreSQL и пр, резко увеличивают свой вес как разработчика для работодателя.
Я контрибьютил, но за последние 10 лет не собеседовался при приёме на работу.

Но я собеседовал, наверное, более 100 кандидатов уже. История положительных засылок патчей или крупные проекты на Github'е были однозначным и большим плюсом.

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

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

C>Я контрибьютил, но за последние 10 лет не собеседовался при приёме на работу.
C>Но я собеседовал, наверное, более 100 кандидатов уже. История положительных засылок патчей или крупные проекты на Github'е были однозначным и большим плюсом.

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

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

C>Но я собеседовал, наверное, более 100 кандидатов уже. История положительных засылок патчей или крупные проекты на Github'е были однозначным и большим плюсом.

слава богу я в клоунские компании на собеседования не хожу

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

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

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

Поправочка: многие в менеджменте верят, что наиболее эффективным для менеджмента является тот программист, который пашет на износ пока не выгорит.

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

DP>Зависит от того, куда идешь. В "традиционных" областях вряд ли на это обратят внимание — разве что вы не супер звезда и создатель или 2-ой контрибютор в известном проекте.

Остается открытым вопрос — за каким фигом ключевому разработчику известного проекта идти работать наемником.

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

DP>>Зависит от того, куда идешь. В "традиционных" областях вряд ли на это обратят внимание — разве что вы не супер звезда и создатель или 2-ой контрибютор в известном проекте.
C>Остается открытым вопрос — за каким фигом ключевому разработчику известного проекта идти работать наемником.

Вопрос для кэпа? Кто ещё то заплатит за работу над опенсорсов, если не корпорация?

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

aik>Вопрос для кэпа? Кто ещё то заплатит за работу над опенсорсов, если не корпорация?

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

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

C>Остается открытым вопрос — за каким фигом ключевому разработчику известного проекта идти работать наемником.
За деньгами же.

JR> Уже не однократно встречал мнение, что те, кто котрибъютят в основную ветку linux ядра, PostgreSQL и пр, резко увеличивают свой вес как разработчика для работодателя.

Мнение неверное.
Но.
1. Если это хороший и известный проект, то увеличивает количество приглашений на интервью (если это тебе нужно).
2. Набирается определенный вес и знакомства, и повышаются шансы, что очередной наниматель будет специфично за тобой охотиться (а значит, не потребуются дебильные собеседования из серии "напиши-ка мне алгоритм декодирования GIF").

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

JR>> Уже не однократно встречал мнение, что те, кто котрибъютят в основную ветку linux ядра, PostgreSQL и пр, резко увеличивают свой вес как разработчика для работодателя.

SD>Мнение неверное.
SD>Но.
SD>1. Если это хороший и известный проект, то увеличивает количество приглашений на интервью (если это тебе нужно).
SD>2. Набирается определенный вес и знакомства, и повышаются шансы, что очередной наниматель будет специфично за тобой охотиться (а значит, не потребуются дебильные собеседования из серии "напиши-ка мне алгоритм декодирования GIF").

Особенно если, как в примере выше, занимался поддержкой графических форматов в том же gimp

C>Поправочка: многие в менеджменте верят, что наиболее эффективным для менеджмента является тот программист, который пашет на износ пока не выгорит.
Ну для компании у которой проекты непродолжительные это действительно так, разве нет?

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

C>>Поправочка: многие в менеджменте верят, что наиболее эффективным для менеджмента является тот программист, который пашет на износ пока не выгорит.
_>Ну для компании у которой проекты непродолжительные это действительно так, разве нет?

А потом такие менеджерки удивляются «а чего хороших программистов днём с огнём не сыщешь»

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


JR>Интересует участвовал ли кто из присутствующих в больших опенсорсных проектах (Linux, открытые СУБД и пр.) насколько это было полезно, принесло ли какие-то дивиденды, в плане работы или непосредственно финансов? Уже не однократно встречал мнение, что те, кто котрибъютят в основную ветку linux ядра, PostgreSQL и пр, резко увеличивают свой вес как разработчика для работодателя.

Исправил пару мелких багов в V8, node.js, которые мешали мне в реальных проектах. Так что строчка об этом в конце резюме, в разделе "Прочее" есть. Но всем пофиг

Некоторые почему-то имеют какие-то иллюзии об этом, и потом сталкиваются с реальностью: https://twitter.com/mxcl/status/608682016205344768

Google: 90% of our engineers use the software you wrote (Homebrew), but you can’t invert a binary tree on a whiteboard so fuck off.

PM>Исправил пару мелких багов в V8, node.js, которые мешали мне в реальных проектах. Так что строчка об этом в конце резюме, в разделе "Прочее" есть. Но всем пофиг

Честно говоря, не совсем понимаю, а почему должно быть "не пофиг"? Чем исправление нескольких мелких багов в OpenSource лучше или круче исправления кучи багов всякого масштаба в каком-нибудь проприетарном продукте? Чем добавление небольшой фичи в OpenSource круче разработки сложного enterprise решения? Я понимаю, что для многих программистов участие в OpenSource — это что-то вроде как выбить своё имя на огромной скале. Приятно, конечно, но почему компании будут за это платить?

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

PM>Google: 90% of our engineers use the software you wrote (Homebrew), but you can’t invert a binary tree on a whiteboard so fuck off.
Хехе, смешная была teh drama.

То, что чувак кое как склепал что то работающее совсем не означает что он может качественно работать как Software Engineer.

Max Howell: I am often a dick, I am often difficult, I often don’t know computer science...

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

_>Ну для компании у которой проекты непродолжительные это действительно так, разве нет?

А такие бывают? Обычно успешные проекты не выбрасывают на помойку после пары месяцев.

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

CC>За деньгами же.

То есть какой-нибудь чувак садится и придумывает себе такой план действий на будущее:

1) написать опен сорц проект
2) сделать его успешным и известным
3) идти работать быдлокодером
4) PROFIT!!!

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

PM>>Исправил пару мелких багов в V8, node.js, которые мешали мне в реальных проектах. Так что строчка об этом в конце резюме, в разделе "Прочее" есть. Но всем пофиг

DB>Честно говоря, не совсем понимаю, а почему должно быть "не пофиг"? Чем исправление нескольких мелких багов в OpenSource лучше или круче исправления кучи багов всякого масштаба в каком-нибудь проприетарном продукте? Чем добавление небольшой фичи в OpenSource круче разработки сложного enterprise решения? Я понимаю, что для многих программистов участие в OpenSource — это что-то вроде как выбить своё имя на огромной скале. Приятно, конечно, но почему компании будут за это платить?

Так мне тоже пофиг Так как результат участия в open source околонулевой.

Упоминание в резюме — как просто еще одна из тем для разговора на собеседовании, в дополнение к стандартным вопросам про "most challenging task". Но обычно резюме дальше набора умений и последнего проекта никто не читает, потому что всем см. выше.

Отвечая на ваши вопросы — ни почему, ничем, ничем. Теоретически, компании может быть некий специфичный интересен опыт кандидата в той же области, что и его open source, но таких уникумов наверно специально ищут.

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

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

PM>>Google: 90% of our engineers use the software you wrote (Homebrew), but you can’t invert a binary tree on a whiteboard so fuck off.
CC>Хехе, смешная была teh drama.

Типичная ситуация — провал интервью перед доской, если кандидат не тренировался специально вращать деревья на ней.

CC>То, что чувак кое как склепал что то работающее совсем не означает что он может качественно работать как Software Engineer.
CC>

CC>Max Howell: I am often a dick, I am often difficult, I often don’t know computer science...

Но оно работает, у меня к homebrew претензий нет, в отличие от продуктов успешных гномосортировщиков и деревьевращателей. С Max Howell я не работал, так что про его качества и мотивы таких высказываний не берусь судить. Насколько я помню, тот его твит запустил волну metoo в стиле "я не помню порядок аргументов memcpy" (и я тоже)

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

PM>Типичная ситуация — провал интервью перед доской, если кандидат не тренировался специально вращать деревья на ней.
Особенно если он вообще ни в зуб ногой про деревья: "I want to defend Google, for one I wasn't even inverting a binary tree, I wasn’t very clear what a binary tree was." (C)
Ему ж задали простейшую задачку на отсев случайных в профессии людей, по сложности примерно как развернуть список или посчитать биты в байте.
Задачку, которая делается не приходя в сознание, если знаешь как устроено бинарное дерево.
На КЫВТе кстати уже пару раз гремели срачи по поводу таких элементарнейших задач и с такими же претензиями "йа звизда а вы меня о такой плебейщине спрашиваете!".

PM>Но оно работает, у меня к homebrew претензий нет
Ты не представляешь какой ужас на языке с памперсами можно в итоге заставить шевелиться.
Не, ты конечно можешь нанимать себе людей, которые ни в зуб ногой в том, что делают. Я же предпочту тех, кто понимает что происходит под капотом.
Он кстати тоже потиху дошёл до осознания: "Clearly I wrote something worthy of Google, right? Well, no I didn't. I wrote a simple package manager. Anyone could write one. And in fact mine is pretty bad. It doesn't do dependency management properly. It doesn’t handle edge case behavior well. It isn’t well tested. It’s shit frankly." (С)

PM> в отличие от продуктов успешных гномосортировщиков и деревьевращателей.
А как же "PM>Но оно работает"?
Т.е. тебе не нравится как работает тот же Google Cloud?

PM> С Max Howell я не работал, так что про его качества и мотивы таких высказываний не берусь судить.
Мотивы он прекрасно просуммировал и озвучил сам: "I am often a dick, I am often difficult, I often don’t know computer science" (С)
У чувака банальные проблемы с самомнением, которые мешают ему реально оценить свой уровень знаний.

PM> Насколько я помню, тот его твит запустил волну metoo в стиле "я не помню порядок аргументов memcpy" (и я тоже)
Да пофигу на твиттер в целом, там просто гнездо обиженных на что угодно.
Вот кстати что по этому поводу говорит автор: "I feel bad about my tweet, I don’t feel it was fair, and it fed the current era of outragism-driven-reading that is the modern Internet, and thus went viral, and for that I am truly sorry." (С)
Как раз этот его твит был очень большой ошибкой. Отмываться от репутации истерички-примадонны он будет ещё долго.

RW>Особенно если, как в примере выше, занимался поддержкой графических форматов в том же gimp

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

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

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

DB>Чем добавление небольшой фичи в OpenSource круче разработки сложного enterprise решения?

Много чем, если это сколь-нибудь крупный опен сорс. "Сложное энтерпрайз решение" — почти всегда "дом из г...а и палок", качество этого решения находится ниже плинтуса, и некому оценить ни уровень исполнения, ни затраты на поддержку, ни сложности с совместимостью. Это все почти не имеет значения для "сложного enterprise" (которое очень часто есть не что иное как "home brew reinvented bicycle").

Совсем другое — большой и стабильный open source проект, где твои патчи оценят сотни и тысячи людей с очень разным background, умениями, мозгами, понятиями, и образованием. Почти всегда это будет куда менее кустарный "hack left & right project". Зачастую еще и с документацией, почти всегда с тестовым покрытием, а также с обсуждениями между автором и теми, кто в теме.

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

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

SD>Мне тут некий аноним в личную почту пишет
Это известный идиот-кукушка. Шли его в игнор и даже не читай, и уж тем более не пости сюда его "творчество" (именно этого он и добивается)

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

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

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


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

IM>А им не все равно?

Даже если честно не трогать свой проект днем иточить опенсорс по ночам ты можешь не выспаться для основной работы и точить основной проект хуже.
А так ведь может и днем прийти важный/интересный багрепорт или pull request в опенсорс.

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


SD>в России и вовсе порой вред — сплошная зависть, и черные мысли, что работник будет в рабочее время это опен сорс пилить

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

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

JR>Добрый день

JR>Интересует участвовал ли кто из присутствующих в больших опенсорсных проектах (Linux, открытые СУБД и пр.) насколько это было полезно, принесло ли какие-то дивиденды, в плане работы или непосредственно финансов? Уже не однократно встречал мнение, что те, кто котрибъютят в основную ветку linux ядра, PostgreSQL и пр, резко увеличивают свой вес как разработчика для работодателя.

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

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

Вообще, спасибо за пост. Я вспомнил свою трудовую биографию. Вспомнил, что несколько небольших проектов-тулов 10-15 летней давности с моим участием сдали в опенсорс. Поискал. Меня не забыли и кое-где внесли в со-авторы. Даже в википедии упомянули разок как выяснилось Но самое интересное — всю старую историю похерили. Я вроде проекты помню, а моих патчей нет, код переписан. Я своего кода не узнаю, да и не помню его уже.

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

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

JR>Добрый день

JR>Интересует участвовал ли кто из присутствующих в больших опенсорсных проектах (Linux, открытые СУБД и пр.) насколько это было полезно, принесло ли какие-то дивиденды, в плане работы или непосредственно финансов? Уже не однократно встречал мнение, что те, кто котрибъютят в основную ветку linux ядра, PostgreSQL и пр, резко увеличивают свой вес как разработчика для работодателя.

Профит от того что разработчики что-то контрибютят в свои или опенсорсные проекты для меня лично есть. Заключается он в том что когда собеседуешь какого-нибудь кандидаты хочется понять две вещи: 1) как он вообще думает решая какую либо задачу (т.к. большинсво думать совсем не умеют и понять это помогает общение на этапе интервью) 2) какой код пишет кандидат (т.к. это основаня из его каждодневных задач и делать это он должен как минимум не хуже чем другие члены команды).

И вот по второму пункту возможны 2 варианта:

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

Лет 10 назад, а может больше, был такой случай который мне запомнился. Один из кандидатов (который кстати тусит здесь) прислал код своего per project-а. Сказать что от увиденого вытекли глаза это ничего не сказать. Прикинув что договорится его писать ближе к общепринятым code style стандартам вряд ли получится за разумное время (плюс возникли вопросы про разумности выбранного подхода для решения задачи) пришлось звонить и договариваться об отмене интервью. Профит: ни я ни кандидат своего времени не потеряли, а я через какое-то время нашел кандидата который писал код и думал практически так же как я.

И второй пример: нужно было как можно быстрее найти Rails разрабочика. Среди кандидатов попался один который работал над своим pet project и даже написал про него пару статей на хабре. Посмотрев его код и пообщавщись с ним стало понятно что его и нужно брать в первую очередь. Вроде как работает уже около 2-х лет на этом проекте.

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

Повлияло ли то что я контрибютил в ОС или свои per project на меня лично я сказать затрудняюсь (не особо часто это делаю да и не особо часто менял работу в последнее время), но на собеседовании точно были моменты когда я расказывал про свои проекты и показывал их.

P.S. А вообще контрибутинг в ОС проекты это занятие не для слабонервных. Я например с удивлением узнал что в .NET Core система его сборки полное дерьмо (хотя казалось бы всё должно быть наоборот), а в IntelliJ Idea можно встретить в репозитории обширные куски закоменченого кода и стремные методы на несколько экранов.

P.P.S. Есть еще как минимум один профит при работе над своими pet project-ами (возможно это и для работы над ОС проектами тоже справедливо). В силу разных обстоятельств их стараешся делать лучше чем рабочие проекты (учитываешь ошибки с какими столкнулся, выбирешь другие подходы для решения задачь более рациональные с твоей точки зрения, более разумно управляешь свои времением, лучше оцениваешь и прорабатываешь задачи и т.п.). Это всё не проходит даром и по факту с течением времени начинаешь лучше и эфективнее делать свою основную работу.

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

C>В силу разных обстоятельств их стараешся делать лучше чем рабочие проекты
Скорее просто времени на их вылизывание куда больше — сроков то нет и в спину никто не гонит.

C>Это всё не проходит даром и по факту с течением времени начинаешь лучше и эфективнее делать свою основную работу.
+1

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

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

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

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

PM>Типичная ситуация — провал интервью перед доской, если кандидат не тренировался специально вращать деревья на ней.

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

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

M>Ну сделать известный проект денежным это несколько другие таланты, чем его программировать. И примеров самоокупающихся проектов не так уж и много.

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

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

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

A>чтобы перевернуть — мне еще и подумать надо.
Вот серьёзно, сколько тебе надо подумать чтобы например вот такое вот дерево:

преобразовать вот в такое:


A> А получаю я, видимо, куда больше
Дюд, даже не пытайся пыжиться про деньги, будешь огорчён.

A> чем московские вращатели деревьев.
А Москва то тут каким боком?

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

S>Я правильно понимаю, что инвертирование бинарного дерева — это сделать его из возрастающего убывающим, т.е. поменять местами левую и правую часть во всех узлах?
Где то в обсуждеже того самого случая как раз было уточнено что да, его просили сделать mirror.

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

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

PM>>Типичная ситуация — провал интервью перед доской, если кандидат не тренировался специально вращать деревья на ней.

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

Да, задачка простая: https://leetcode.com/problems/invert-binary-tree/

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

PM>>>Типичная ситуация — провал интервью перед доской, если кандидат не тренировался специально вращать деревья на ней.

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

PM>Да, задачка простая: https://leetcode.com/problems/invert-binary-tree/

Да, дольше регистрироваться, чем решать.

Там соседняя задачка интереснее: https://leetcode.com/problems/implement-stack-using-queues/ — пытаюсь понять, что двигало интервьюерами при постановке подобного. Думал я не вижу каких-то остроумных решений, но нет — все тоже предлагают перебирать очередь при вставке или при извлечении значения.

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

PM>>Да, задачка простая: https://leetcode.com/problems/invert-binary-tree/

S>Да, дольше регистрироваться, чем решать.

S>Там соседняя задачка интереснее: https://leetcode.com/problems/implement-stack-using-queues/ — пытаюсь понять, что двигало интервьюерами при постановке подобного. Думал я не вижу каких-то остроумных решений, но нет — все тоже предлагают перебирать очередь при вставке или при извлечении значения.

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

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

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

Потому лично я спрашиваю token bucket. Почему-то его нет в обычных книгах по подготовке к интервью, хотя на практике встречается сплошь и рядом.

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

C>Потому лично я спрашиваю token bucket. Почему-то его нет в обычных книгах по подготовке к интервью, хотя на практике встречается сплошь и рядом.
Это, по-моему, чисто сетевая приблуда. А бинарное дерево даже мне пару раз приходилось реализовывать на тёплой ламповой сишечке, так что выглядит более универсально.

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

M>Даже если честно не трогать свой проект днем иточить опенсорс по ночам ты можешь не выспаться для основной работы и точить основной проект хуже.

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

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

CC>Ему ж задали простейшую задачку на отсев случайных в профессии людей, по сложности примерно как развернуть список или посчитать биты в байте.

Нет. Это в принципе задача на отсев в большинстве контор.

CC>Задачку, которая делается не приходя в сознание, если знаешь как устроено бинарное дерево.

Задачку сделают, вопрос в оптимальности и безошибочности сразу. Да-да, все же пишут сразу безошибочный код на доске. Зачем только ATDD и TDD, системы контроля версий и прочая ересь? Можно сразу код хреначить в прод.


CC>На КЫВТе кстати уже пару раз гремели срачи по поводу таких элементарнейших задач и с такими же претензиями "йа звизда а вы меня о такой плебейщине спрашиваете!".

Да можно сразу валить на школьной программе по информатике.

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

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

CC>>Задачку, которая делается не приходя в сознание, если знаешь как устроено бинарное дерево.
C>Справедливости ради, бинарные деревья руками пишутся редко и можно просто даже забыть терминологию.
О чём ты? Какую ещё там терминологию можно забыть?

C> Потому лично я спрашиваю token bucket. Почему-то его нет в обычных книгах по подготовке к интервью, хотя на практике встречается сплошь и рядом.
Да не то чтобы, этож довольно специфичный по области применения алгоритм.

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

CC>>Ему ж задали простейшую задачку на отсев случайных в профессии людей, по сложности примерно как развернуть список или посчитать биты в байте.
IT>Нет. Это в принципе задача на отсев в большинстве контор.
Чот не пойму с чем ты споришь?

CC>>Задачку, которая делается не приходя в сознание, если знаешь как устроено бинарное дерево.
IT>Задачку сделают, вопрос в оптимальности и безошибочности сразу.
Неверно.

IT> Да-да, все же пишут сразу безошибочный код на доске.
А никто и не ожидает.

CC>>На КЫВТе кстати уже пару раз гремели срачи по поводу таких элементарнейших задач и с такими же претензиями "йа звизда а вы меня о такой плебейщине спрашиваете!".
IT>Да можно сразу валить на школьной программе по информатике.
"Какую то попаболь я в тебе ощущаю, юный падаван" (С)
С чего бы?

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

IT>Это как раз задача на отсев конторы, в которой люди не могут подойти к найму с инженерной точки зрения
Расскажи нам, а как надо "с инженерной точки зрения"?

IT> а тупо копируют чужие практики, как обезьянки.
Если просто содрать чужую задачу не понимая для чего она и на что смотреть — да.
Но почему ты решил что в гугле именно такой случай?

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

PM>Бесполезно искать в таких задачах смысл. Реализовать стек на основе очереди, очередь на основе стека, перевернуть строку, обойти дерево по уровням, и т.д., и т.п. Все их прекрасно знают. Кто хочет пройти интервью, заучивает решения. Кто не готовится, тот повышает шанс провалить ответ у доски.

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

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

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

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

C>Потому лично я спрашиваю token bucket. Почему-то его нет в обычных книгах по подготовке к интервью, хотя на практике встречается сплошь и рядом.

Первый раз увидел

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

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

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

R>а где бы посмотреть на то что вы изобрели ?
Внутри Mac, iPhone, iPad, Watch, AppleTV

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

Основная проблема, что народ копирует собеседования гугла без малейшего понимания что и зачем. Человек может быть богом отладки, но при этом совершенно хреново писать код с ноля. Вообще никак. Другой может хорошо проектировать, но фигово отлаживать сложные случаи. Третьего берут вообще на определенный круг несложных задач.
А встречаются особо одаренные, которые всех будут собеседовать "как в гугле", давая задачи "на развитое инженерное мышление", а не изучая то, что человек знает в рамках требуемых для позиции навыков. Отсюда и получаются собеседования про гномиков.
И самое главное. Даже тут уже писали что к собеседованиям надо готовиться и на такие задачи натаскиваются. Т.е. народ ни до, ни после собеседования ничего подобного не делает. Тогда что этим проверяют? Усидчивость?
Вроде уже писали что гуглу просто надо как-то фильтровать входящий поток, а потом "там научат". Может для крупной компании это выход. Хотя чем тогда заняты менеджеры конкретных проектов хз, но пусть. А для некрупных контор такой подход вообще тупость, на мой взгляд.

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

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

A>Врядли есть много людей кто реально не может придумать как это сделать.
Достаточно много.

A>А вот написать на "белой доске" я бы уже наверно не написал. По крайней мере без какого-нибудь ассиста и гугла я мало какие функции помню точно.
Там не надо ничего кроме операторов самого языка.

A> Ну или что-то маломальски сложное уже точно бы не написал без ошибок.
Интересуют только ошибки в логике алгоритма, остальные пофигу.

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

A>А встречаются особо одаренные, которые всех будут собеседовать "как в гугле"
Ничего что речь тут про сам гугл?

A>А про зп я упомянул в контексте что человек, не умеющий решить дебильную задачу у доски,- левый в профессии.
Хехе, дебильную, ага. Задача то элементарная, букварь Computer Science.

A> Может и левый, но огорчены скорее всего будут как раз многие работающие онсайт в америке.
Ты мне хочешь рассказать за Америку?

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

CC>>>Задачку, которая делается не приходя в сознание, если знаешь как устроено бинарное дерево.
C>>Справедливости ради, бинарные деревья руками пишутся редко и можно просто даже забыть терминологию.
CC>О чём ты? Какую ещё там терминологию можно забыть?
"Инвертирование дерева".

C>> Потому лично я спрашиваю token bucket. Почему-то его нет в обычных книгах по подготовке к интервью, хотя на практике встречается сплошь и рядом.
CC>Да не то чтобы, этож довольно специфичный по области применения алгоритм.
Ну так я собеседую на позиции по инфраструктуре и сетевым сервисам. В этих областях мне лично приходилось token bucket писать примерно так раз 5.

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

CC>>О чём ты? Какую ещё там терминологию можно забыть?
C>"Инвертирование дерева".
Тоже мне беда. Если не понятно что именно требуется то всегда можно задать уточняющие вопросы. И минусом это не будет.

CC>>Да не то чтобы, этож довольно специфичный по области применения алгоритм.
C>Ну так я собеседую на позиции по инфраструктуре и сетевым сервисам. В этих областях мне лично приходилось token bucket писать примерно так раз 5.
О чём и написано: "этож довольно специфичный по области применения алгоритм"
Кандидатам на такие позиции всё таки следует быть в курсе его существования, но generic кандидаты сам алгоритм по названию могут и не знать.
Тогда как бинарное дерево это таки азбука Computer Science и не знать про них будет как минимум весьма странно.

ECR>Это, по-моему, чисто сетевая приблуда.

Да такой же вопрос из серии "я как-то пару раз писал". Столь же бессмысленный, сколь и беспощаный. А то ведь, чего б не спросить CoDel, да так, чтоб не говорить, что оно такое, и википедии не давать.

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

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

SD>Уж тысячу раз говорил, и столько же писал, что сам формат такого собеседования неверен. Просить кандидата что-то писать, в конторе, где уже написаны миллионы строк кода, — способ получить очередного велосипедостроителя.

Дада, самый правильный путь — копипастить со StackOverflow и тянуть 100500 зависимостей через зависимости для элементарных вещей.
Так и получается "двести метров жаваскрипта тянут текста триста байт" и хохмы про то, как удаление из паблик репы "проекта" по паддингу строки ломает через зависимости здоровенный кусок веба. Потому что там как раз "прочитали" вместо того чтоб написать.

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

Дублирование кода это проблема менеджмента а не девелопмента.
А полноценный девелопер должен таки понимать как работает под капотом то, что он использует. Иначе это маппет-кодер а не девелопер.

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

ECR>>Это, по-моему, чисто сетевая приблуда.
SD>Да такой же вопрос из серии "я как-то пару раз писал". Столь же бессмысленный, сколь и беспощаный. А то ведь, чего б не спросить CoDel, да так, чтоб не говорить, что оно такое, и википедии не давать.
Ну вообще-то, вводная даётся так: "Есть сервис, который может выдержать только 1 запрос в минуту от пользователя. Написать функцию, allowAccess, берущую на вход userId и возвращающую true/false".

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

CC>Дада, самый правильный путь — копипастить со StackOverflow и тянуть 100500 зависимостей через зависимости для элементарных вещей.
CC>Так и получается "двести метров жаваскрипта тянут текста триста байт" и хохмы про то, как удаление из паблик репы "проекта" по паддингу строки ломает через зависимости здоровенный кусок веба. Потому что там как раз "прочитали" вместо того чтоб написать.

Не соглашусь. Простая ситуация — мне в проекте понадобился кольцевой буффер. Я, само собой, могу его сам написать — но цель-то у меня не написать класс кольцевого буффера, а использовать его в программе. И в этом плане у многих систем управления зависимости есть огромная дыра: они позволяют подключить огромную библиотеку к проекту, но не позволяют загрузить один алгоритм. И получается, что ты либо копипастишь, либо подключаешь some.name.space.CircularBuffer.dll на несколько килобайт (и таких библиотек в проекте может быть несколько десятков), либо подключаешь super.mega.library.dll на 20 мегабайт, 99% которой тебе не нужны. Все способы отстойные, включая написание класса самому.

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

CC>Дублирование кода это проблема менеджмента а не девелопмента.
CC>А полноценный девелопер должен таки понимать как работает под капотом то, что он использует. Иначе это маппет-кодер а не девелопер.

Помнить != переписывать снова и снова ради переписывания.

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

SD>>Да такой же вопрос из серии "я как-то пару раз писал". Столь же бессмысленный, сколь и беспощаный. А то ведь, чего б не спросить CoDel, да так, чтоб не говорить, что оно такое, и википедии не давать.
C>Ну вообще-то, вводная даётся так: "Есть сервис, который может выдержать только 1 запрос в минуту от пользователя. Написать функцию, allowAccess, берущую на вход userId и возвращающую true/false".
В такой формулировке как-то слишком просто получается.

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

PM>>Бесполезно искать в таких задачах смысл. Реализовать стек на основе очереди, очередь на основе стека, перевернуть строку, обойти дерево по уровням, и т.д., и т.п. Все их прекрасно знают. Кто хочет пройти интервью, заучивает решения. Кто не готовится, тот повышает шанс провалить ответ у доски.

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

В случае этой задачи у меня инжинерное мышление начинает буксовать на "можно ли это сделать эффективниее?" и "нафиг нужен настолько неэффективный алгоритм с такими ограничениями?".

SD>>Просить кандидата что-то писать, в конторе, где уже написаны миллионы строк кода, — способ получить очередного велосипедостроителя.
CC>Дада, самый правильный путь — копипастить со StackOverflow и тянуть 100500 зависимостей через зависимости для элементарных вещей.

Учу читать. Дорого.

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

Вот именно. Ровно это и происходит, когда нанимаемые работники не могут прочитать то, что уже написано до них. И начинают "писать". Разумеется, с помощью всех этих stackoverflow и github, потому что, внезапно, в реальной работе им требуются не сферические алгоритмы в вакууме собеседования, а некоторая кривая "бизнес-логика".

CC>А полноценный девелопер должен таки понимать как работает под капотом то, что он использует. Иначе это маппет-кодер а не девелопер.

Так нанимают-то именно маппет-кодеров, которые выучили книжки или зазубрили литкоды. На собеседовании спрашивают не "разберись, как вот это работает", а "напиши мне ХУZ".

CC>Дублирование кода это проблема менеджмента а не девелопмента.

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

C>Ну вообще-то, вводная даётся так: "Есть сервис, который может выдержать только 1 запрос в минуту от пользователя. Написать функцию, allowAccess, берущую на вход userId и возвращающую true/false".

В такой формулировке это "таймер на 1 минуту". А что такое token bucket, я хоть и помню название, но мне потребуется 5-10 минут погуглить, и еще минут 30-40 подумать, и затем некоторое еще время найти все реально нужные сценарии использования такой функциональности. Плюс, может потребоваться какое-то время по-grep-ать по кодовой базе, чтобы найти 5-6 существующих реализаций. Ибо реальность такова, что писать очередной велосипед не надо, все велосипеды уже написаны. Надо найти нужный, и правильно его использовать.
Иначе будет уже 6-7 разных реализаций, и, разумеется, каждая будет плохо протестирована (если вообще), и уж тем более не будет реального анализа производительности, ужора памяти или каких еще ресурсов. Потому что это ж сложно. Это ж учиться надо, это ж надо понимать, что делаешь. Зачем, если вон, на собеседовании, накалякал какую-то дурь, которую интервьюер считает правильной, и все?

Вот за такие собеседования и хочется взять скотч, и интервьюерам что-то заклеить. Шибко далеки они от народа и нужд компании.

S> И в этом плане у многих систем управления зависимости есть огромная дыра: они позволяют подключить огромную библиотеку к проекту, но не позволяют загрузить один алгоритм. И получается, что ты либо копипастишь, либо подключаешь some.name.space.CircularBuffer.dll на несколько килобайт

Напомню, что я писал о серверной инфраструктуре большой конторы. Там в 99.999% случаев все эти "огромные библиотеки" уже подключены ко всем подряд проектам. И да, десять строчек программы создают, вау, гигабайтный исполнимый файл! Не шутка, а реальность этого мира в больших конторах. Монолитная "либа", общая для всей компании. Неэффективно? Да всем плевать, если это какой-то там сервис на десятке машин.

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

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

SD>Учу читать. Дорого.
Ты мысли свои выражать сначала научись, учитель.

SD>Вот именно. Ровно это и происходит, когда нанимаемые работники не могут прочитать то, что уже написано до них.
Это всего лишь один случай из множества, и как правило обусловленный тем, что документация отсутствует и заменена передаваемым из уст в уста lore.

SD>Так нанимают-то именно маппет-кодеров, которые выучили книжки или зазубрили литкоды.
Маппетов нанимают не так как тут обсуждается.

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

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

SD> И девелоперу приходится либо становиться продажником (объяснять тому самому менеджементу, что, как и почему оно все еще работает), либо уходить.
Это работа его менеджера.

CC>Ты мысли свои выражать сначала научись, учитель.

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

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

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

CC>Маппетов нанимают не так как тут обсуждается.

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

CC>Это работа его менеджера.

Это работа технического специалиста. Менеджер — это тот, кто дебажит людей, а не тот, кто занимается зависимостями между классами или библиотеками.

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

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

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

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

Я правильно понимаю что ты сейчас про мордокнигу? Про их идиотские принципы найма много кто матерится, и причины несколько более глубинные чем эти задачки — там не нанимают "в команду", там нанимают "в компанию" а потом начинается чесание в репе куда ж этого нанятого приткнуть. Оттого найм и заточен на generic mappets.

CC>Такими задачками никто не проверяет бинарно: ответил/не ответил, задачка всего лишь повод начать обсуждение и смотреть как кандидат мыслит.

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

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

Ты не поверишь (С) на собеседование уходит целый день, иногда два.

CC>Я правильно понимаю что ты сейчас про мордокнигу? Про их идиотские принципы найма много кто матерится, и причины несколько более глубинные чем эти задачки — там не нанимают "в команду", там нанимают "в компанию" а потом начинается чесание в репе куда ж этого нанятого приткнуть. Оттого найм и заточен на generic mappets.

Я сейчас про гугл и микрософт. Там эти самые литкоды в полный рост. И за ними многие другие повторяют. Хотя, конечно, есть и островки разума. Как-то с дропбоксом общался, понравилось.

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

SD>Опять ты штампами говоришь.
Я сам по таким принципам собеседую. И не только я.

SD> Такими задачами и их вариациями проверяется только натасканность кандидата на эти самые задачи.
Нет. Мне не интересно разжёвывать всё ещё раз, поищи старую тему по форуму.

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

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

C>>Ну вообще-то, вводная даётся так: "Есть сервис, который может выдержать только 1 запрос в минуту от пользователя. Написать функцию, allowAccess, берущую на вход userId и возвращающую true/false".
S>В такой формулировке как-то слишком просто получается.
Просто?

Ну и на то и собеседование, чтобы потом обсуждать детали, а потом заниматься усложнизмом.

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

C>>Ну вообще-то, вводная даётся так: "Есть сервис, который может выдержать только 1 запрос в минуту от пользователя. Написать функцию, allowAccess, берущую на вход userId и возвращающую true/false".
SD>В такой формулировке это "таймер на 1 минуту".
Ну так там дальше усложнения идут — не 1 запрос, а N запросов. Некоторые кандидаты ещё делают вместо TB связный список timestamp'ов. Там ещё дальше можно обсуждать много интересного — типа стратегий кластеризации.

SD>А что такое token bucket, я хоть и помню название, но мне потребуется 5-10 минут погуглить, и еще минут 30-40 подумать, и затем некоторое еще время найти все реально нужные сценарии использования такой функциональности. Плюс, может потребоваться какое-то время по-grep-ать по кодовой базе, чтобы найти 5-6 существующих реализаций. Ибо реальность такова, что писать очередной велосипед не надо, все велосипеды уже написаны. Надо найти нужный, и правильно его использовать.
Ну так там весь алгоритм — это два if'а. Если делать из него библиотеку — получится сложнее.

SD>Вот за такие собеседования и хочется взять скотч, и интервьюерам что-то заклеить. Шибко далеки они от народа и нужд компании.
Как я уже сказал, разные вариации TB мне пришлось писать раз 5. Т.е. задача чисто практическая.

C>Ну так там дальше усложнения идут — не 1 запрос, а N запросов. Некоторые кандидаты ещё делают вместо TB связный список timestamp'ов.

Еще и timer wheel навелосипедить? Спрашивается, зачем? Ответ я вижу только один — ты это когда-то делал и разбирался. Теперь ищещь кандидатов "такой как я". Поэтому я и говорю, что такие собеседования набирают не тех, кто может разобраться, а тех, кто "уже писал вот это".

C> Там ещё дальше можно обсуждать много интересного — типа стратегий кластеризации.

Так если цель — "обсуждать много интересного", зачем издеваться заданиями "напиши мне не скажу что, и не пользуйся интернетом, но вот мой извращенный разум задачу искорежил вот так". Речь, напоминаю, идет о наборе серьезных инженеров — а-ля L5+/65, а не кодеров (у которых сабжа нет по определению). Не нужно к ним подходит с "напиши мне разворот строки", чтобы потом дополнять задачу условиями типа "а теперь сделай, чтобы оно пело ча-ча-ча и троекратно салютовало".
Такие интервью можно и нужно вести сверху вниз. Сначала обсудить реальный сервис, ожидания и гарантии его работы, и потом уже, разумеется, предоставляя интернет и прочее, дать возможность кандидату найти подходящие решения.

C>Как я уже сказал, разные вариации TB мне пришлось писать раз 5. Т.е. задача чисто практическая.

Ну как я и ожидал. "Мне было нужно, значит, всем нужно".

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

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

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

Точно, это черезчур сложная для 90% синьеров задача, зачем если ещё на вопросе о разнице между array и linked list засыпется. Зато с опытом педаления кода на крупные конторы.

$>Точно, это черезчур сложная для 90% синьеров задача, зачем если ещё на вопросе о разнице между array и linked list засыпется. Зато с опытом педаления кода на крупные конторы.

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

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

SD>Но именно в крупной конторе даже самому завалящему девелоперу достается знание процесса разработки и operations.
В крупной конторе пытаются компенсировать разбавление уровня разработчиков процессом разработки. Но продукт не остается прежним- см. пример скайп.

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

DB>Честно говоря, не совсем понимаю, а почему должно быть "не пофиг"?

Могу сказать. В требовании к вакансии есть пункт "Знание библиотеки ХХХ." Ты приходишь на собеседование, на вопрос "Знаешь ли ты ХХХ" отвечаешь — да, даже контрибьютил туда. И всё, тебе ставят плюс, скипают вопросы по этому ХХХ и идут дальше. Так у меня было с OpenCV, хотя мои правки исключительно мелкофиксы и их мало.

Ну и вспоминается история про открытый драйвер для Радеонов в Линуксе. Один польский студент туда контрибьютил, а когда закончил универ, то АМД его взяла к себе на работу разрабатывать AMDGPU.

$>В крупной конторе пытаются компенсировать разбавление уровня разработчиков процессом разработки. Но продукт не остается прежним- см. пример скайп.

Ха, как раз Скайп-то и остался прежним. И потому не выдержал конкуренции.

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

SD>Ха, как раз Скайп-то и остался прежним.
Шта? В каком месте он остался прежним? Его в МС разделали как бог черепаху!

SD> И потому не выдержал конкуренции.
Его люто сговняли отчего он сдох.
А не трогали бы кривыми ручонками — жил да жил бы ещё.

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

JR>Добрый день

JR>Интересует участвовал ли кто из присутствующих в больших опенсорсных проектах (Linux, открытые СУБД и пр.) насколько это было полезно, принесло ли какие-то дивиденды, в плане работы или непосредственно финансов? Уже не однократно встречал мнение, что те, кто котрибъютят в основную ветку linux ядра, PostgreSQL и пр, резко увеличивают свой вес как разработчика для работодателя.

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

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

C>>>Ну вообще-то, вводная даётся так: "Есть сервис, который может выдержать только 1 запрос в минуту от пользователя. Написать функцию, allowAccess, берущую на вход userId и возвращающую true/false".
S>>В такой формулировке как-то слишком просто получается.
C>Просто?

Поправьте меня, но полное решение будет порядка 10 строк. А вот если бы формулировка требовала не более n пакетов в минуту, код потребовался бы совсем другой.