Если у компании такие детальные планы, то это должно быть отражено в объявлении о работе. Или кадровик должен такое озвучить сам. А не морочить голову дурацкими вопросами.
Озвучить что? Полный план найма, бюджет, количество ставок, годовые планы затронутых подразделений и их KPI? Чтобы кандидат не дай бог не напрягся и не подумал 30 секунд над вопросом?
Какие ещё варианты ответа ожидает услышать сотрудник отдела кадров на этот вопрос?
Те, которые помогут оценить, вероятность того что кандидат через три месяца пойдет в другое место. И что нужно сделать или предложить, чтобы кандидат остался.
Что он способен трудиться, даже не видя непосредственных результатов своего труда, усидчив;
В большей степени способен учиться, систематически работать с информацией, вычленять необходимое из огромного массива знаний.
Либо покупал преподам коньяк. Или был спортсменом или другим "активистом", за что получал поблажки и автоматы. Или просто сдавал на трояк чужие лабы, купленные за пивко.
Как минимум не является неадекватом, раз его не выперли за годы обучения;
Чтоб тебя выперли за поведение нужно быть вообще в край отбитым. Сколько таких, полпроцента?
Кул стори: в региональном филиале моего вуза пара кексов отмудохала прям в здании препода за отказ проставить зачет. Угадайте, сколько из них были отчислены, а сколько - получили диплом питерского вуза (далеко не самого донного, кстати).
Более находчив, способен договариваться, находить компромисы, лучше социализован;
Хаха, нет.
Навскидку, из моего потока хоть как-то квалифицированы и способны работать по специальности на момент выпуска были где-то процентов 15.
Конечно стоит, потому я и сказал, что формулировки мудацкие. Но так-то вопросы вполне резонные, особенно если речь о миддле+ - эта аудитория уже нюхнула пороху и обычно имеет хоть какие-то представления о том, что нравится, а что нет.
Если собеседующий не в состоянии по-человечески эти вопросы сформулировать - минус собеседующему. Если собеседуемый не в состоянии на них ответить кроме как петросянством - минус собеседуемому.
Вы думаете люди так и планируют: "через 3 года мне надоест жарить таски и я захочу быть тимлидом"?
А я этого и не писал. И вы правы, вопрос в том числе и про ближайшую перспективу. Если через 5 лет человек хочет быть там-то, то какие шаги он собирается предпринять сейчас? Что ему для этого нужно? Как это коррелирует с ближайшими планами компании?
Кем вы видите себя через 5 лет? В таком случае, можно ответить - вижу себя человеком пауком.
Через год-два выясняется, что кандидат хочет стать фуллстеком, тимлидом, архитектором, а компании нужно, чтоб он сидел и выполнял задачи 5х8. Или наоборот: компания нанимает синьора, чтоб через полгода-год нанять ему пару миддлов в подчинение, а синьор в гробу это видал, он хочет таски жарить. Но зачем обсуждать ожидания на собесе, если можно шутить, верно?
Почему вы пришли к нам на собеседование? Вы меня позвали, я и пришел (пришла).
20 баксов - это 20 баксов? Прям реально нет разницы, что разрабатывать, как разрабатывать, лишь бы деньги платили?
Формулировки вопросов, конечно, мудаковатые, но таки от разработчика чуть выше джуна ожидается некая способность к коммуникации с другими людьми.
От проекта к проекту отличается, надо мерять. На моем прошлом жирном проекте вроде около половины смогли срезать.
После какого числа пакетов модульная сборка начинает обгонять обычную сборку?
Та же история. В теории - с любого, хотя бы за счёт более агрессивного кеширования.
Почему параллельная сборка не работает в проекте "на пакетах"?
Работает, но сильно ограниченно. Шаги сборки нельзя выполнять параллельно: сначала препроцессинг, потом компиляция, потом дексинг, потом упаковка. Какие-то шаги типа дексинга плохо параллелятся внутри, если у вас есть такой шаг - он становится бутылочным горлышком. Компилятор может параллелить работу, но ему всё равно сначала нужно переварить весь код модуля чтобы понять, что поменялось, что нужно пересобрать, и что из этого можно распараллелить.
Если же у вас есть модули, то у системы сборки есть простые и четкие критерии того, что можно гарантированно параллелить и кешировать, а что нужно пересобрать. Если два модуля не зависят друг от друга - их можно параллелить. Если в модуле нет изменений и ни одна из его зависимостей не поменялась - модуль не нужно пересобирать, даже смотреть на него не нужно.
Можете сами прикинуть, что проще обработать: граф модулей из 30 нод или граф зависимостей классов из нескольких тысяч нод.
Потому что в терминах Gradle и Maven, которые де-факто стандарты для Java/Kotlin разработки, подпроекты называются модулями. Библиотека - внешняя зависимость, модуль - обособленная часть проекта.
в остальных случаях деление почти всегда избыточно, а пакетов хватает с лихвой.
Пока ваше приложение умещается в десяток-другой экранов - да. А потом наступает момент, когда вы начинаете тратить по 5-10-15 минут на сборку, потому что у вас мономодуль и фишки типа параллельной сборки и кеширования вам недоступны.
Вот да. Люди до сих пор помнят потерю большой части расширений, но при этом как-то очень резво забыли, как одна подвисшая или упавшая вкладка ломала к чертям весь браузер целиком.
Вы не абсолютными числами считайте, а относительными. Вырезать город под ноль 2000 лет назад - норма жизни, а сейчас за десяток казненных мирных жителей кипишь поднимается.
поощряемые мозгом действия, ведущие к восстановлению ресурсов
Поправка - действия, которые мозг считает полезными и ведущими к восстановлению ресурсов. Проблема в том, что он достаточно туп, и не всегда в состоянии распознать контекст.
Да даже сам процесс прохождения собесов дофига занимает. Спланировать собес, чтоб обоим удобно было, пройти, подождать фидбек, повторить для следующего этапа - вот уж и пара-тройка недель прошла.
Нет никакой загадки, вопрос масштабирования. Чтобы обеспечить едой и транспортом 140 миллионов человек нужны сотни тысяч людей, которые будут над этим работать.
Чтобы обеспечить 140 миллионов недорогим сервисом для просмотра фильмов нужно.. хз, пара тысяч человек?
Техническим собеседованием и/или тестовым заданием.
Смотреть на знания кандидата и его, так сказать, деловые качества, а не на бумажки.
Озвучить что? Полный план найма, бюджет, количество ставок, годовые планы затронутых подразделений и их KPI? Чтобы кандидат не дай бог не напрягся и не подумал 30 секунд над вопросом?
Те, которые помогут оценить, вероятность того что кандидат через три месяца пойдет в другое место. И что нужно сделать или предложить, чтобы кандидат остался.
Ну если ваша стратегия найма - подходить на улице к случайным прохожим, то бог в помощь.
В текущем контексте как раз очень важно иметь планы на год вперед - и основной, и пару запасных.
Либо покупал преподам коньяк. Или был спортсменом или другим "активистом", за что получал поблажки и автоматы. Или просто сдавал на трояк чужие лабы, купленные за пивко.
Чтоб тебя выперли за поведение нужно быть вообще в край отбитым. Сколько таких, полпроцента?
Кул стори: в региональном филиале моего вуза пара кексов отмудохала прям в здании препода за отказ проставить зачет. Угадайте, сколько из них были отчислены, а сколько - получили диплом питерского вуза (далеко не самого донного, кстати).
Хаха, нет.
Навскидку, из моего потока хоть как-то квалифицированы и способны работать по специальности на момент выпуска были где-то процентов 15.
Нормально.
Конечно стоит, потому я и сказал, что формулировки мудацкие. Но так-то вопросы вполне резонные, особенно если речь о миддле+ - эта аудитория уже нюхнула пороху и обычно имеет хоть какие-то представления о том, что нравится, а что нет.
Если собеседующий не в состоянии по-человечески эти вопросы сформулировать - минус собеседующему. Если собеседуемый не в состоянии на них ответить кроме как петросянством - минус собеседуемому.
А я этого и не писал. И вы правы, вопрос в том числе и про ближайшую перспективу. Если через 5 лет человек хочет быть там-то, то какие шаги он собирается предпринять сейчас? Что ему для этого нужно? Как это коррелирует с ближайшими планами компании?
Какая разница что есть? Там везде нужно в рот засовывать.
Через год-два выясняется, что кандидат хочет стать фуллстеком, тимлидом, архитектором, а компании нужно, чтоб он сидел и выполнял задачи 5х8. Или наоборот: компания нанимает синьора, чтоб через полгода-год нанять ему пару миддлов в подчинение, а синьор в гробу это видал, он хочет таски жарить. Но зачем обсуждать ожидания на собесе, если можно шутить, верно?
20 баксов - это 20 баксов? Прям реально нет разницы, что разрабатывать, как разрабатывать, лишь бы деньги платили?
Формулировки вопросов, конечно, мудаковатые, но таки от разработчика чуть выше джуна ожидается некая способность к коммуникации с другими людьми.
От проекта к проекту отличается, надо мерять. На моем прошлом жирном проекте вроде около половины смогли срезать.
Та же история. В теории - с любого, хотя бы за счёт более агрессивного кеширования.
Работает, но сильно ограниченно. Шаги сборки нельзя выполнять параллельно: сначала препроцессинг, потом компиляция, потом дексинг, потом упаковка. Какие-то шаги типа дексинга плохо параллелятся внутри, если у вас есть такой шаг - он становится бутылочным горлышком. Компилятор может параллелить работу, но ему всё равно сначала нужно переварить весь код модуля чтобы понять, что поменялось, что нужно пересобрать, и что из этого можно распараллелить.
Если же у вас есть модули, то у системы сборки есть простые и четкие критерии того, что можно гарантированно параллелить и кешировать, а что нужно пересобрать. Если два модуля не зависят друг от друга - их можно параллелить. Если в модуле нет изменений и ни одна из его зависимостей не поменялась - модуль не нужно пересобирать, даже смотреть на него не нужно.
Можете сами прикинуть, что проще обработать: граф модулей из 30 нод или граф зависимостей классов из нескольких тысяч нод.
Потому что в терминах Gradle и Maven, которые де-факто стандарты для Java/Kotlin разработки, подпроекты называются модулями. Библиотека - внешняя зависимость, модуль - обособленная часть проекта.
https://en.cppreference.com/w/cpp/language/modules
Пока ваше приложение умещается в десяток-другой экранов - да. А потом наступает момент, когда вы начинаете тратить по 5-10-15 минут на сборку, потому что у вас мономодуль и фишки типа параллельной сборки и кеширования вам недоступны.
Вот да. Люди до сих пор помнят потерю большой части расширений, но при этом как-то очень резво забыли, как одна подвисшая или упавшая вкладка ломала к чертям весь браузер целиком.
Давно пора. А то ишь ты, хотят жрать в ресторанах и в отпуска ездить.
Вы не абсолютными числами считайте, а относительными. Вырезать город под ноль 2000 лет назад - норма жизни, а сейчас за десяток казненных мирных жителей кипишь поднимается.
Поправка - действия, которые мозг считает полезными и ведущими к восстановлению ресурсов. Проблема в том, что он достаточно туп, и не всегда в состоянии распознать контекст.
Да даже сам процесс прохождения собесов дофига занимает. Спланировать собес, чтоб обоим удобно было, пройти, подождать фидбек, повторить для следующего этапа - вот уж и пара-тройка недель прошла.
Нет никакой загадки, вопрос масштабирования. Чтобы обеспечить едой и транспортом 140 миллионов человек нужны сотни тысяч людей, которые будут над этим работать.
Чтобы обеспечить 140 миллионов недорогим сервисом для просмотра фильмов нужно.. хз, пара тысяч человек?