Здравствуйте, Codealot, Вы писали:
S>>b) будет вслух рассуждать при их решении?
C>Справедливости ради, хватает компаний, в которых чесать языком — не только необходимый, но и основной скилл, начиная с уровня сеньора и выше.
Я про другое. На собеседованиях просят порассуждать в слух типа для того, чтобы посмотреть, как человек думает, и ждут чего-то вроде "Так, значит нам нужно получить вот это... Можно попробовать вот так... А нет, здесь не получится потому-то и потому-то. Значит нужно получить вот это с учетом вот этого. Раз это не сработало, то можно попробовать вот так..." и т.д., и т.п. Даже если не затрагивать вопрос о том, насколько такие "рассуждения вслух" соотносятся с реальным процессом размышления. Просто можно представить себе что будет творится на рабочих местах, если программисты будут "думать вслух" в прямом смысле слова: один такой "здесь почему-то потребление CPU упирается в потолок, хотя быть такого не должно, значит ща запустим профайлер, посмотрим... Ага, вот здесь мы жрем слишком много, но почему?..." А за соседним столом другой: "этот запрос приходит на тред веб-сервера, а для его выполнения нужно обратиться к данным, которые обрабатываются на главном треде, значит нужно как-то синхронизироваться. Что, если вставить сюда mutex?..." И так все, не обращая внимания друг на друга. В опен спейсе, ага
Ну а то, что с какого-то уровня иерархии нужно работать, в основном, языком, так это нормально, насколько я могу судить. Т.к. начиная с некоторого количества подчиненных управление -- это именно что работа с людьми, а не с технологиями.
Здравствуйте, so5team, Вы писали:
S>Просто можно представить себе что будет творится на рабочих местах, если программисты будут "думать вслух" в прямом смысле слова: один такой "здесь почему-то потребление CPU упирается в потолок, хотя быть такого не должно, значит ща запустим профайлер, посмотрим... Ага, вот здесь мы жрем слишком много, но почему?..." А за соседним столом другой: "этот запрос приходит на тред веб-сервера, а для его выполнения нужно обратиться к данным, которые обрабатываются на главном треде, значит нужно как-то синхронизироваться. Что, если вставить сюда mutex?..." И так все, не обращая внимания друг на друга.
Вот представь себе все это, только они при этом еще собираются кучками по 2-30 человек и делают это попеременно.
Здравствуйте, Codealot, Вы писали:
C>Ты действительно пытаешься сказать, что компилятор требует меньшей культуры разработки, чем сраный фейсбук?
Представь себе да. Если не путать сложность и культуру разработки, то в этом утверждении ничего странного нет. Именно в продуктах с древней историей очень часто культура разработки никакая (я работал над компилятором, если что). Но главное не это, Интел продает чипы, а не софт. Если убрать интеловский компилятор, то не изменится практически ничего, чего нельзя сказать об их чипах. В компаниях типа Интела первый сорт это разработчики железа, а не программисты.
Здравствуйте, Codealot, Вы писали:
S>>Компилятор для вот этого языка. C>Выглядит не очень серьезно.
Не важно как выглядит для человека со стороны, главное что всякие автодески и прочие боинги платили за этот компилятор очень приличные деньги.
S>>А совсем недавно пришлось работать с одинм не очень публичным интеловским API — далеко не фонтан. C>Вебсайт у фейсбука — тоже далеко не фонтан.
Да, но он работает и им пользуются сотни миллионов и он приносит миллионы в день. Интеллу миллионы приносят чипы, а не компилятор.
Здравствуйте, Skorodum, Вы писали:
S>Не важно как выглядит для человека со стороны, главное что всякие автодески и прочие боинги платили за этот компилятор очень приличные деньги.
За Therac-25 тоже заплатили очень приличные деньги. А уж сколько бабла было просрано на Rational Rose...
S>Да, но он работает и им пользуются сотни миллионов и он приносит миллионы в день. Интеллу миллионы приносят чипы, а не компилятор.
1. И какое это имеет отношение к "культуре разработки", о которой ты говорил?
2. Интелу чипы приносят многие десятки миллиардов. А компилятор — миллионы.
Здравствуйте, landerhigh, Вы писали:
L>Здравствуйте, mogadanez, Вы писали:
M>>Тоже самое как повара могут проверить на умение шинковки например, или столяра как он гвоздь забъет и не будет ли вбивать шурупы.
L>
L>Человек, который так будет проверять повара или столяра, сильно рискует нанять повара на стоярные работы.
Здравствуйте, Sharov, Вы писали:
S>Да, наиболее хайповые американские ит компании -- fb, amzn, apple, netflix, goog. S>Можно и мс добавить. Но в этих компания дрючат гномиков и системный дизайн S>на собеседования. Как в мс -- не знаю.
В гугле точно уже не дрючат. В остальных — не знаю, по обстановке.
Здравствуйте, netch80, Вы писали:
S>>Да, наиболее хайповые американские ит компании -- fb, amzn, apple, netflix, goog. S>>Можно и мс добавить. Но в этих компания дрючат гномиков и системный дизайн S>>на собеседования. Как в мс -- не знаю. N>В гугле точно уже не дрючат. В остальных — не знаю, по обстановке.
Здравствуйте, Codealot, Вы писали:
C>Здравствуйте, Worminator X, Вы писали:
WX>>Большинству проектов не нужны гуру (это уровень архитектора, который меняется редко), а нужны надежные и исполнительные кодеры для решения текущих задач, разгребания рутины. Нужный уровень все равно будет обеспечен аджайлом и паттернами, главное от программиста — быть надежным, укладываться в сроки и уметь обучаться при необходимости. Из победителей олимпиад часто выходят посредственные работники, которые считают себя звездами, но могут легко завалить проект. Программист (в энтерпрайзе, по крайней мере) — это скорее электрик, чем ученый.
C>Большинство нанимателей этого не понимает. Почти каждый уверен, что уж ему то позарез нужны гуру из гуру, а все остальные компании лаптем щи хлебают.
Глупости оба говорите. Во-первых, человек — это априори самый ненадёжный элемент бизнеса, а во-вторых, лучше в команде путь будет "лишний ум", чем "лишний тугодум". Да и "лишним" он не будет никогда — при обсуждении архитектуры и конкретных воплощений, как раз чем больше светлых голов, тем лучше. Для развития продукта — опять же нужны специалисты, а не "исполнительные кодеры" — они "нутром чуют", что и куда надо развивать.
Кроме того, не забываем простейший человеческий фактор: "главный сенсей" заболел/женился/помер/иммигрировал — кем заменять? Сворой джунов? Даже просто толковый спец есть в команде — уже хорошо.
На одной из моих работ я как-то спросил: вы же меня наняли, а чего вакансия всё ещё висит? (вполне такой логичный вопрос новичка, которому вовсе не хочется, чтобы его кем-то заменили) Мне ответили "шокирующую правду" — "А мы вообще никогда не прекращаем процесс найма! Специалисты нужны всегда". Вот так бесконечно водя неводом, они вылавливают жемчужины, которые на миг оказались на маркете. Профукаешь — будешь ещё год водить неводом впустую.
B>У п-стов нет медалей, "чёрных поясов", малиновых штанов и грамот "лучший погромизд года".
Нужно создать гильдию программистов, в которой заказчики будут выдавать программистам квесты, а за их выполнение — кроме денег, гильдия будет присуждать програмистам ранги от F(низший) до A(высший) или S(достижения мировых масштабов). У какой-нибудь игровой конторы уже и ПО готовое есть.
Друга ищи не того, кто любезен с тобой, кто с тобой соглашается, а крепкого советника, кто полезного для тебя ищет и противится твоим необдуманным словам.
Здравствуйте, alpha21264, Вы писали:
A>Обычно на собеседовании тебя просят рассказать о себе (в смысле про прошлую работу), A>и сразу становится всё ясно.
Здравствуйте, mogadanez, Вы писали:
M> Что касается "посидеть — подумать" — по моему опыту это вполне коррелирует с общей производительностью человека в дальнейшем. если есть два равных человека — один быстрый как пчела другому надо посидеть подумать — я выберу первого. не один раз приходилось расставаться с людьми за низкую производительность, когда на собеседовании убедили себя что он не медленный а обстоятельный
Но если быстрый, как пчела, спотыкается о сложную задачу, когжа нужно именно посидеть- подумать. А "медленный" — посидел-подумал, и выдал результат? Как вместе с водой не выплеснуть и ребёнка?
Здравствуйте, Sharov, Вы писали:
S>Для этого ввели в крупных компаниях так называемое system design interview.
Дизайн интервью обычно дают архитекторам. А разработчикам уже обычно такое не дают, ибо не их это задача.
2Baiker
Ну, нет универсальный программистов уже давно. Не сможет человек даже с 10 годами стажа в sql или разработке монолита влиться в проект и стать мидлом на питоне на микросервисной архитектуре.
Вот сейчас ищем разработчика-питониста. Опытные разрабы на простой вопрос — какие знаете способы интеграции между АС — начинают мычать что-то несуразное. Кафку многие в глаза не видели. Ну, ладно, Кафку — вообще асинхронного обмена не пробовали живьем. Ну, а смысл при каких угодно регалиях и прошлом опыте брать людей без опыта в конкретно нашей текущей технологии?
Здравствуйте, gress, Вы писали:
S>>Для этого ввели в крупных компаниях так называемое system design interview. G>Дизайн интервью обычно дают архитекторам. А разработчикам уже обычно такое не дают, ибо не их это задача.
Не знаю, но насколько понял, в гуглах и фб дают вообще всем. Может кроме самых начинающих, а когда
уже какой-никакой есть опыт, то скорее всего спросят. А что в этом такого, кроме архитекторов никто
не должен разбираться, как устроены и работают масштабные сервисы? Хотя бы на понятийном
уровне понимать надо практически всем.
G>Вот сейчас ищем разработчика-питониста. Опытные разрабы на простой вопрос — какие знаете способы интеграции между АС — начинают мычать что-то несуразное. Кафку многие в глаза не видели. Ну, ладно, Кафку — вообще асинхронного обмена не пробовали живьем. Ну, а смысл при каких угодно регалиях и прошлом опыте брать людей без опыта в конкретно нашей текущей технологии?
Ну все теперь, конченные люди, раз Кафку не видели. Вот это типичное отличие нашего подхода к западному --
там смотрят на более общие, абстрактные вещи, в том числе сис. дизайн, как человек думает, подход к решение.
А у нас дрючат конкретное api -- не знаешь, досвидание. Поэтому там -- ит инновационное, а здесь -- догоняющее.
Здравствуйте, Sharov, Вы писали:
S>Не знаю, но насколько понял, в гуглах и фб дают вообще всем. Может кроме самых начинающих, а когда S>уже какой-никакой есть опыт, то скорее всего спросят. А что в этом такого, кроме архитекторов никто S>не должен разбираться, как устроены и работают масштабные сервисы? Хотя бы на понятийном S>уровне понимать надо практически всем.
У нас сейчас на собес разработчика дается 1 час на все — общее интервью с вопросами об опыте, вопросами о проекте и компании, техническая часть. HR тоже свои вопросы задает.
На дизайн-интервью для собеседования разработчика обычно минут 10 есть, не больше. Полноценное дизайн-интервью — это час.
S>Ну все теперь, конченные люди, раз Кафку не видели. Вот это типичное отличие нашего подхода к западному -- S>там смотрят на более общие, абстрактные вещи, в том числе сис. дизайн, как человек думает, подход к решение. S>А у нас дрючат конкретное api -- не знаешь, досвидание. Поэтому там -- ит инновационное, а здесь -- догоняющее.
Кафка — не единственный способ асинхронного обмена. Хоть с какой-нибудь шиной поработали бы или с RabbitMQ. Опять-таки, как ты себе представляешь человека, который может успешно пройти современное дизайн-интервью, не имея представления об асинхронном обмене? Что он может сказать о событийно-ориентированной архитектуре?
Нет времени и бюджета на то, чтобы новый разработчик погружался в незнакомую ему технологию. У нас проекты, сроки, обязательства. Денег на переобучение человека со стороны мне просто никто не даст.
— "А мы вообще никогда не прекращаем процесс найма! Специалисты нужны всегда". Вот так бесконечно водя неводом, они вылавливают жемчужины, которые на миг оказались на маркете. Профукаешь — будешь ещё год водить неводом впустую.
