Придерживаюсь ровно таких же принципов. Главное в кандидате не знание технологий, главное - умеет ли он думать. И именно это я проверяю на собеседовании. Да, используя технические вопросы, но мы с ним копаем глубже и шире, без оглядки на "правильные" ответы. Их просто нет, правильных. Только так и можно проверить, может ли человек анализировать и синтезировать. Но есть проблема, на поток такое не поставить никогда. Очень многое зависит от собеседующего руководителя (боже упаси, не розововолосой зумерши-эльфийки!), от его заинтересованности в успешном результате проекта/продукта, умении понять/почувствовать нужного человека (эмпатия?).
Что касается дурака-руководителя. Как правило, с ним встречаешься уже в конце, часто после оффера. Так что приходится терпеть какое-то время, получать опыт, и уходить.
Вы, по сути, изобрели велосипед со своими корпоративными приблудами. Большинство компаний давно уже используют эту довольно простую схему: "скрининг", техсобес, собес с тимлидом/командой, оффер, но до вас почему-то это только дошло, как до той утки на седьмые сутки.
У меня тоже, как у многих здесь в комментариях есть личный опыт собесов в Яндексе. И как у подавляющего большинства исключительно негативный. Уж не знаю, в какой момент вы дошли до того, что программисту для написания кода нужно давать привычный текстовый редактор хотя бы (интересно, когда вы дойдёте до идеи дать ему привычную среду разработки?), а не бумажку и ручку. Вот именно это меня больше всего взбесило: необходимость писать код на бумажке после 20 с лишним лет опыта использования различных текстовых редакторов / сред. Тогда я получил отказ, фидбека мне не дали, я его несколько недель выбивал из девочки-хээрщицы. И что по итогу? Фидбек: "Коллеги отметили, что вы хорошо знаете алгоритмы и структуры данных (я готовился 2 недели, так-то они мне нужны раз в год в лучшем случае) и быстро умеете адаптировать решение под изменившиеся требования (типа, а если у вас мало памяти, но много процессора), однако вы допускаете много ошибок и делаете много исправлений". Нуёпта! Конечно, я делаю много ошибок и исправлений, когда пишу на бумаге код на абстрактном языке программирования, я привык к возможностям редактора текста, где я могу быстро обложить какой-то кусок кода блоком if или типа того, у меня это уже в пальцах.
У меня вообще сложилось впечатление, что Яндексу нужны исключительно вчерашние студенты, без семьи, без других интересов, готовые батрачить по 12 часов в день за "мы же семья" и хрен в кармане.
Честно говоря, на текущий момент я не представляю, чем меня нужно заманивать на собес в Яндекс сейчас, чтобы я на него сходил.
Критикуя предлагай? Хорошо. Самая рабочая схема найма, которая мне попадалась за более 30 лет профессионального опыта в разных странах и компаниях примерно такая. Кадровичка, пользуясь работными сайтами, готовит список потенциальных кандидатов, отбирая их по типовым критериям: опыт, технологии, зарплатные ожидания соответствуют имеющейся зарплатной вилке. Кадровичка передаёт эти списки тимлидам команд, которым нужны сотрудники соответствующей квалификации. Тимлиды читают резюме и выбирают потенциально интересных кандидатов и передают эти списки кадровичке. Кадровичка связывается с кандидатами и назначает собесы. Тимлиды проводят собесы сами (в редких случаях делегируют своим сеньорам)! Тимлиды! Сами! Ведь именно они знают, кто им нужен, именно они знают, о чём спросить на конкретную должность.
Не надо всех кандидатов пропускать через шаблонные собесы, результатами которых потом, типа, будет удобно пользоваться тимлидам! Тимлиды не доверяют этим результатам, поэтому опять проводят собес по-своему. Дайте тимлиду самому искать подходящих кандидатов в команду. Вы хотя бы попробуйте так сделать. Да розововолосые хээрщицы будут против, они почувствуют страх сокращения, поскольку в этой схеме они лишние, но тимлиды и кандидаты скажут только "спасибо".
Предложенное в статье больше похоже на фантазии дилетанта в области найма. Этакая зелёная девочка хэар переносит свой опыт выбора жениха на собеседование с разработчиками.
Перед собеседованием можно добавить этап выполнения тестового задания. Хорошее тестовое задание должно быть максимально приближено к реальным задачам. Чтобы оценить навыки, можно предложить что-то объёмное, например, разработку небольшого, но полнофункционального сервиса. Важно, чтобы кандидат сделал всё самостоятельно и в кратчайшие сроки — это покажет, насколько он заинтересован в позиции. Если человек отказывается от тестового задания, это говорит о недостаточной вовлечённости.
Вот ищу я работу. У меня, скажем, 10 вариантов. Если каждый из них будет давать мне тестовое задание, да ещё и приближенное к реальным задачам... Ясно видно, что наша девочка никогда не программировала и не понимает, сколько это занимает времени. Я про реальные задачи, а не пузырьковая сортировка. Я лично от тестовых заданий всегда отказываюсь. Если настаивают, отправляю в свой гитхаб, там моего кода много, есть даже специально выполненные тестовые задания. Смотрите, оценивайте. На бесплатное заказное программирование я время, а значит и деньги, тратить не собираюсь.
Что значит "заинтересован в позиции"? Да откуда я знаю, как оно там у вас на самом деле в компании? Как там у вас там с условиями, ЗП, задачами? Почитать на сайте? Так там такие же зелёные девочки из маркетинга пишут сами не зная чего, пересыпая этот бред всяким булшитом, вроде "лидер отрасли", "ведущая компания" и т.п. Я лично всегда с известной долей настороженности отношусь к любой позиции и компании. Как там оно на самом деле у вас для меня только вскрытие покажет.
Вовлечённость? Куда? Мы ещё не познакомились, я у вас не поработал. Откуда вовлечённости взяться? Вы кто такие, чтобы я вам что-то о себе доказывал?
Сколько человек должно проводить собеседование? Оптимально 3-5. Один интервьюер может что-то упустить, а вот группа сможет задать вопросы с разных точек зрения.
Девочка, видимо, ещё не знает сколько стоит час разработчика, и сколько встреч у менеджера. Тем более это заметно, когда кандидатов поток. По-хорошему должен собеседовать только тимлид.
Дайте ему посидеть в зуме или в офисе минут 10–15, чтобы он смог привыкнуть к обстановке, успокоиться и морально подготовиться. В реальной работе нередко приходится ждать ответа коллег или заказчиков, и умение сохранять самообладание в таких ситуациях — важное качество.
10-15 минут на разогрев? Это не разогрев называется, а маринование, уважаемый кулинар. Не надо женские приёмы со свиданий распространять на деловые переговоры. Это плохой тон. Вы собираетесь сожрать мои 10-15 минут без видимой причины, это неуважение.
Один из самых показательных вопросов на собеседовании — «Почему вы хотите работать именно у нас?». Задайте его первым. Он позволяет сразу определить, насколько кандидат заинтересован в компании, изучил ли он её заранее и готов ли искренне обосновать свой выбор. Если кандидату важны только деньги, то вы быстро сможете это определить и закончить разговор не потратив впустую час‑два времени.
Про заинтересованность писал выше. Ей неоткуда ещё появиться.
У меня 10 вакансий на руках, я заинтересован в них почти одинаково, так как реальной информации не хватает. Только работа в компании и конкретной команде может показать, что вы собой представляете. Могу ещё один вопрос посоветовать: "с каким животным вы себя ассоциируете?" Он ещё более гениальный, особенно в самом начале собеседования.
Затем переходите к вопросам, о самом человеке. Наличие детей, семейное положение, планы на ближайшие годы — всё это влияет на мотивацию сотрудника и его стабильность в компании.
А на каком основании вы собрались мне задавать личные вопросы? Опять неуважение к кандидату.
Существует две стратегии задавания технических вопросов.
Это вообще шедевр. Однозначно правильные ответы можно получить только на простые вопросы. Проблема с простыми шаблонными вопросами в том, что ответы на них зазубривают. Даже не зная почти ничего по теме, человек легко пройдёт этот этап. Были у меня такие на собеседованиях. Со сложными вопросами, нельзя дать однозначный правильный вопрос, нужно задавать дополнительные вопросы. В конце концов, важно не то, как человек проходит "профессиональный ЕГЭ-угадайку", а его аналитические возможности, умение находить информацию, умение воплотить идею в код, а не вот эти ваши тесты.
Переработки, давление, дедлайны? Вот точно в такую компанию не пойду, хоть и работаю по собственной инициативе (просто самому интересно) по 10-12 часов в день. Зачем мне соковыжиматель? Мне работа нужна, где мне будет интересно, обеспечено и комфортно. Привыкли к людям как к тряпкам относиться? Тогда мне точно с вами не по пути. Прозябайте дальше и умрите, как компания!
После прохождения всех этапов важно не торопиться с ответом. Подождите неделю, две, а лучше три, чтобы кандидат прочувствовал всю значимость решения. Заодно это позволит проверить, насколько он заинтересован: если начнёт писать и спрашивать, значит, действительно хочет работать в вашей компании. Важно создать ощущение, что кандидат должен доказать свою ценность, а не наоборот.
А ещё лучше вообще не давайте ответа, пусть приползёт к вашему офису и просидит под дождём неделю без пищи и только на воде из атмосферных осадков. Зарплату от должен будет платить вам, а не вы ему. С женой пусть разведётся, квартиру подарит вам, научиться раболепно улыбаться и заискивать, пусть благодарит до пенсии за возможность "поработать" в подобной компании. Ах, да, и пусть в 6 утра каждый день, включая выходные и отпуск, поёт гимн компании, высоко, гордо задрав голову к динамику в потолке офисной комнаты вместе со всей командой.
Короче, автор, ты бредишь. Лично я, столкнувшись с тобой на собеседовании, послал бы тебя по известному адресу. Уйди из найма! И коллег своих подобных забери с собой! Вы слишком глупы для IT.
У нас просто разный профессиональный опыт. И я Вас прекрасно могу понять. Пока дальше первого языка и среды разработки не глянешь, всё кажется просто и логично. Стоит расширять кругозор и спокойно относиться к чужому опыту и мнению.
Конечно, никто ничего не запрещает, и всегда можно натянуть сову на глобус при большом желании. Вот только в MVC модель обновляет View, а в Delphi (как я его запомнил) ничего подобного не было. Были обработчики событий (Control) экранных элементов, в которых происходило и изменение View и изменение анемичных Model.
Ещё раз, я расстался с Delphi году в 2012. В ту пору его авторы начали дрейф в сторону CLR и Delphi Pascal, как ещё одного CLI-языка. Поэтому рассказываю, как оно было в то время. Структура формы была не заточена под MVC или любой другой осознанный шаблон. Собственно в то время кроме MVC и MVP никто ни о чём не слышал. Подход, который продавали вместе с Delphi был — RAD. Что это за зверь, и как структурировался код в 90% проектов, я рассказал. Кстати, серверной разработки на Delphi не было в принципе, а под клиент-серверными решениями подразумевалось desktop-приложение, в качестве клиента, и какой-нибудь Sybase или MS SQL Server, в качестве сервера.
Я не знаю, что там сейчас использует Delphi, и живо ли оно вообще. Я с ним работал с 1-ой по 7-ую версии. Тогда там никаким MVC ещё не пахло. У тебя была форма, которую ты набирал из компонентов в визуальном редакторе, у тебя были события, связанные с компонентами, и у тебя были обработчики этих событий. Главный рекламируемый паттерн Delphi в те времена был "х** х** и в продакшен", который по вумному тогда назывался RAD (rapid application development). То есть верхом разработки было поместить весь или почти весь код в обработчики этих событий. В одном обработчике можно было найти и работу с экранными элементами, и запросы к базе данных, и вычислительные алгоритмы, и всё остальное прочее (хотя это "прочее" в те времена не блистало разнообразием).
Так вот про MVC почти никто в те времена не задумывался. По крайней мере статей в профильных (бумажных) журналах про шаблоны проектирования и прочую теорию в те времена особо-то и не было. Ко всему прочему Delphi Pascal, хотя и имел в своём составе интерфейсы, так необходимые практически для каждого шаблона проектирования, но их реализация оставляла желать лучшего. В библиотеках и примерах кода они просто не использовались, а многие программисты на Delphi даже в теории не знали про их существование.
К чему это я? А к тому, что любая рефлексия того, что каждый из нас делает каждый день, очень важна и полезна для профессионального роста каждого из нас. Поэтому меня и не радует отношение "все эти ваши паттерны-шматерны, принципы, подходы, никому не нужны!". Подобное отношение приводит в пределе к RAD. Или иными словами спаггети-коду, говнокоду.
Лучше задумываться над тем, что и как ты делаешь, и тогда ты растёшь, чем упрощать всё до эмоциональных аргументов и анекдотов и топтаться на месте.
Вас понял, но у нас, действительно, разное понимание этого термина Э. Вы о продукте, я о размере организации и принципах управления такими организациями, а также количестве денег и возможностях, которые эти ресурсы дают ей. В Э-организациях есть разные продукты и проекты. Последние 10-20 лет, например, стали популярны внутренние стартапы. Э-организации разные бывают. Я работал в тех, которые "наелись" коробками и аутсорсом, проблемами и большими расходами, которые с ними связаны, и, в итоге, пришли к экономической целесообразности внутренней разработки. Однако, поскольку это их непрофильная деятельность, в них есть масса проблем, которые я описал в первом своём ответе. С другой стороны, Касперский, например, изначально создавался на написание коробок, но также представляет собой Э-организацию в силу своего размера и мирового масштаба. Хочешь не хочешь, а приходится внедрять иерархию и привлекать сторонних менеджеров, что даёт те же "болезни", что и, скажем, в МТС или ВТБ. В Яндексе и Озоне пока не работал, сказать точно, что там внутри творится не могу, но могу точно сказать, что HR-ы и процесс отбора там отстойный, поскольку многолетний опыт эпизодического общения с ними я уже имею.
Нет. Тем более, что это обобщённый опыт за последние 10-15 лет и несколько компаний. Да, разумеется вещи вроде сервера БД покупаются, а не разрабатываются самостоятельно, но софт, например, система автоматизации кредитования крупных компаний, разрабатывается самостоятельно, а не покупается коробкой/сервисом, хотя переговоры с подобными поставщиками ведутся в познавательных интересах.
У нас с Вами, видимо, просто разный опыт и понимание терминов. Для меня энетерпрайз это, например, Сбер, X5, Билайн, РБК, любой коммерческий банк, Касперский и т.д. Это не инди, не стартап, не Рога и копыта со своей конфигурацией 1С и т.п.
Какие примеры энетерпрайза в Вашем понимании этого термина Вы можете назвать?
Я бы, скорее, у названных проектов выделил общую черту, что это чисто коммерческие проекты/продукты/сервисы без особого внимания регуляторов, как у банков и мобильных провайдеров. К сожалению, WB и X5 мне точно не подходят, так как знаю их подноготную от бывших своих подчинённых. Сбер тоже к таким компаниям относится весьма двойственно. Ни плюшек материнской компании, ни свободы действий, и "давай-давай-давай". Да и в принципе я не ищу сейчас работу, меня устраивает место, где я работаю.
Не поймете меня неправильно. Даже подчёркивая проблемы энтерпрайза и других компаний, я отдаю себе отчёт, что они как-то выживают и даже приносят прибыль, несмотря на весь "песок" в своих механизмах. За 30 лет я привык к подобным вещам и просто стараюсь трезво оценивать действительность, что и где возможно, а что нет.
Ну, фиг его знает, у меня на проекте вполне себе чистая архитектура, привнесённая в запущенный проект мной. Новая часть кода сделана по ЧиА, а старая постепенно переносится из дремучего легаси в новую парадигму. Да, получилось много классов, но они маленькие, сконцентрированные на своей задаче, разбитые по слоям. Но в чём проблема? Так или иначе этот код должен был где-то быть, его было бы не меньше, но без ЧиА в легаси это большие классы на несколько сотен строк, а в новом коде это много классов до сотни строк каждый. Сборок тоже много, но это уже шаблон для новых модулей и разработчики привыкли подглядывать, в имеющиеся модули, чтобы понимать, какие сборки им сделать в новом модуле, что в них помещать, а что нет. То есть система работает, код писать и поддерживать проще, так как есть предсказуемость и системный подход. Да, мне пришлось поработать сверхурочно 2-3 месяца, но мне было интересно. Да, это модульный монолит, но это было сознательное решение и желательное изменение.
Смысл MVVM тоже прекрасно понятен, хотя в последних нескольких проектах я его не использую, так как разработка у меня серверная, а не desktop/mobile, как было раньше. Очень удобный шаблон, когда у вас есть возможность навесить bindings, как это, например, в WPF. И Ильичи, будь то Владимиры или Леониды, тут ни при чём. Или вы предлагает использовать подходы RAD времён Delphi и WinForms?
Эм, а это куда? :) Если серьёзно, что Вы под "инди" понимаете? Инди-игры я знаю, но их разработка, это скорее стартап на коленке в нерабочее время. Или иначе pet-project.
Я про энерпрайз и в Вашем понимании. Свои внутренние продукты, а от сторонних аутсорс, коробок и т.п. давно уже отказались. И я не про одно место, а про несколько в последние годы. Например, средний банк или сотовый провайдер большой тройки.
Не стартапами едиными... В энетерпрайзе всё тоже весьма плохо, в том числе и с чистой архитектурой.
Засилье эффективных менеджеров, ничего не понимающих в разработке, но имеющих своё мнение, которое они вынуждены демонстрировать, чтобы быть успешными. Правда, такая чайка живёт обычно недолго. Нагадит здесь, летит в другое место повторять успешный опыт. Отрицательный отбор. Рыба гниёт с головы.
Низкое качество требований. Отчасти из-за той же некомпетентности менеджеров, которые не знают, как работает их часть бизнеса, не говоря уже о смежных частях. Отчасти из-за недооценки и загруженности функциональных сотрудников, которые коллективно много знают, но не имеют права голоса и времени, чтобы донести своё видение. Отчасти из-за проблем с аналитиками, которые гордо называют себя системными, но на деле не могут справиться даже со сбором и фиксацией бизнес-требований.
Большое количество формализма в принятии решения, бюрократия. Слишком много откровенно лишних телодвижений, необходимых для доведения в прод чего бы то ни было.
Большое количество систем, сервисов и команд их создающих. Сложно договориться даже о простейшей интеграции между двумя смежными системами. Нет общих подходов и архитектуры всей информационной инфраструктуры компании (мозаичность решений).
Люди башни из слоновой кости, которые не могут даже пояснить за стрелки на их диаграммах, потоки данных это или зависимости.
Feature rush, но это свойственно любому бизнесу и было сказано про стартапы. Но в случае кровавого энетерпрайза это накладывается на все прочие проблемы.
Множество ограничений по доступным технологиям. "Я понимаю, что здесь лучше подойдёт MongoDB, но у нас можно только MS SQL Server или Oracle". Подставьте любые другие технологии.
Часто проблемы с инфраструктурой. Она большая, множество legacy оборудования, которое нужно подружить с более новым. Что-то постоянно падает.
Куча проблем, связанных с безопасностью. Тебе постоянно что-то запрещают. От тебя требуют каких-то странных вещей, например, резко дерзко закрывают доступ в репозиторий пакетов и требуют, чтобы ты дал полный список пакетов, к которым тебе необходим доступ. Любая дырка в файрволе может превратиться в недели согласований, а потом выясняется, что нужно ещё парочку проковырять и пробросить их через другие VLAN.
И как альфа и омега всего этого звездеца — всё те же эффективные менеджеры. Они повсюду и у каждого из них свой глюк.
И толку-то от того, что она выдаст ошибку, когда у вас место закончится? Вы логи постоянно читаете? Успеете среагировать?
Для мониторинга состояния оборудования, ресурсов и софта есть специальные инструменты для мониторинга, а для них дэшборды с красивыми, понятными индикаторами, графиками, алертами.
Чтобы дорасти, нужно удержаться. Чтобы удержаться, нужно правильно выбрать организацию, где не будет слишком скучно, и где не будут "выжимать" и "выдавливать". В каких организациях больше шансов на это, с Вашей точки зрения?
А что, собственно, делать таким талантливым людям? Куда и на какие должности устраиваться, с Вашей точки зрения? Архитектор? В большинстве мест архитектор — это человек из башни слоновой кости, который мало что понимает о продуктах, которые он пытается интегрировать в единое целое (они часто даже не могут объяснить, что обозначают стрелочки на их диаграммах: зависимости или потоки данных). Техлид? Техлид чаще всего — это "сбалансированная должность", как сказала одна девочка-HR, которая, скорее, "разбалансированная" в силу обилия задач, которые сваливают на такого специалиста. Наставник? Таких должностей нет. Системный аналитик? Это точно не про "меньше общаться с людьми и расти в архитектора". Сеньор-разработчик? Ну, Вы только что забанили такой вариант своей статьёй. Так на кого подаваться "золотой шестерёнке" и куда?
cert-manager не умеет работать в связке с ExternalDNS. Его нет в списке интеграций, но есть до сих пор открытое issue на тему интеграции.
Из этого issue я узнал, что ExternalDNS не умеет работать с TXT записями (только A и CNAME): issue.
Концепция ExternalDNS, если я понял её правильно, состоит в следующем: у вас есть сайты, которые нужно выставить наружу, вам лень (или сайтов очень много) прописывать для них DNS-записи руками, вы ставите ExternalDNS, который сканирует ваши ingress-ресурсы, берёт из них адреса сайтов и создаёт для них DNS-записи. Эта проблема (автоматическое создание DNS-записей) находится вне рамок данной статьи. Более того, задача как раз не публиковать в публичную Сеть внутренние сайты (тогда можно было бы вообще HTTP-01 обойтись). Даже если считать, что DNS-записи будут создаваться во внутреннем DNS, всё равно это не является темой данной статьи.
В целом, да, ExternalDNS — не бесполезный проект, можно найти ему применение, но к теме статьи имеет лишь косвенное отношение.
Придерживаюсь ровно таких же принципов. Главное в кандидате не знание технологий, главное - умеет ли он думать. И именно это я проверяю на собеседовании. Да, используя технические вопросы, но мы с ним копаем глубже и шире, без оглядки на "правильные" ответы. Их просто нет, правильных. Только так и можно проверить, может ли человек анализировать и синтезировать. Но есть проблема, на поток такое не поставить никогда. Очень многое зависит от собеседующего руководителя (боже упаси, не розововолосой зумерши-эльфийки!), от его заинтересованности в успешном результате проекта/продукта, умении понять/почувствовать нужного человека (эмпатия?).
Что касается дурака-руководителя. Как правило, с ним встречаешься уже в конце, часто после оффера. Так что приходится терпеть какое-то время, получать опыт, и уходить.
Вы, по сути, изобрели велосипед со своими корпоративными приблудами. Большинство компаний давно уже используют эту довольно простую схему: "скрининг", техсобес, собес с тимлидом/командой, оффер, но до вас почему-то это только дошло, как до той утки на седьмые сутки.
У меня тоже, как у многих здесь в комментариях есть личный опыт собесов в Яндексе. И как у подавляющего большинства исключительно негативный. Уж не знаю, в какой момент вы дошли до того, что программисту для написания кода нужно давать привычный текстовый редактор хотя бы (интересно, когда вы дойдёте до идеи дать ему привычную среду разработки?), а не бумажку и ручку. Вот именно это меня больше всего взбесило: необходимость писать код на бумажке после 20 с лишним лет опыта использования различных текстовых редакторов / сред. Тогда я получил отказ, фидбека мне не дали, я его несколько недель выбивал из девочки-хээрщицы. И что по итогу? Фидбек: "Коллеги отметили, что вы хорошо знаете алгоритмы и структуры данных (я готовился 2 недели, так-то они мне нужны раз в год в лучшем случае) и быстро умеете адаптировать решение под изменившиеся требования (типа, а если у вас мало памяти, но много процессора), однако вы допускаете много ошибок и делаете много исправлений". Нуёпта! Конечно, я делаю много ошибок и исправлений, когда пишу на бумаге код на абстрактном языке программирования, я привык к возможностям редактора текста, где я могу быстро обложить какой-то кусок кода блоком if или типа того, у меня это уже в пальцах.
У меня вообще сложилось впечатление, что Яндексу нужны исключительно вчерашние студенты, без семьи, без других интересов, готовые батрачить по 12 часов в день за "мы же семья" и хрен в кармане.
Честно говоря, на текущий момент я не представляю, чем меня нужно заманивать на собес в Яндекс сейчас, чтобы я на него сходил.
Критикуя предлагай? Хорошо. Самая рабочая схема найма, которая мне попадалась за более 30 лет профессионального опыта в разных странах и компаниях примерно такая. Кадровичка, пользуясь работными сайтами, готовит список потенциальных кандидатов, отбирая их по типовым критериям: опыт, технологии, зарплатные ожидания соответствуют имеющейся зарплатной вилке. Кадровичка передаёт эти списки тимлидам команд, которым нужны сотрудники соответствующей квалификации. Тимлиды читают резюме и выбирают потенциально интересных кандидатов и передают эти списки кадровичке. Кадровичка связывается с кандидатами и назначает собесы. Тимлиды проводят собесы сами (в редких случаях делегируют своим сеньорам)! Тимлиды! Сами! Ведь именно они знают, кто им нужен, именно они знают, о чём спросить на конкретную должность.
Не надо всех кандидатов пропускать через шаблонные собесы, результатами которых потом, типа, будет удобно пользоваться тимлидам! Тимлиды не доверяют этим результатам, поэтому опять проводят собес по-своему. Дайте тимлиду самому искать подходящих кандидатов в команду. Вы хотя бы попробуйте так сделать. Да розововолосые хээрщицы будут против, они почувствуют страх сокращения, поскольку в этой схеме они лишние, но тимлиды и кандидаты скажут только "спасибо".
А почему Вы решили, что это шуточная статья? Я лично не нашёл никаких предупреждений об этом. 1 апреля тоже далеко.
Предложенное в статье больше похоже на фантазии дилетанта в области найма. Этакая зелёная девочка хэар переносит свой опыт выбора жениха на собеседование с разработчиками.
Вот ищу я работу. У меня, скажем, 10 вариантов. Если каждый из них будет давать мне тестовое задание, да ещё и приближенное к реальным задачам... Ясно видно, что наша девочка никогда не программировала и не понимает, сколько это занимает времени. Я про реальные задачи, а не пузырьковая сортировка. Я лично от тестовых заданий всегда отказываюсь. Если настаивают, отправляю в свой гитхаб, там моего кода много, есть даже специально выполненные тестовые задания. Смотрите, оценивайте. На бесплатное заказное программирование я время, а значит и деньги, тратить не собираюсь.
Что значит "заинтересован в позиции"? Да откуда я знаю, как оно там у вас на самом деле в компании? Как там у вас там с условиями, ЗП, задачами? Почитать на сайте? Так там такие же зелёные девочки из маркетинга пишут сами не зная чего, пересыпая этот бред всяким булшитом, вроде "лидер отрасли", "ведущая компания" и т.п. Я лично всегда с известной долей настороженности отношусь к любой позиции и компании. Как там оно на самом деле у вас для меня только вскрытие покажет.
Вовлечённость? Куда? Мы ещё не познакомились, я у вас не поработал. Откуда вовлечённости взяться? Вы кто такие, чтобы я вам что-то о себе доказывал?
Девочка, видимо, ещё не знает сколько стоит час разработчика, и сколько встреч у менеджера. Тем более это заметно, когда кандидатов поток. По-хорошему должен собеседовать только тимлид.
10-15 минут на разогрев? Это не разогрев называется, а маринование, уважаемый кулинар. Не надо женские приёмы со свиданий распространять на деловые переговоры. Это плохой тон. Вы собираетесь сожрать мои 10-15 минут без видимой причины, это неуважение.
Про заинтересованность писал выше. Ей неоткуда ещё появиться.
У меня 10 вакансий на руках, я заинтересован в них почти одинаково, так как реальной информации не хватает. Только работа в компании и конкретной команде может показать, что вы собой представляете. Могу ещё один вопрос посоветовать: "с каким животным вы себя ассоциируете?" Он ещё более гениальный, особенно в самом начале собеседования.
А на каком основании вы собрались мне задавать личные вопросы? Опять неуважение к кандидату.
Это вообще шедевр. Однозначно правильные ответы можно получить только на простые вопросы. Проблема с простыми шаблонными вопросами в том, что ответы на них зазубривают. Даже не зная почти ничего по теме, человек легко пройдёт этот этап. Были у меня такие на собеседованиях. Со сложными вопросами, нельзя дать однозначный правильный вопрос, нужно задавать дополнительные вопросы. В конце концов, важно не то, как человек проходит "профессиональный ЕГЭ-угадайку", а его аналитические возможности, умение находить информацию, умение воплотить идею в код, а не вот эти ваши тесты.
Переработки, давление, дедлайны? Вот точно в такую компанию не пойду, хоть и работаю по собственной инициативе (просто самому интересно) по 10-12 часов в день. Зачем мне соковыжиматель? Мне работа нужна, где мне будет интересно, обеспечено и комфортно. Привыкли к людям как к тряпкам относиться? Тогда мне точно с вами не по пути. Прозябайте дальше и умрите, как компания!
А ещё лучше вообще не давайте ответа, пусть приползёт к вашему офису и просидит под дождём неделю без пищи и только на воде из атмосферных осадков. Зарплату от должен будет платить вам, а не вы ему. С женой пусть разведётся, квартиру подарит вам, научиться раболепно улыбаться и заискивать, пусть благодарит до пенсии за возможность "поработать" в подобной компании. Ах, да, и пусть в 6 утра каждый день, включая выходные и отпуск, поёт гимн компании, высоко, гордо задрав голову к динамику в потолке офисной комнаты вместе со всей командой.
Короче, автор, ты бредишь. Лично я, столкнувшись с тобой на собеседовании, послал бы тебя по известному адресу. Уйди из найма! И коллег своих подобных забери с собой! Вы слишком глупы для IT.
Каждому своё. Лишь бы Вам нравилось, и деньги достаточные платили.
У нас просто разный профессиональный опыт. И я Вас прекрасно могу понять. Пока дальше первого языка и среды разработки не глянешь, всё кажется просто и логично. Стоит расширять кругозор и спокойно относиться к чужому опыту и мнению.
Перепутал я год. Правильно, в 2005 я с Delphi закончил и перешёл на C#. Старый уже, память плохая. :) Как раз .NET Framework 3 вышел.
А RAD хорош только для маленьких короткоживущих проектов. Для остальных проектов — это ад. Никому не пожелаю в таких участвовать.
Конечно, никто ничего не запрещает, и всегда можно натянуть сову на глобус при большом желании. Вот только в MVC модель обновляет View, а в Delphi (как я его запомнил) ничего подобного не было. Были обработчики событий (Control) экранных элементов, в которых происходило и изменение View и изменение анемичных Model.
Ещё раз, я расстался с Delphi году в 2012. В ту пору его авторы начали дрейф в сторону CLR и Delphi Pascal, как ещё одного CLI-языка. Поэтому рассказываю, как оно было в то время. Структура формы была не заточена под MVC или любой другой осознанный шаблон. Собственно в то время кроме MVC и MVP никто ни о чём не слышал. Подход, который продавали вместе с Delphi был — RAD. Что это за зверь, и как структурировался код в 90% проектов, я рассказал. Кстати, серверной разработки на Delphi не было в принципе, а под клиент-серверными решениями подразумевалось desktop-приложение, в качестве клиента, и какой-нибудь Sybase или MS SQL Server, в качестве сервера.
Я не знаю, что там сейчас использует Delphi, и живо ли оно вообще. Я с ним работал с 1-ой по 7-ую версии. Тогда там никаким MVC ещё не пахло. У тебя была форма, которую ты набирал из компонентов в визуальном редакторе, у тебя были события, связанные с компонентами, и у тебя были обработчики этих событий. Главный рекламируемый паттерн Delphi в те времена был "х** х** и в продакшен", который по вумному тогда назывался RAD (rapid application development). То есть верхом разработки было поместить весь или почти весь код в обработчики этих событий. В одном обработчике можно было найти и работу с экранными элементами, и запросы к базе данных, и вычислительные алгоритмы, и всё остальное прочее (хотя это "прочее" в те времена не блистало разнообразием).
Так вот про MVC почти никто в те времена не задумывался. По крайней мере статей в профильных (бумажных) журналах про шаблоны проектирования и прочую теорию в те времена особо-то и не было. Ко всему прочему Delphi Pascal, хотя и имел в своём составе интерфейсы, так необходимые практически для каждого шаблона проектирования, но их реализация оставляла желать лучшего. В библиотеках и примерах кода они просто не использовались, а многие программисты на Delphi даже в теории не знали про их существование.
К чему это я? А к тому, что любая рефлексия того, что каждый из нас делает каждый день, очень важна и полезна для профессионального роста каждого из нас. Поэтому меня и не радует отношение "все эти ваши паттерны-шматерны, принципы, подходы, никому не нужны!". Подобное отношение приводит в пределе к RAD. Или иными словами спаггети-коду, говнокоду.
Лучше задумываться над тем, что и как ты делаешь, и тогда ты растёшь, чем упрощать всё до эмоциональных аргументов и анекдотов и топтаться на месте.
Вас понял, но у нас, действительно, разное понимание этого термина Э. Вы о продукте, я о размере организации и принципах управления такими организациями, а также количестве денег и возможностях, которые эти ресурсы дают ей. В Э-организациях есть разные продукты и проекты. Последние 10-20 лет, например, стали популярны внутренние стартапы. Э-организации разные бывают. Я работал в тех, которые "наелись" коробками и аутсорсом, проблемами и большими расходами, которые с ними связаны, и, в итоге, пришли к экономической целесообразности внутренней разработки. Однако, поскольку это их непрофильная деятельность, в них есть масса проблем, которые я описал в первом своём ответе. С другой стороны, Касперский, например, изначально создавался на написание коробок, но также представляет собой Э-организацию в силу своего размера и мирового масштаба. Хочешь не хочешь, а приходится внедрять иерархию и привлекать сторонних менеджеров, что даёт те же "болезни", что и, скажем, в МТС или ВТБ. В Яндексе и Озоне пока не работал, сказать точно, что там внутри творится не могу, но могу точно сказать, что HR-ы и процесс отбора там отстойный, поскольку многолетний опыт эпизодического общения с ними я уже имею.
Нет. Тем более, что это обобщённый опыт за последние 10-15 лет и несколько компаний. Да, разумеется вещи вроде сервера БД покупаются, а не разрабатываются самостоятельно, но софт, например, система автоматизации кредитования крупных компаний, разрабатывается самостоятельно, а не покупается коробкой/сервисом, хотя переговоры с подобными поставщиками ведутся в познавательных интересах.
У нас с Вами, видимо, просто разный опыт и понимание терминов. Для меня энетерпрайз это, например, Сбер, X5, Билайн, РБК, любой коммерческий банк, Касперский и т.д. Это не инди, не стартап, не Рога и копыта со своей конфигурацией 1С и т.п.
Какие примеры энетерпрайза в Вашем понимании этого термина Вы можете назвать?
Я бы, скорее, у названных проектов выделил общую черту, что это чисто коммерческие проекты/продукты/сервисы без особого внимания регуляторов, как у банков и мобильных провайдеров. К сожалению, WB и X5 мне точно не подходят, так как знаю их подноготную от бывших своих подчинённых. Сбер тоже к таким компаниям относится весьма двойственно. Ни плюшек материнской компании, ни свободы действий, и "давай-давай-давай". Да и в принципе я не ищу сейчас работу, меня устраивает место, где я работаю.
Не поймете меня неправильно. Даже подчёркивая проблемы энтерпрайза и других компаний, я отдаю себе отчёт, что они как-то выживают и даже приносят прибыль, несмотря на весь "песок" в своих механизмах. За 30 лет я привык к подобным вещам и просто стараюсь трезво оценивать действительность, что и где возможно, а что нет.
Ну, фиг его знает, у меня на проекте вполне себе чистая архитектура, привнесённая в запущенный проект мной. Новая часть кода сделана по ЧиА, а старая постепенно переносится из дремучего легаси в новую парадигму. Да, получилось много классов, но они маленькие, сконцентрированные на своей задаче, разбитые по слоям. Но в чём проблема? Так или иначе этот код должен был где-то быть, его было бы не меньше, но без ЧиА в легаси это большие классы на несколько сотен строк, а в новом коде это много классов до сотни строк каждый. Сборок тоже много, но это уже шаблон для новых модулей и разработчики привыкли подглядывать, в имеющиеся модули, чтобы понимать, какие сборки им сделать в новом модуле, что в них помещать, а что нет. То есть система работает, код писать и поддерживать проще, так как есть предсказуемость и системный подход. Да, мне пришлось поработать сверхурочно 2-3 месяца, но мне было интересно. Да, это модульный монолит, но это было сознательное решение и желательное изменение.
Смысл MVVM тоже прекрасно понятен, хотя в последних нескольких проектах я его не использую, так как разработка у меня серверная, а не desktop/mobile, как было раньше. Очень удобный шаблон, когда у вас есть возможность навесить bindings, как это, например, в WPF. И Ильичи, будь то Владимиры или Леониды, тут ни при чём. Или вы предлагает использовать подходы RAD времён Delphi и WinForms?
Эм, а это куда? :) Если серьёзно, что Вы под "инди" понимаете? Инди-игры я знаю, но их разработка, это скорее стартап на коленке в нерабочее время. Или иначе pet-project.
Я про энерпрайз и в Вашем понимании. Свои внутренние продукты, а от сторонних аутсорс, коробок и т.п. давно уже отказались. И я не про одно место, а про несколько в последние годы. Например, средний банк или сотовый провайдер большой тройки.
Не стартапами едиными... В энетерпрайзе всё тоже весьма плохо, в том числе и с чистой архитектурой.
Засилье эффективных менеджеров, ничего не понимающих в разработке, но имеющих своё мнение, которое они вынуждены демонстрировать, чтобы быть успешными. Правда, такая чайка живёт обычно недолго. Нагадит здесь, летит в другое место повторять успешный опыт. Отрицательный отбор. Рыба гниёт с головы.
Низкое качество требований. Отчасти из-за той же некомпетентности менеджеров, которые не знают, как работает их часть бизнеса, не говоря уже о смежных частях. Отчасти из-за недооценки и загруженности функциональных сотрудников, которые коллективно много знают, но не имеют права голоса и времени, чтобы донести своё видение. Отчасти из-за проблем с аналитиками, которые гордо называют себя системными, но на деле не могут справиться даже со сбором и фиксацией бизнес-требований.
Большое количество формализма в принятии решения, бюрократия. Слишком много откровенно лишних телодвижений, необходимых для доведения в прод чего бы то ни было.
Большое количество систем, сервисов и команд их создающих. Сложно договориться даже о простейшей интеграции между двумя смежными системами. Нет общих подходов и архитектуры всей информационной инфраструктуры компании (мозаичность решений).
Люди башни из слоновой кости, которые не могут даже пояснить за стрелки на их диаграммах, потоки данных это или зависимости.
Feature rush, но это свойственно любому бизнесу и было сказано про стартапы. Но в случае кровавого энетерпрайза это накладывается на все прочие проблемы.
Множество ограничений по доступным технологиям. "Я понимаю, что здесь лучше подойдёт MongoDB, но у нас можно только MS SQL Server или Oracle". Подставьте любые другие технологии.
Часто проблемы с инфраструктурой. Она большая, множество legacy оборудования, которое нужно подружить с более новым. Что-то постоянно падает.
Куча проблем, связанных с безопасностью. Тебе постоянно что-то запрещают. От тебя требуют каких-то странных вещей, например, резко дерзко закрывают доступ в репозиторий пакетов и требуют, чтобы ты дал полный список пакетов, к которым тебе необходим доступ. Любая дырка в файрволе может превратиться в недели согласований, а потом выясняется, что нужно ещё парочку проковырять и пробросить их через другие VLAN.
И как альфа и омега всего этого звездеца — всё те же эффективные менеджеры. Они повсюду и у каждого из них свой глюк.
И толку-то от того, что она выдаст ошибку, когда у вас место закончится? Вы логи постоянно читаете? Успеете среагировать?
Для мониторинга состояния оборудования, ресурсов и софта есть специальные инструменты для мониторинга, а для них дэшборды с красивыми, понятными индикаторами, графиками, алертами.
Чтобы дорасти, нужно удержаться. Чтобы удержаться, нужно правильно выбрать организацию, где не будет слишком скучно, и где не будут "выжимать" и "выдавливать". В каких организациях больше шансов на это, с Вашей точки зрения?
А что, собственно, делать таким талантливым людям? Куда и на какие должности устраиваться, с Вашей точки зрения?
Архитектор? В большинстве мест архитектор — это человек из башни слоновой кости, который мало что понимает о продуктах, которые он пытается интегрировать в единое целое (они часто даже не могут объяснить, что обозначают стрелочки на их диаграммах: зависимости или потоки данных). Техлид? Техлид чаще всего — это "сбалансированная должность", как сказала одна девочка-HR, которая, скорее, "разбалансированная" в силу обилия задач, которые сваливают на такого специалиста. Наставник? Таких должностей нет. Системный аналитик? Это точно не про "меньше общаться с людьми и расти в архитектора". Сеньор-разработчик? Ну, Вы только что забанили такой вариант своей статьёй.
Так на кого подаваться "золотой шестерёнке" и куда?
Скорее всего, Вы неправы.
cert-manager не умеет работать в связке с ExternalDNS. Его нет в списке интеграций, но есть до сих пор открытое issue на тему интеграции.
Из этого issue я узнал, что ExternalDNS не умеет работать с TXT записями (только A и CNAME): issue.
Концепция ExternalDNS, если я понял её правильно, состоит в следующем: у вас есть сайты, которые нужно выставить наружу, вам лень (или сайтов очень много) прописывать для них DNS-записи руками, вы ставите ExternalDNS, который сканирует ваши ingress-ресурсы, берёт из них адреса сайтов и создаёт для них DNS-записи. Эта проблема (автоматическое создание DNS-записей) находится вне рамок данной статьи. Более того, задача как раз не публиковать в публичную Сеть внутренние сайты (тогда можно было бы вообще HTTP-01 обойтись). Даже если считать, что DNS-записи будут создаваться во внутреннем DNS, всё равно это не является темой данной статьи.
В целом, да, ExternalDNS — не бесполезный проект, можно найти ему применение, но к теме статьи имеет лишь косвенное отношение.