Да элементарно: благодаря скраму они еще до факапа поняли, что будет факап. Ну и конечно в этом виноват скрам.
Все эти аджайлы и скрамы они не про скорость. Они про что угодно, но не скорость.
Предсказуемость, гибкость, понимание как изменение изначальных договоренностей изменят срок. Примерно понять какой срок будет реален. Про "мы команда" (вот кстати в РФ именно командная работа хромает: очень часто слышу не МЫ сделали плохо, а Он/ВЫ сделали плохо)
вы сейчас говорите про так себе джуна в компании с одним однотипным продуктом и использующей типовой стек.
Достаточно крупная компания с несколькими сотнями разработчиков, ссобственным продуктом полного цикла. и типовая карьера: команда састейн, поддержка старой версии на проде, прокачка скилов до толкового джуна, замечают в отделе постарше внутренний перевод на уровень недомидла. там жесткий энтерпрайз и куча задач которые сеньерам не интересны но отличают настоящий продукт: разные хвосты к мониторингу, ci. Всякие написать unit файл сервиса, обвернуть утилиты тестирования в rpm пакеты. вообщем те задачи когда знаю что писать и учусь как писать. ну и плюс рост компании и рост отделов. да при этом стек хоть и широк, но в одной сфере и специфичен.
Хотя да определенные личные характеристики тоже важны.
Собственно я в текушей компании 11 лет и как раз прошел путь от джуна до руководителя группы и системного архитектора. есть еще человек 40 таких дедушек. Конечно все на позициях сеньеров, лидов и архитекторов давно.
Да спорная на самом деле статья. Все сильно зависит от того как построен бизнес, что за софт пишется, какова цена ошибки и вообще много всего. Например если вы не можете позволить себе CI (окружение изолированно) или у вас высокие требования по перфомансу — то джуны это только поддержка и багфикс. А если на фронте верстку крутить то там можно и джунами обойтись.
Опять таки бывают всякие галеры. где лучше взять самоуверенных джунов и «прокачивать их» и нескольких сеньеров.
Хотя конечно лучше вырастить сеньера из джуна. но это на самом деле признак очень хорошей компании когда. и стек технологий очень серьезный и обучение построенно хорошо и процесс ревью и тестирования (джуну не получится сильно накосячить)
ну а что было бы лучше чтобы взял, а потом придирался по пустикам, критиковал на ровном месте и в целом относился предвзято?
поймите сейчас на толковых программеров спрос высокий. и если вы претендуете на роль сеньера и действительно ее стоите… то это вы должны оценивать лицо собеседующего и выбирать где вам будет комфортнее, а не наоборот.
я же сказал "любым способом".
вариант с remove_if был только один раз.
и нет цели "засчитать" есть цель понять каков уровень у кандидата. имеет ли смысл сразу переходить на более высокий уровень или стоит поспрашивать. если не использовал итераторы в решении то я и так спросить про них могу без задачи.
если давно не работал и не помнит стл это уже звоночек (мне таки нужен стл). но пускай решит в терминах известного ему инструмента — скорее как успокаивающий фактор.
но я могу себе это позволить — у нас широкий спектр вакансий и если я вижу, что на сеньера он не тянет, но кандидат толковый могу предложить позицию пороще в том числе в команде помладше.
для этого достаточно иметь в компании такой документ как "должностная инструкция" и оформить трудовой договор с вами где вас приняли с испытательным сроком та такую то должность. и чтобы в этой инструкции не было ничего явно дискриминационного типа "не беременна".
далее вам под подпись выдают служебное задание и срок. которое вы не выполняете и вылелаете по статье
Ой все эти "гибко и масштабируется" настолько сферический конь в вакууме. У меня на практике выходило так что хорошо спроектированный и написанный код никто масштабировать и гнуть не собирается. а когда таки придет время то там будет проще переписать. А почему? А потому что в хорошем коде уже все продумано и реализованно с учетом возможных изменений требований на ближайшую перспективу. и два там так напроектированно что только сеньеров туда пускать. а то первый джун превратит всю стройную архитектуру в кусок очень сложного навоза.
И какая разница что пишут в книжках про паттерны проектирования. Мы тут сейчас комментируем претендента на должность сеньера. который забыл про virtual… Ну не верю я в это. можно забыть про что то редкое или необязательное. но виртуал я не зная языка скажу что это про наследование, динамический полиморфизм и позднее связывание речь идёт.
"Во валит". На самом деле вопрос с подвохом. Варианты от банального цикла по итераторам до алгоритмов. кто то пытается с наскоку цикл с auto. кого то можно спросить про валидность итераторов после манипуляций с контейнером.
И да помогает. Практика показывает что нормальный программер довольно просто решает такую задачку, чуть раскрепощается и меньше волнуется.
Но все таки основная цель отсеять мусор как можно раньше.
Причем эту задачу я мог бы просить НR задавать перед приглашением. Но я хочу видеть сам: у меня был сотрудник — как программист талантливейший. Но самооценка ниже плинтуса. любой вопрос на собеседовании — волновался и тупил вплоть до таблицы умножения. Но все равно видно делал человек подобное раньше или нет
А так да. дальше уже можно спрашивать и про интрузивные контейнеры и про сложности алгоритмов с подковыками: например когда тупой поиск перебором
в векторе оказываетсяя быстрее поиска по ключу в ассоциативном контейнере.
Что? Какие HashMap и сложность?
У меня на собеседовании первый вопрос: есть список std:list data любым способом удалить из него элементы с четным значением.
С тем, кто хотя бы попытается написать цикл с итератором уже можно пробовать говорить на должность С++ разраба. Увы на это только 10% отвечают...
Причем этот вопрос актуален даже для сеньеров. Там проблема в том, что если пришел действительно стоящий человек то его подобное может оскорбить.
Видимо одинаковые мысли приходят. Мы запилили крайне похожую вещь для 1.7 аналогично девелоперы отказались (но мы с++, так что джава код там был наверное не очень).
Идея полностью аналогичная + запросы к таким индексам идут через отдельный тредпул. Плюс держим некое количество загруженных «замороженных» индексов в кеше с неким подобим сегментированного LRU алгоритма вытеснения. С учетом того что активных данных у нас примерно 10/300 экономия была существенная.
Для любого незакрытого индекса на диске требуется оперативная память как минимум 0,1% -0,5% (зависит от маппинга и используемых фич) от объема это индекса на диске. Просто для открытия шардов. Что в купе с требованием про HEAP_SIZE < 32g и тем что хип нужен не только чтобы индексы открыть — приводит к ограничению 16 — 24 ТБ индекса на одной ноде. Дальше придется городить огород с несколькими инстансами на сервер. Причем это еще без всяких сложных запросов.
Очень долгая миграция шардов с узла на узел. Гораздо быстрее «холодные» индексы закрыть, потом rsync скопировать а потом открыть. Но удается это не очень всегда.
Размер кластера ограничен количеством шардов в нем. На практике с ростом числа индексов и шардов просто катастрофически увеличивается время создания новых индексов. Причем в старых версиях просто больше 3х узлов при 20 тысячах индексов (пара шардов на каждый). В новых версиях лучше.
Если активно используете scroll|scan см пункт первый. Ибо scroll_id включает в себя идентификаторы всех шард на которых хоть что-то нашлось пригодное для скана. У нас он достигал значений в сотни мегабайт на кластере из 20-30 узлов с сотней тысяч индексов.
Частично помогла группировка узлов в «микрокластера» и трайб поверх, однако отказались от трайба и самостоятельно группируем результаты ибо запросы простые.
Крайне ограниченная возможность поменять маппинг. Причем даже простое добавление поля приводит к необходимости переиндексировать данные (но это правда на ЕS 1.7, в свежих не знаю)
есть старый дедовский метод: из стопки резюме выбирается половина и выбрасывается в корзину, не читая, со словами: «неудачники нам не нужны». На самом деле я видел и подобно но не в IT
Не соглашусь, чтобы собеседовать крутых чуваков — не надо быть более крутым чуваком. Собственно в этом и статья. А вот как раз когда собеседующий во время интервью начинает меряться с собеседуемыми яйцами — начинается «пафос».
Не к ночи помянутый Яндекс (со слов бывшего моего сотрудника): успешно прошел семь кругов ада и кучу собеседований, ну а в итоге те же мапы, сортировка пузырьком, макароны в коде и срач на ревью как лучше назвать переменную.
Здраво написано, насчет немедленного ответа сразу… Иногда бывает нужно самому сесть собраться с мыслями, вспомнить собеседование и решить. Но да, практически всегда письмо в HR с отзывом о кандидате пишу не позже конца дня. Даже случаев «всех посмотреть» — мало было.
Я вот сейчас сижу и представляю себе электрика с абстрактным мышлением, который ежедневно читает статейки от какого нибудь сименса. Участвует в профессиональных срачиках: «под каким углом изгибать провода», «какой цвет изоляции для фазы лучший».
Увы, но практика показывает что научить «быть программистом» просто так нельзя. Так же как и быть например врачом. Нужно нечто большее.
Вот два ВУЗа учат и учат, а толку — ноль.
Да элементарно: благодаря скраму они еще до факапа поняли, что будет факап. Ну и конечно в этом виноват скрам.
Все эти аджайлы и скрамы они не про скорость. Они про что угодно, но не скорость.
Предсказуемость, гибкость, понимание как изменение изначальных договоренностей изменят срок. Примерно понять какой срок будет реален. Про "мы команда" (вот кстати в РФ именно командная работа хромает: очень часто слышу не МЫ сделали плохо, а Он/ВЫ сделали плохо)
Достаточно крупная компания с несколькими сотнями разработчиков, ссобственным продуктом полного цикла. и типовая карьера: команда састейн, поддержка старой версии на проде, прокачка скилов до толкового джуна, замечают в отделе постарше внутренний перевод на уровень недомидла. там жесткий энтерпрайз и куча задач которые сеньерам не интересны но отличают настоящий продукт: разные хвосты к мониторингу, ci. Всякие написать unit файл сервиса, обвернуть утилиты тестирования в rpm пакеты. вообщем те задачи когда знаю что писать и учусь как писать. ну и плюс рост компании и рост отделов. да при этом стек хоть и широк, но в одной сфере и специфичен.
Хотя да определенные личные характеристики тоже важны.
Собственно я в текушей компании 11 лет и как раз прошел путь от джуна до руководителя группы и системного архитектора. есть еще человек 40 таких дедушек. Конечно все на позициях сеньеров, лидов и архитекторов давно.
Опять таки бывают всякие галеры. где лучше взять самоуверенных джунов и «прокачивать их» и нескольких сеньеров.
Хотя конечно лучше вырастить сеньера из джуна. но это на самом деле признак очень хорошей компании когда. и стек технологий очень серьезный и обучение построенно хорошо и процесс ревью и тестирования (джуну не получится сильно накосячить)
ну а что было бы лучше чтобы взял, а потом придирался по пустикам, критиковал на ровном месте и в целом относился предвзято?
поймите сейчас на толковых программеров спрос высокий. и если вы претендуете на роль сеньера и действительно ее стоите… то это вы должны оценивать лицо собеседующего и выбирать где вам будет комфортнее, а не наоборот.
а как связанны интерфейсы и виртуальное наследование?
может вы путаете виртуальный метод и виртуальное наследование?
я же сказал "любым способом".
вариант с remove_if был только один раз.
и нет цели "засчитать" есть цель понять каков уровень у кандидата. имеет ли смысл сразу переходить на более высокий уровень или стоит поспрашивать. если не использовал итераторы в решении то я и так спросить про них могу без задачи.
если давно не работал и не помнит стл это уже звоночек (мне таки нужен стл). но пускай решит в терминах известного ему инструмента — скорее как успокаивающий фактор.
но я могу себе это позволить — у нас широкий спектр вакансий и если я вижу, что на сеньера он не тянет, но кандидат толковый могу предложить позицию пороще в том числе в команде помладше.
если сможете найти и доказать что использовался ваш код —
для этого достаточно иметь в компании такой документ как "должностная инструкция" и оформить трудовой договор с вами где вас приняли с испытательным сроком та такую то должность. и чтобы в этой инструкции не было ничего явно дискриминационного типа "не беременна".
далее вам под подпись выдают служебное задание и срок. которое вы не выполняете и вылелаете по статье
Ой все эти "гибко и масштабируется" настолько сферический конь в вакууме. У меня на практике выходило так что хорошо спроектированный и написанный код никто масштабировать и гнуть не собирается. а когда таки придет время то там будет проще переписать. А почему? А потому что в хорошем коде уже все продумано и реализованно с учетом возможных изменений требований на ближайшую перспективу. и два там так напроектированно что только сеньеров туда пускать. а то первый джун превратит всю стройную архитектуру в кусок очень сложного навоза.
И какая разница что пишут в книжках про паттерны проектирования. Мы тут сейчас комментируем претендента на должность сеньера. который забыл про virtual… Ну не верю я в это. можно забыть про что то редкое или необязательное. но виртуал я не зная языка скажу что это про наследование, динамический полиморфизм и позднее связывание речь идёт.
"Во валит". На самом деле вопрос с подвохом. Варианты от банального цикла по итераторам до алгоритмов. кто то пытается с наскоку цикл с auto. кого то можно спросить про валидность итераторов после манипуляций с контейнером.
И да помогает. Практика показывает что нормальный программер довольно просто решает такую задачку, чуть раскрепощается и меньше волнуется.
Но все таки основная цель отсеять мусор как можно раньше.
Причем эту задачу я мог бы просить НR задавать перед приглашением. Но я хочу видеть сам: у меня был сотрудник — как программист талантливейший. Но самооценка ниже плинтуса. любой вопрос на собеседовании — волновался и тупил вплоть до таблицы умножения. Но все равно видно делал человек подобное раньше или нет
А так да. дальше уже можно спрашивать и про интрузивные контейнеры и про сложности алгоритмов с подковыками: например когда тупой поиск перебором
в векторе оказываетсяя быстрее поиска по ключу в ассоциативном контейнере.
Что? Какие HashMap и сложность?
У меня на собеседовании первый вопрос: есть список std:list data любым способом удалить из него элементы с четным значением.
С тем, кто хотя бы попытается написать цикл с итератором уже можно пробовать говорить на должность С++ разраба. Увы на это только 10% отвечают...
Причем этот вопрос актуален даже для сеньеров. Там проблема в том, что если пришел действительно стоящий человек то его подобное может оскорбить.
Идея полностью аналогичная + запросы к таким индексам идут через отдельный тредпул. Плюс держим некое количество загруженных «замороженных» индексов в кеше с неким подобим сегментированного LRU алгоритма вытеснения. С учетом того что активных данных у нас примерно 10/300 экономия была существенная.
max_restore_bytes_per_sec
Throttles per node restore rate. Defaults to 40mb per second.
Для любого незакрытого индекса на диске требуется оперативная память как минимум 0,1% -0,5% (зависит от маппинга и используемых фич) от объема это индекса на диске. Просто для открытия шардов. Что в купе с требованием про HEAP_SIZE < 32g и тем что хип нужен не только чтобы индексы открыть — приводит к ограничению 16 — 24 ТБ индекса на одной ноде. Дальше придется городить огород с несколькими инстансами на сервер. Причем это еще без всяких сложных запросов.
Очень долгая миграция шардов с узла на узел. Гораздо быстрее «холодные» индексы закрыть, потом rsync скопировать а потом открыть. Но удается это не очень всегда.
Размер кластера ограничен количеством шардов в нем. На практике с ростом числа индексов и шардов просто катастрофически увеличивается время создания новых индексов. Причем в старых версиях просто больше 3х узлов при 20 тысячах индексов (пара шардов на каждый). В новых версиях лучше.
Если активно используете scroll|scan см пункт первый. Ибо scroll_id включает в себя идентификаторы всех шард на которых хоть что-то нашлось пригодное для скана. У нас он достигал значений в сотни мегабайт на кластере из 20-30 узлов с сотней тысяч индексов.
Частично помогла группировка узлов в «микрокластера» и трайб поверх, однако отказались от трайба и самостоятельно группируем результаты ибо запросы простые.
Крайне ограниченная возможность поменять маппинг. Причем даже простое добавление поля приводит к необходимости переиндексировать данные (но это правда на ЕS 1.7, в свежих не знаю)
Не к ночи помянутый Яндекс (со слов бывшего моего сотрудника): успешно прошел семь кругов ада и кучу собеседований, ну а в итоге те же мапы, сортировка пузырьком, макароны в коде и срач на ревью как лучше назвать переменную.
Увы, но практика показывает что научить «быть программистом» просто так нельзя. Так же как и быть например врачом. Нужно нечто большее.
Вот два ВУЗа учат и учат, а толку — ноль.