Comments 447
В целом основная проблема вытекла из утверждения во втором предложении поста: "...тимлид на .NET". И этот рассинхрон в определениях явно вами и отмечается по всему посту, как будто ждете, что мы тут в комментариях подтвердим, что вы правы.
Однако тимлид это роль, в основной фокус которой входит управление командой: организация рутины, коммуникации с соседями, выбивание ресурсов и прочее. Конечно тимлид должен быть технарем, но ровно настолько, чтобы разбирать, втирают ли ему сейчас какую-то дичь или нет. Для этого не нужно быть экспертом в языке (я питонист и однажды лидил фул-стек команду, где бэк был на ноде), но понимать общие концепции и уметь спуститься в детали.
Но за такой подробный обзор не грех поставить лайк, интересно почитать у кого как устроено, не проходя эти круги ада :)
Ну вот, как выяснилось, в разных местах по-разному. Где-то тимлид это бывший старший разработчик в команде, на которого переложили часть управляющих функций. А где-то целиком менеджер. Мне ближе первое и по опыту, и идейно.
Разделение зависит от размера команды и компании в целом. В крупных бюрократических структурах у тимлида физически не будет времени даже код ревью делать, будешь "программировать" в календаре аутлука и постоянных созвонах.
в крупных бюрократических структурах еще есть и Прожект Менеджеры и Продукт Менеджеры и даже Деливери Менеджеры, на которых большинство менеджерских задач и перекладывается, а тим остается тех-спецом
Из окопа java бэк на ноде кажется не таким уж и далеким от питона:)
А где есть стандарты на тимлида? Я думал что тимлид должен по своей части хотябы архитектуру на уровне интерфейсов и классов нарисовать и проверять исполнение иначе от него мало пользы (коммуникации с другими командами это навык а не его киллер фича)
Тимлид в большом числе компаний - это вообще чистый менеджер с техническим бэкграундом. Мне интересно, в каких из этих вакансий вам вообще предлагали параллельно программировать, а не только управлять командой?
Везде, кроме Т-Банка и Uzum, речь о программировании была явно.
Ну если он совмещает в себе аналитика и ПМ, то да, не до программирования А так извините, чего там тимлидить на фуллтайм со средней командой из 5 человек? Код ревью постоянный? В курсе кода команды хорошо бы быть, и лучше это делается во момент собственного программирования тоже. Ну понятно что это будет условно с коэффициентом 0.5, но не 0 уж всяко
либо у них где-то используется. Второе гораздо хуже, но и первое не слишком осмысленно, на мой взгляд.
У этого кода есть неустранимая проблема - он написан не мной :)
Скорее всего у них действительно очень много "устаревшего" кода...
Но кроме вероятности нанять шарлатана, есть и обратный эффект: не нанять нормального спеца.
Как раз это - не проблема компании, потому что на падающем или стагнирующем рынке у компаний часто для него всё равно нет ни работы, ни бюджета.
Ой, вы просто не видели реалии российского импортозамещения. Вот где кормятся толпы идиотов, которых я бы не взял даже пол в офисе подметать, а там они за лидов. Довелось мне поучаствовать в одном таком проекте "импортозамещения САП ERP", до сих пор вздрагиваю. Приведу даже описание того, что они там у себя пишут, .NET-чики оценят (проект, разумеется, состоит из бэка на AspNet.Core и фронта, причем фронт отдельный ужас, но не будем об этом):
- Ни в сервисах, ни в репозиториях, нигде вообще не используются асинхронные вызовы. Совсем. Весь "высоконагруженный проект" полностью построен на синхронном коде. Нет, многопоточность там тоже не ночевала, но это следующий пункт.
- "Лиды" проекта имеют представление о DI. О да, еще как. Поэтому, DI-контейнеров там три(!). Разных. Разумеется, настройка каждого из них в отдельном проекте. Часть зависимостей помечается Lazy (видимо, думают, что это как-то решит проблему производительности). По какому принципу? А хз, видимо, зависит от того, кто конкретно писал этот конкретный сервис. Часть резолвится методом передачи ServiceResolver'а в конструктор. Часть - по старинке, просто через конструктор.
- Когда в их надежный как швейцарские часы конструкт проникает чей-то зловредный асинхронный код, они используют нечто под названием "AsyncHelper". Суть этого AsyncHelpera, как можно догадаться, состоит в вызове метода Sinc() который в свою очередь вызывает GetAwaiter().GetResult(), но не только, No sir! Для начала они вручную(!) вызывают самописный тредпул (чем им нативный не угодил?) и пропихивают таск туда(!) чтобы уже затем вызвать GetAwaiter().GetResult(). Чтобы что? Не знаю. Любой, кто мало-мальски имеет представление о том, как работает async в .NET понимает всю фантастическую абсурдность этих телодвижений.
- В какой-то момент в этом замечательном спагетти-монолите кто-то решил изобразить микросервисы. Для чего, для начала, от основной базы было отпилено несколько таблиц и перемещено в отдельную. С констрейнтами и сильной связью с таблицами в основной базе. С дублированием данных и ключей. С поиском совпадений по полю name ведь других способов не осталось - связность-то нарушена.
И эти люди на полном серьезе получали по 500-600к за свою работу.
Так что работа не работа, а вот за что платить находят.
Вообще с чистым SQL в современном энтерпрайзе работают мало и редко
Пруфов, разумеется, не будет
в ходе собеседований автор столкнулся с другой реальностью )
Пруфы на что нужны? ORM появились лет 20 назад. Сейчас чистый SQL используется только в каких-то эксклюзивных случаях.
Мой опыт говорит об обратном.
Буквально чистый sql со строками и интерполяцией - да, редко, поскольку прямой путь к уязвимостям. Однако ORM как раз в современном enterprise тоже зачастую избегают, поскольку ему нельзя доверять формирование запросов и планов запросов при высокой нагрузке. Т.е. либо пользуют что-то типа JOOQ, либо в том же Hibernate прибегают к HQL и по факту работают тоже с запросами напрямую.
Мы EF Core используем чисто для вставки/обновления данных. Иногда через получение записи по Id, иногда просто через создание модели с известным ключом и потом менять свойства, а она через ChangeTracking это всё сам сохранит. Часто удобно можно без открытия транзакций несколько записей вставить/поменять
Но ведь в ORM можно и графы сущностей использовать, чтобы лишних джойнов не тащить.
Ох вэйт.
Во-первых, ОРМ в виде того же Entity Framework это в первую очередь реализация UnitOfWork. Т.е. работа с транзакционными границами используя язык программирования, а не язык SQL.
Вторая суперсила EF - change tracking. Т.е. при применении изменений рассчитывается diff и далее накатывается только он (если вообще появился какой-то diff). Фича классная, но опциональная.
Третья суперсила - сборка аггрегата за счёт маппинга. Т.е. у вас аггрегат это Todo list, при этом Todo items нормализованы в отдельную таблицу, то чтобы собрать агрегат нужно будет сделать простые джойны. И EF сделает аггрегацию автоматически когда вы получаете аггрегат для выполнения операции над ним. Ну или лениво подгрузит, есть вам не так критичен перфоманс.
А никто никогда и не говорил выполнять сложные аггрегации из БД через EF. Эти фреймворк для менеджмента данных (command side), а не для формирования из представлений (query side), хотя какие-то кастрированные возможности у него конечно есть и можно использовать в примитивных случаях.
По классике: когда в руках молоток, все вокруг кажется гвоздями.
Меня вообще удивляет, почему этот вопрос вызывает такую дискуссию. Entity Framework во всех вакансиях, давно уже стандарт де-факто в сообществе. Не в пет-проектах же он используется такими масштабами, понятное дело, что именно в энтерпрайзе. Почему у кого-то сомнения, не понимаю :)
Это просто показывает, что несмотря на современные решения (паттерны) очень много народу пилит то, что станет легаси уже завтра. Да что там говорить - они изначально проектируют легаси. И в итоге я вижу адские проекты на чистом SQL с бизнес-логикой на хранимках. То что по идее можно сделать одной левой не включая мозжечок там делается через преодоление. Программисты с загнанным взглядом работают "на галерах" потому что эффективность их работы 10% от нормы (поди отладь такое). А когда выдается свободная минутка они заходят на хабр и пишут в комментариях всякую дичь - потому что это для них норма и как по другому они не знают. Так я это понимаю.
В нашем проектике в табличке с партицированием и шардированием выполняемая хибером загрузка объекта перед его обновлением - боль, от которой мы пытаемся избавиться (ресурсов недостаточно, увы). Грузить простые POJO из мелких таблиц - идеально, а чуть в сторону - лучше руками.
ему нельзя доверять формирование запросов и планов запросов при высокой нагрузке.
При этом вы пишите, что используется HQL... А какие запросы в таком случае ORM выполняет ? Или имеется в виду, что выбираются объекты через find по одному или со связями прописанными как Eager ? Так этого давно никто не делает, даже джуны уже знают и про Eager и про N+1. Но HQL - это всё равно ORM! В большинстве случаев результатом запроса на HQL будет объект-сущность целиком или почти целиком (без связей, но с простыми полями) Кроме того раз уж речь за джаву, то там есть JPA, который тот же HQL по сути, но через код. И мало чем отличается в этом плане от JOOQ Запрос JPA строит практически один в один как он описан в коде. И это тоже ORM
MongoDB ради геопространственных индексов
Они есть во многих БД, почему монга то?
PS прикольная подробная статья
Хотел спросить какая у вас была должность (гл. эксперт или выше), пока не увидел ФИО внизу :)
А что, видели меня где-то? )
А почему не попробовали остаться в отрасли? Вопрос без сарказма. В Концерн был набор, в Гринатом активно ищут. Тут даже была статья как Росатому нужны IT специалисты.
В Гринатоме только питонисты и JS-ники. А так вообще я пробовал остаться в отрасли, но многим компаниям заблокировали найм. Цифрум меня хотел забрать, им не дали, а потом и там пошли сокращения айтишников. Топсистемы проигнорили. В общем, наше начальство даже за несколько месяцев не смогло найти, куда нас пристроить.
В чятике одной большой команды :)
Печально что тинёк тоже из когда-то "Ылиты" скатился на уровень яндекса с вакансиями "25 этапов собеса для перекладывания джейсонов"
После таких длинных интервью, насколько вилка зарплат сходится со средней статистикой: https://career.habr.com/ ?
Озон в getmatch пишет зарплаты к вакансиям, в целом цифры сходятся. На хабре чуть ниже, но это можно списать на то что новые наймы на более высокие ЗП идут.
Ну и там довольно большие суммы фигурируют: https://clck.ru/3N2jgT. От 450 или даже 585 до налогов. Если, конечно, верить getmatch. @Enfriz, у вас "примерно по нижней планке сеньора выходило", т. е. это как раз примерно эти цифры?
Про getmatch не совсем верно. Они пишут примерную зарплату по рынку, сам OZON зарплаты скрывает.
Не даёт посмотреть, пока не добавишь свои данные. Ну навскидку я бы сказал сеньор 350-450, мидл 250-350 (на руки)
Во-первых, огромное спасибо за то, что поделились своим опытом, наконец-то так подробно про .net)
С другой стороны, печально осознавать, что спикер DotNext и профессионал, способный за пару недель подготовиться к алго- и sd-секциям на уровне выше среднего (видимо на основной работе не только json или достаточно времени на pet-проекты), по итогу получил оффер от всего лишь 3 (если не ошибаюсь) компаний из топ-10-15. По сути в России больше .NET-а нет, в том смысле, что переход в другую компанию - это смена шила на мыло)
Да, как я понимаю в России почти везде в энтерпрайзе Java, и некоторые переходят на Go.
Додо, кстати не рассматривали? Из того, что вы перепробовали, еще они в потенциальном списке, но куда-то в последнее время пропали из инфополя.
Культура в додо весьма специфичная. Ну и extreme programming - подход на любителя.
Он был во второй волне моего списка, до которой я не дошёл, т.к. первая волна заняла сильно больше времени, чем я рассчитывал. Ну и получил хороший оффер, не стал продолжать. Ещё там во второй волне были: Контур, ВТБ, ПСБ, МТС.
Пару раз собеседовался в додо. В 2020 не прошел System Design (ума не приложу зачем его спрашивать с мидла) в 2025 не прошел HR :)
Премии вместо оклада, SQL вместо ORM - звучит ужасно.
Только менеджерить - звучит не круто. Не знать стек, с которым работает команда - не круто
Известные зарплаты это круто, это правильно, это хорошо для рынка.
>человек в лицо мило с тобой общается, а потом в кулуарах будет тебя поливать грязью
Это не по айтишному. По айтишному проще свалить, чем таким постоянно заниматься
Первый раз, когда я огорчился, не увидев в конце статьи ссылку на канал в Телеграмме.
Если не сложно, расскажите про росатом. Почему там разбазаривают (т е выкидывают на "базар" труда) людей? Неужто и этот бизнес сокращается? Или в ходе "оптимизации" случайно не туда заоптимизировались? Ну допустим не было задач для вашего департамента, можно же распределить людей как то. Тем более тим-лидов. Такими кадрами компании пока что не разбрасывались до сего дня... Либо же предложения были, но поражали своей скупостью? 😁
Росатом слишком большой. Цепочки управления очень длинные. Из-за этого в этих цепочках будут некомпетентные звенья и поломки. Не удивлюсь, если Лихачёв вообще не в курсе, что его подчинённые выгнали 250 крутых айтишников. И ещё из-за длины цепочек многие оценки зависят не от реальной работы, а от отчётов. По отчётам никаких сокращений, одни оптимизации и улучшения.
"Либо же предложения были" — как я писал в посте про увольнение (ссылка в самом начале статьи), была компания из контура Росатома, которая очень хотела меня нанять, не снижая зарплаты, но им полностью заблокировали найм. Не только меня, а вообще. И не только им. У Росатома с деньгами непросто не из-за того, что бизнес не доходный (очень доходный), а из-за того, что доход обычно приходит через десятилетия после трат. А для трат и кредитов сейчас условия тяжёлые.
Причин много. Одна из основных - высокая ключевая ставка.
А разбрасываются в том числе (но не только) потому что полностью отказались от .NET а на Java переходить сотрудники не захотели.
полностью отказались от .NET
Чем мотивировали?
Де-факто просто выиграла управленческая ветка, у которой был старый проект с корнями на джаве. А номинально объясняют якобы более импортозамещённым состоянием у джавы. Хотя другие организации отрасли имеют большие проекты на .NET и переходить не планируют.
Ну справедливости ради, если нас действительно захотят по настоящему отрезать, то заместить джаву будет несколько проще чем Net. Впрочем это точно не означает, что нужно немедленно всех сокращать. Думаю, вы правы что решение бюрократическое в худшем смысле этого слова.
Ну справедливости ради, если нас действительно захотят по настоящему отрезать, то заместить джаву будет несколько проще чем Net.
С трудом себе представляю что кроме нугета можно отрезать в современном .net.
Примерно всё! - документацию, готовые сборки, какое либо вщзаимодействие с разработчиками. Вы рассуждаете в плоскости "отрежут физически", а это не так делается! Это делается административно - просто примут акт с очередными "санкциями". А исполнять его компании и физ лица будут сами, что бы не попасть под домоклов меч правосудия. Вот и всё. И уж поверьте, одним словом из трех букв, "разрешающим" доступ к отрезанным сайтам тогда не обойдешься. Просто на данный момент им выгоднее, что бы мы оставались в орбите их технологий, поэтому рубят "вершки", а не "корешки". Они разумно полагают, что этот период "консолидированного царства" может закончиться в любой момент.
Это все точно так же применяется и к java. И как раз таки решается впном, который вы, по не понятной причине, так боитесь назвать своим именем. Мало того - не знаю что там в java, а в .net у нас есть форкнутый рантайм, поддерживаемый криптопро, если уж совсем припечет.
Про санкции это вообще смешно - из коммерческого софта/библиотек плюс-минус все самое ценное и так уже не купить российским компаниям после 2022. А чтобы физ. лица что-то там исполняли боясь чего-то - вы видели чтобы физ. лица что-то массово блокировали для кубы, ирана, северной кореи? Вот я - нет. И опять же - решается впном и абсолютно точно так же затрагивает java.
И вот, кстати, тут вспомнилось что у знакомого джависта в компании как раз все сидят из под впна ибо jetbrains лютуют, а мы, дотнетчики, как-то обходимся без этого. Так что еще вопрос кого там заместить проще.
Работаю в Гринатоме уже 3,5 года, это и есть главный интегратор IT в РосАтоме. На должности DevOps.
Скажу так, зарплаты тут крайне сложно поднять и все напрямую зависит, как тебе повезет. Тут даже ввели систему, увольняешься в четверг, один день идет оформления увольнения, в субботу выставляют объявления о вакансии, ты откликиваешься и тебя берут обратно. У меня коллеги по отделу работают уже больше 5 лет, а у них зарплата ниже моей, просто потому что за эти годы набежала инфляция, да и рынок изменился. Поэтому существует такой ТУПОЙ костыль в виде того, что обновляется твоя зарплата по рынку, когда она выставляется на бирже труда.
Причем, как я понял это связано какая ставка тебе попадется - государственная (которая тянется с РосАтом) или с Гринатовская ставка. У меня зарплата индексируется каждый полгода (ставка гранатовская), у моих коллег нет, ибо ставка старая росатомская.
Внутренние сервисы постепенно меняются на новые и они крайне удобные и быстрые. Но все ещё есть старые сервисы по типу СУИТ (система заявок) или СЭД (документа оборот), которые будут подбешивает.
Сейчас вот проблема в виде попа-боли, отказываемся от многих сервисов зарубежных, в том числе от Виндовс и это крайне сложный процесс, потому что многое что было завязано на Майкрасофт, чат и маил это Skype and Outlook.
Тоже, как повезет с сотрудниками, есть тупни лютые, а есть прям очень крутые ребята, которые заряжают энергией, но к сожалению их становится все меньше, опять же возвращаемся к вопросу о зарплате.
Если ты разработчик и как-то связан с сетью, это вообще забей, там такие лютые безопастники, которые понабрали из ближайших ПТУ, что прям хочется биться головой, ибо они выше тебя по статусу и если у тебя отвалиться сеть по их вине банально потому что они убрали СВ (заблокировали порт) и твой сервис умрет, ты можешь убить несколько дней и куча нервов, чтобы добраться до их начальство (хотя ты знаешь их поименно и лично) и сквозь бюрократию добиться своего и вернуть буквально то что работало всегда.
А так в целом нормально, как первая-вторая компания, но работать тут в долгую не советую.
О! Насчет безопастников это я вам верю на 120% =) Столкнулся с подобным кренделем на своем тернистом пути ещё в далеком 2008-м (тогда наоборот M$ везде пихали, внедрял шарепоинт в административной части одной местной ТЭЦ) Но он не был ПТУ-шником. Просто тип был своеобразным. Тоже любил без предупреждения рубануть и потом разбираться. Иногда путался там в своих правилах на любомой циске и рубил не то )) Слава вселенной, мое руководство было на короткой ноге с начальником ИТ - отдела ТЭЦ, т е с непосредственным начальником кренделя )
Одно из самых приятных при переходе из Росатома в новую компанию — отказ от е**чего Skype for Business, древнего и криво ломанного, который в Росатоме был основным софтом для коммуникации )
"...Вообще с чистым SQL в современном энтерпрайзе работают мало и редко... По моим ощущениям, им этот ответ не понравился, и в целом мне показалось, что оценили мои навыки в этой части низко..."
Насколько я знаю, в озоне пользоваться ормами запрещено за исключением узкого круга ненагруженных админок. Так что "фи" на эту тему достаточно предсказуемо.
а можете поделиться причинами такого подхода?
Вероятно из-за того, что:
Идёт работа с нестандартными запросами, а ORM не поддерживает это / генерирует неэффективные запросы?
Сервис без миграций и админки и нужен только для больших сложных запросов?
Но честно - хз. Только предполагаю
ИМХО, тут дело не только в классике "чем нам плох орм". В моей картине мира тимлид/сеньёр должен уметь "покрутить", поанализировать базейку запросами. Как свою, так и витринку в olap по своему домену. А они могут быть нетривиальными.
тут согласен - с помощью ORM не всегда можно реализовать нестандартные запросы. Для таких запрсов имеется RAW режим.
Но всё-равно нахожу довольно странным приоритет использования "чистого" SQL перед ORM.
Я бы предположил, что существенная часть бизнес-логики лежит в хранимках, вьюшках и функциях.. в этом случае "не нужон этот ваш ORM" )
Это да, хоть DBA-шником работать не привелось, но одно время хотел (и даже экзамены сдавал), и эти знания очень даже помогают в любой области, где есть БД (плюс-минус везде). Там просто диагностика с этого начинается - сколько таблиц? сколько в каждой из них строк? а столбцов? какие первичные и внешние ключи? какие индексы и констрэйнты? Этого обычно хватает для первичного понимания что и как, а дальше уже там можно смотреть какая кардинальность по колонкам, и всякое прочее )
ORM делает простым и без того простое, а сложное - еще сложнее.
Пока не запустите - не добудете запрос, можете лишь полагаться на опыт и здравый смысл, прогнозируя выхлоп, а EF умеет удивлять. Экспрешны дают некоторую статическую типизацию, но если углубиться в их генерацию - можно здорово наотстреливать ног в рантайме, да так, что ревьюер не догадается, а компилятор - не подстрахует.
С другой стороны, писать запросы руками - это не сложное занятие, с маппингом типов справится какой-нибудь Dapper. Даже если запрос билдится - это будет что-то тривиальное, сложностью управлять здесь очень просто, в отличие от абстракций экспрешнов с СУБД-специфичной трансляцией. Статической проверки типов в запросе нет, но явные имена полей и таблиц поддаются грепу.
Для таких запрсов имеется RAW режим.
Когда сырых запросов достаточно много, возникает вопрос: а стоит ли игра свеч? Стремились к простоте, а получили ласкутное одеяло технологий, альтернативных решений и срачи в ревью о границах допустимой сложности.
К тому же, EF Core лишь относительно недавно вообще научился запрашивать unmapped types, без чего в этом режиме было мало смысла.
EF потрясающ, но он не для этого. Это рализация паттерна репозиторий для общих случаев.. когда вы выходите за их рамки, то очевидно он вам уже не подходит
Ещё и нет гарантий, что после очередного обновления запросы, которые он генерит, останутся такими же.
А это может быть довольно деструктивно, если админы на стороне бд руками прибили индексы к запросам, как в оракле любят
На дотнексте допытывали озонщиков - насколько я понял, у них микросервисы с 1-2 эндпойнтами и суммарно 5ю запросами в БД. Поэтому это проще писать в одном условном файлике с голыми sql запросами без всяких ORM, т.к. оно оверхед для проекта и более предсказуемо ведет себя. Но они хвастались, что в постгрес-драйвере для дотнета кто-то из их сотрудников является чуть ли не главным мейнтейнером, поэтому в компании супер-экспертиза по этому драйверу и голому SQL в связке с дотнетом.
Для себя же я услышал, что разработчики там винтики в большой системе, только чтобы перекладывать json в sql. Если надо какое-то доп свойство замапить или связь дотюнить (что обыденность для развивающегося проекта), то вся работа по проекту ведется со SQL исключительно при помощи Ctrl+F, никаких тебе ошибок компиляции как в случае EF. В Т-Банке наоборот иной подход и они всеми руками за EF. Хотя не думаю, что там какие-то координально отличные нагрузки относительно озона.
У Т-Банка есть презентация своего фреймворка Kora для Котлина, и они там сделали даже свой язык макросов для конверсии SQL в методы языка.
Что-то я перехотел в Озон
Сейчас еще больше расхотите, из профильного чата:
Прям, сеньором-сеньором не был, но был опыт работы там, линейным c#-погромистом. Я там, наверняка, в "чёрных списках", поэтому не особо рискую.
Собесы. Сами по себе не настолько страшные - достаточно иметь голову на плечах и хорошо разбираться в вопросе. Куда сложнее пробиться сквозь первые энцать gateway перед самими собесами. Причём, могут пригласить, а потом передумать, потому что
Бардак. Звали в новую формируемую с нуля команду, с тем, чтобы постепенно вводить её в курс дела. Устроился, пришёл, подписали документы, выдали технику, логины, пароли - ну, пиши своему лиду, он тебе всё расскажет. А лида нет. И команды нет, только меня и взяли. А человека девать куда-то надо. Ну, слили в уже существующую команду.
И так тут не только с набором, а со всем.
3. Инфраструктура красивая и замороченная - тысячи микросервисов дружно работают, дышат, с репликациями, сообщаются друг с другом. Правда, нет документации, код - лучшая документация, не так ли? А почему нет документации?
4. Всё надо вчера. Сегодня уже поздно. О, у тебя два часа потрачено на задачу, которая решается час? Непорядок. Ну и что, что ты тут новый человек, всё же просто, просто берёшь, поднимаешь вот эти 15 проектов в докере в дебаге, и спокойно отлаживаешься. А, ты не знал что нужны именно эти проекты? Ну, сам виноват, знать надо - смотри код соседних репозиториев. И неважно что их столько сотен. А пока что, кстати, хреново ты работаешь, скотина такая.
5. Ненормированный рабочий график. На практике - сидишь, работаешь в час ночи, смотришь в маттермост - а там остальная команда тоже дружно въёбывает.
6. Условия. Вообще, хорошие. Если бы так не выматывало, в целом, круто.Закончилось моё знакомство с озоном на том, что я заболел, поработал в больном виде недельку, неистово тупя и отставая от графика, на что дали втык лиду и тот, чтоб не париться, уволил по причине "ничего не знает, ничего не умеет".
Виноват ли тут я? Наверняка в чём-то виноват.
Ничего не знаю, ничего не умею? Чушь, отлично работаю сейчас и хорошо работал в других местах. На этом, правда, очень хорошо, качественно выгорел.
Стоит ли идти в озон работать? Если ты очень сильно уверенный в себе сеньор, который видал жизнь во всех её позах, и отлично ориентируешься в сотнях микросервисов просто поглядев на них - иди, там тебе будет вполне ок. Иначе - нет, нет, ещё раз нет. Темп жизни сумасшедший, вздыхать и думать некогда.
Возможно вам просто не повезло попасть в такую команду. С другой стороны, возможно мне повезло отказаться от их оффера в 21 году и остаться на старом месте работы.
А уволили как? По собственному, или с тремя зарплатами как положено?
или с тремя зарплатами как положено
Мне даже интересно, сколько компаний реально так делают... 2/10? 3?
Мне пока ни одна не попалась. Все идут по одной дороге: "либо пиши по собственному, либо уволим по статье", в лучшем случае два оклада. Причём не важно на какой ноте увольняешься. Самый сок был в одной белгородской компании, которая, кстати, дочка Росатома. Сначала было "спасибо, как круто что ты за два месяца сделал нам новый сервис", а как только выяснилось что команда на новом проекте не нужна в таком же размере, ВДРУГ оказалось что я и работаю не очень да и вообще не очень-то им подхожу.
Можно, конечно, начинать с ними бодаться и писать в роструд, но это тот ещё квест, я уверен этим вообще единицы занимаются...
Ну меня как-то припекло и я занимался. Не так уж все сложно на самом деле, заскринил все переписки, записал на диктофон разговор с начальством, пошел к юристу и мне помогли составить грамотно досудебную претензию. Отправил ее в компанию официальной почтой после чего они резко вспомнили нормы ТК и выплатили мне три зарплаты. Но, конечно, мой случай, вероятно, ошибка выжившего.
Потому что ваши запросы, как правило, или слишком простые, чтобы для них использовать орм, или слишком сложные, чтобы их можно было качественно выразить через орм.
ОРМ прекрасно справляется с запросами когда их не более (скажем) одного в секунду из несложного джойна не более чем пяти-шести таблиц. А попробуйте добится быстрого отклика от БД когда размеры таблиц 10М записей и идут одновременно 10К запросов в секунду к джойнам многих таблиц. И одновременно идут инсерты и апдейты в ети таблицы. Без оптимизации на уровне БД делать нечего, на уровне ОРМ етого не добиться.
а можете поделиться причинами такого подхода?
ORM это кривая абстракция
Очень просто. Как выразился один мой коллега, когда-то работавший в Ozon Tech, "От Tech там только течь в башке. Как захотел лид, так все и будет и хоть ты тресни, никого не переубедить." То есть, у кого-то на высокой должности есть предубеждение перед ОРМ и ничего ты с этим сделать не сможешь. Ниже мой пост про то, какие условия они предлагают при хантинге, так что ничему не удивляюсь.
Во всех вакансиях на шарпистов у них в требуемых пунктах Entity Framework, и по нему задают вопросы на собесах.
Запрещено, но местами и дальше шли.
Когда я там работал, в моём проекте были вообще только хранимые процедуры на каждый селект.
Обычный собес на джуна, ничего особенного😑
В смысле на джуна? Можно пояснительную бригаду в студию?
Бытует расхожее мнение, что собеседование на джуна (в действительности на низкооплачиваемого неуверенного мидла) затрагивает множество технических тем и выжимает из соискателя все соки, в то время как интервью с сеньором довольно краткое (поскольку его и так уже в индустрии знают). Комический эффект фразы заключается в несоразмерности прилагаемых усилий и оплаты.
Emoji для лопаты в этом комментарии отсутствует, поскольку символ этого инструмента пока является только кандидатом в Unicode 16.0.
Отличная статья, столкнулся с теми же проблемами про поиске работы в июне этого года. У меня правда специализация другая, но сути это не меняет. Особенно повеселил Т-Банк, с их системой оценок. Мне кажется в Т-Банке все скатилось к тому, что интервьюер очень боится поставить настоящий уровень по той причине, что может быть потом с него спросят? И лучше сказать, что кандидат прошел собес на уровень два-ниже и все - с меня ответственность снята. Ну или уже 10-ый раз гоняя одни и те же задачи интервьюер подсознательно ожидает ответ за секунд, а если нет - ну незачет.
И другой момент с System Design интервью. Начал изучать эту тему. Оказывается там есть особые правила, этапы, которым надо следовать, обязательно говорить уверенно и без тени сомнения. Мол показывайте, что что-то знаете, чтобы продать себя подороже. Такой посыл основной. Вообще не понимаю, каким образом человек просмотревший на ютубе 6 интервью по URL shortener и заучивший эту задачу может помочь в реальной работе? Плюс тебя постоянно перебивают и перескакивают с темы на тему. И это называется проектированием системы.
На самом деле часто замечал этот момент. Когда люди собеседуют месяцами и годами, то одни и те же вопросы начинаются казаться банальной истиной, которую должен знать каждый джун. И не все задумываются, что вокруг у людей другой опыт, что не все проводят собесы и задротят те же темы.
В Т-Банке интервьюеры в целом ставят оценки согласно внутренним правилам, в зависимости от сложности вопросов и количества правильных ответов в разных темах. Т.е. получается более-менее справедливо для всех кандидатов. Но это, конечно, не отменяет тот факт, что кто-то старается выбирать адекватные и релевантные вопросы, старается получше раскрыть знания, а кто-то берет первые попавшиеся вопросы и не особо думает о кандидате.
Что касается настоящего уровня - от многих слышал, да и сам придерживаюсь мнения, что уровень обычно занижен. Т.е. Junior+ - это Middle во многих других компаниях, Middle - это Middle+ и так далее.
Сколько ни собесился в Тинькофф, всегда попадались душные, придирчивые и старающиеся самоутвердиться интервьюверы, объективными оценками и не пахло. Вопросы были из разряда "назовите методы класса Object", не назовешь хотя бы один - получаешь в ответ недовольное лицо типа "еще один недоджун пришел" и минус за вопрос. Хотя вроде очевидно, что такие вопросы проверяют лишь то, насколько кандидат заучил ответы на типичные вопросы на интервью и не более.
Каждый раз приходил, каждый раз заваливал, каждый раз думал про себя "ну и отлично, я бы с такими коллегами и не смог работать" и уходил на оффер в соседнюю компанию.
Полезная статья и комментарии к ней...
Недавно проходил собеседование, и не мог понять, как оценивают, по сути или формально... Плюс я это сделал после оч. большого перерыва.
Мне задали вопрос как реализовать фичу,(отправка сообщения в брокер, которая устойчива к падению сервера) - я подумал, сказал что ну можно создать хранилище или лог отправленных сообщений, по которому потом можно обработать потерянные данные - но решение мне показалось слишком на поверхности. Интервьвер мне предложил почитать про паттерн OutBox) Который я честно не помнил. Почитал - а я его собсна и придумал. Но зато я знаю что официально на ответ я не ответил. Как и на другие, вероятно)
Так что смотря на все эти ритуалы на собеседованиях - да, это просто ритуалы.
Собесился как-то в один желтый банк (другой, не Т, догадайтесь сами), так меня там на полном серьезе заставили развернуть связный список. Я как-то раньше ронял реплики про "там на собеседовании заставляют развернуть связный список" в иронично-утрированном ключе - ан нет, реальность мощнее иронии и такое бывает. На втором собеседовании (собеседование, к слову, было на синьора с перспективами техлида), меня спросили, дескать, вот фича, вот компоненты необходимые для реализации, как выстроишь процесс? К слову, оговорено, что компоненты сильно завязаны и без каждого в отдельности ничего как надо не заработает. Ну я подошел к этому как к технической задаче - реализуем фундамент, на нем промежуточные сервисы, потом сверху натягиваем фронт. Результат - отказ, по их словам, "слишком долго работал в аутсорсе, поэтому не думаю доставке минимального value клиенту в каждой итерации". Какое там value можно доставить, если без каждого в отдельности сервиса ничего не заработает, по их же словам - я не знаю. Это в финтехе, где абсолютно все сроки, этапы и требования обычно строго согласованы заранее. Вопрос, почему вообще именно разработчик, пусть даже и техлид, должен угадывать, как лучше угодить клиенту, остается открытым.
Да нормально всё, просто вы нарвались на шизоснобов в плохом настроении, тут не о чем рефлексировать.
Вопрос, почему вообще именно разработчик, пусть даже и техлид, должен угадывать
imho человек который хочет в специальность где есть менеджмент - обязан про это как минимум помнить.
если разраб будет строить звезду смерти для сервиса где надо из 3х полей формы сгенерить json и пульнуть кудато и потратит на это полгода, то это плохо
==
не защищаю их, но вообще
не думаю доставке минимального value клиенту в каждой итерации
Это важный фактор который многим нужен, особенно в онлайнсервисах которые постоянно работают-развиваются-апдейтятся
Помним контекст - это финтех. Сервис предполагается, предоставляет готовое решение по оценке активов (недвижимость вроде, не помню уже). Какое там value промежуточное вообще можно доставить, мне не пояснили, хотя я специально попросил уточнить после собеседования, ну просто для общего развития.
Вы целиком компанию оцениваете, в ее внутренности оценивают сами себя в течении года
Если какой-то производственный департамент чёто там пилит но результаты на рынок не выводятся в течении года, то возникнет вопрос что они вообще делают?
Речь шла о намного меньших сроках, порядка двух месяцев. Но вообще, имхо, это фундаментальная разница в подходах. Я действительно не люблю "Гибкие методологии" в таких вещах и ватерфолл при разработке полностью документированного продукта с нуля мне кажется гораздо более приемлемым выбором. Но это, конечно, вопрос срачный дискуссионный.
Плюс тебя постоянно перебивают и перескакивают с темы на тему.
Думаю это лайтовый вариант стресс-интервью, почти приличный
Перебивать и перескакивать разумеется не приветствуется, но тут всё зависит от конкретных собеседующих.
Возможно, проблема как раз в том, что вы говорите про заучивание решения задач по видео с Ютуба, а от вас ждут понимания того, какие инструменты применять в той или иной ситуации и знания типовых шаблонов. Сейчас все научились рисовать квадратики, но копни чуть глубже - сразу сыпятся на непонимании деталей.
Странно в тиньке то, что для разработчиков грейд, по сути, выставляется на первом собеседовании, и даже идеально сданные последующие секции особо не могут на него повлиять в сторону повышения.
Статья интересная, но пожалуйста, уберите Буше из списка бирюзовых компаний
Там ничего бирюзового нет, я бы сказала, что все красное. И в целом худшее место, в котором довелось работать
Привёл что в интернете пишут, сорян ) Так, может, потому и плохо, что бирюза нежизнеспособна?
Пока компания не очень большая и там “атмосфера стартапа” с заинтересованными людьми, вполне жизнеспособна.
По мере роста возникает потребность в иерархии и появляются люди, желающие "ломать систему”, а с ними бирюза не очень хорошо справляется.
Разве таких нельзя просто уволить ? На моей практике, людей увольняли из компании, если они начинали плохо себя вести, наглеть и т.п. Это я больше про отношения в коллективе, уважение и т.п. Никому не нужны токсики и те, кого лид будет регулярно заставлять делать свою работу, регулярно доказывать необходимость задачи и т.п.
Что-то мне кажется они хотели услышать конкретные метрики в ответе на вопрос- Как ты понимаешь, работает ли команда хорошо или нет?
я тут тоже заходил на собес к одному из списка
вам не кажется они реально это хотят услышать, причем очень формально...вообще сложилось ощущение что они там у себя построили полностью формализованную систему оценки эффективности-производительности на основе Velocity, Throughput и т.п. причем они не смогли внятно ответить что будет если эти метрики просядут из-за сложности задач или внешних блокеров... но требуют чтобы тимлиды очень конкретно целились в эти показатели считая их истиной и единой адекватной метрикой
А какие, например? Диаграмма сгорания? Процент багов? Это ведь то же самое, что я сказал, только другими словами )
Вы сказали без уважения )
а вы использовали слова: "спринт, сторипоинт, планинг, капасити" ???
Очень конечно уныло это всё...
Я вот работал в командах с жёстким, прям палочным скрамом, умею точно оценивать задачи на грумминге и скрам-покере с пол-пинка, знаю смысл всех этих метрик, но при этом без наводящих вопросов нормально на подобные вопросы тоже не отвечу...
Очевидно же, что это больше игра для менеджеров. Так нахрена это с лидов-то спрашивать, хспде...
А хотели услышать нужными словами 😁
Во-первых, я смотрю на скорость и качество результата их работы.
В чем скорость измеряется? Строк в секунду? А качество как померять? Это и будут конкретные метрики.
Во-вторых, смотрю, как много дополнительного ручного управления требует команда, как часто нужно подключаться, чтобы решить какую-то проблему внутри.
А вот здесь вы уже конкретную метрику для самостоятельности указали. Можете, когда захотите.
К сожалению, навык прохождения собеседований соотносится с настоящим умением работать программистом очень ортогонально. Я распишу своё мнение по современным процессам найма как-нибудь потом, но достаточно сказать, что для подготовки я в течение двух недель читал книжки и общался с DeepSeek, и без этой подготовки я бы собеседования нигде не прошёл. Хотя, разумеется, двухнедельное чтение книжек не сделали меня ни на йоту лучшим разработчиком, не добавили мне опыта и умений.
Это, кстати, на мой взгляд довольно серьёзная проблема, которая существует много лет и никак не решается. Никто не знает, как на самом деле нужно проводить собеседования, чтобы хотя бы с 90 % вероятностью выбрать из толпы того, кто нужен. Всё крайне субъективно и больше похоже на свидания, чем на подбор работника.
Моя прабабушка рассказывала, что её отец, чтобы подобрать батрака, рекомендовал посадить потенциальных кандидатов за стол и предложить обед. Эмпирика состояла в том, что кто с большим аппетитом ест, тот и работает лучше. Мне кажется, учитывая критику, которой подвергаются сложившиеся на подходы к собеседованиям в IT, эта практика вполне заслуживает внедрения в IT-сообществе, как доставляющая куда большее удовольствие соискателю, менее трудозатратная для нанимателя и, в общем-то, примерно в той же степени эффективная, как то, что мы имеем сейчас.
Моя прабабушка рассказывала, что её отец, чтобы подобрать батрака, рекомендовал посадить потенциальных кандидатов за стол и предложить обед
Забавно, мать мне рассказывала тоже самое (ей рассказывали старшие родственники, которые жили в деревне и знали все сами), если надо было нанять работника, то смотрели сколько он ест. Это было даже в советском фильме про Буратино)
Тоже слышал подобное в Москва слезам не верит
Я, кстати, на 100% не могу гарантировать, что почтенная дама не пересказывала эпизоды из просмотренных ранее фильмов под видом собственного опыта. Таким образом, она могла предвосхитить практику записывать себе в резюме все проекты, с которыми хотя бы рядом стоял.
Маловероятно, фильмы вышли сильно позже. Да и как посмотрю, практика была широко распространена, раз уж в фильмы вошла.
Подумалось вот что - были ли тогда ломатели собеседований? Которые специально не ели день другой чтобы удивлять всех своим волчьим аппетитом.
Есть (был?) такой проект, "Я помню" - массовые интервью с ветеранами войны. Так его основатель и главный интервьюер говорил, что ветераны регулярно начинали пересказывать ему эпизоды из популярных фильмов и книг о войне, при этом искренне считая, что это их личные воспоминания. Память человеческая - штука причудливая.
Если неделю-две ни чего не есть, то накинешься и на редьку - так себе показатель. Автор показал, что он не очень голоден и ценит себя!
У меня два собеса было в кафе и один в баре за кружкой пенного )
Хороший аппетит говорит об отсутствии каких-то очевидных проблем со здоровьем, пойдет при найме на физическую работу, но в ИТ... Хотя как работовзятель, методику одобряю) Соискатели будут обсуждать, в какой компании какие блюда предлагают, в каком заведении проводят интервью... ))
Вы просто ментально не менеджер, вернее не хотите отказываться от программирования, а значит не можете быть руководителем по определению. Это не плохо и не хорошо, это Ваш выбор. Хотя руководитель из Вас бы получился бы очень эффективный, так как Вы очень точно понимаете роль руководителя: создать условия для качественной и оперативной работы команды с минимальными вовлечением руководителя в микроменеджмент.
Ваш ответ по тому как понять, что команда работает хорошо, абсолютно правильный, это я Вам как преподаватель EMBA могу точно сказать.
В mindbox Вас не взяли как раз из-за Ваших установок, но это их ошибка, Вы адекватный человек и увидели бы, что в системе условных "бирюзовых компании" все работает и как раз открытость решает возможные вопросы недовольства.
Текст отличный, спасибо.
Есть такая роль - tech lead. Видимо, Вам хотелось туда. Проблема, что то это обычно роль, а не должность.
A tech lead is a senior software engineer who not only writes code but also guides a team in technical decisions, project direction, and mentoring junior developers. They play a crucial role in ensuring the technical success of projects while fostering collaboration within the team.
кроме вероятности нанять шарлатана, есть и обратный эффект: не нанять нормального спеца
есть классный чувак Джоэл Спольски, который написал книжку о том, как нанимать разработчиков. в ней он пишет так:
В процессе интервьюирования важно помнить следующее: лучше отказаться от хорошего кандидата, чем нанять плохого. Плохой работник будет стоить кучу денег, усилий и времени, которое другие люди потратят, исправляя его ошибки. В случае любых сомнений лучше сказать «не берем».
хороший специалист всегда найдёт работу, так что не нужно думать о том, что можно его обидеть, если отказать
Это потом превращается в "лучше отшить сто хороших кандидатов, чем нанять одного плохого" И из цитаты про Спольского следует, что понятие испытательного срока ему чуждо. Ну или все его плохие кандидаты успешно просачиваются как через сито собеседований, так и через сито испытательного срока.
ну... слушай, у нас были ситуации, когда мы искали чюваков полгода+, без выходов. это очень печально и выматывает, но реально не хочется нанимать кого-то, а потом думать о том, увольнять его или нет. хочется, чтобы кандидат выходил и сразу начинал фигачить)))
Так и нет у них испытательных сроков. Он же из США. Easy hire - easy fire. Уволить можно любого в один день. Хоть через месяц, хоть через год.
Что делает его заявление ещё более забавным.
USA и easy hire?)) Там собесы по году идут. Я туда (ну лан, в Канаду) в т.ч. не переехал имея рабочую визу из-за того, что где наш местный бигтех учится - они преподают. Собеседования на полгода-год там да щас? Или уже больше?
Это старая поговорка. И она не о сложности собеседований в ИТ.
Она про то, что законодательство заточено под интересы бизнеса. Меньше ограничений от государства. Там нет проблемы уволить человека в один день без всякой компенсации через год работы. В отличии от Европы, где нужна или серьёзная причина, или официальное сокращение штата, или надо компенсацию за пару месяцев выплатить.
В течение испытательного срока в UK можно без причины уволить, предупредив не менее чем за неделю.
В остальных крупных странах, если верить ИИ, тоже не сильно сложнее, и никаких компенсаций не требуется.
А в США не надо предупреждать за неделю. И не на испытательном сроке, а когда угодно, хоть через год, хоть через 10. Есть разница?
Hire это не собеседование а адаптация
Это прям щит 99 лвла казалось бы да если бы не одно но... Сквозь эти фильтры вредители всё-равно проходят (ну вот попал он во все фазы лун, все интервьеры были в хорошем настроении)
Никто не докажет что соотношение меньше или больше, чем если бы собеседование отталкивалось от опыта работы соискателя в духе STAR-куллсторей и разговора по душам.
Это прямое следствие того, что собеседование НИКАК не перекликается с работой. С таким же успехом как нанимать смотря на решение онлайн-литкода можно было бы копье метать или как тут писали - смотреть кто больше всех съест каши.
Итого мы получаем следующую картину - НЕТ В МИРЕ ФИЛЬТРОВ которые могут определить, что этот чувак вредитель. Их реально нет. Ну максимум верхнеуровнево отсечь тех, кто не может даже запросик написать. Почувствовать общее настроение, совпадение ментальностей и пр - это понятно, ценно. Попросить решить легкую задачку минут на 5-10 чтобы глянуть как пишет, что спросит - это понятно.
Ключевой рабочий способ работы с вредителями - это продумать стратегию вывода этого вредителя из отдела (а лучше из конторы).
Вроде бы и дорого, держишь, смотришь, какой-то код он там напишет, зарплату ему в это время платить, мб выходные оклады (это прежде чем определить, что чел не эффективен) НО есть другая рука о которой чуваки смотрящие в рот FAANG без критического мышления не могут взять в толк: есть цена этого полугодового найма с кучей людей, этих бесчисленных потраченных часов специалистов уже у тебя работающих (причем лидов). И всё-равно ты получишь вредителей. И всё-равно придется с ними расставаться. И всё-равно будет их код. И всё в тех же количествах.
Не будь этого цирка - разработчики бы спокойно работали уверенные что если чего - их опыт будет оценен другой конторой и он не останется голодным на улице за бортом. И сосредоточился на решении текущих задач.
А сейчас этой уверенности нет по факту, и приходится вместо работы готовиться к собесам и осваивать самопродажи. Если работодатель думает, что это разработчики будут делать только за свой счет, а не за счет работодателя - то мой пламенный привет на планету розовых пони.
Подскажи, как более опытный разработчик, что более востребовательно/нужно в связке с DotNet'ом
1) Kafka/RabbitMQ
2) Angular/React/Vue
Или все это сугубо зависит от компании, где будет юзаться и можно смело брать что-то и просто учить?
В энтерпрайзе много высоконагруженного, поэтому часто выбирают Kafka, потому что у неё из коробки всякая балансировка, репликации и так далее.
Что касается фронта, то с шарпом я чаще всего встречал Angular. Кажется, есть какие-то исторические причины. Angular привязан к TypeScript, который тоже детище Microsoft, как и C#. Но глубоко я не копал.
В энтерпрайзе много высоконагруженного, поэтому часто выбирают Kafka, потому что у неё из коробки всякая балансировка, репликации и так далее.
только кафка и кролик не взаимозаменяемы в полной мере, я вот в текущем энтерпрайзе наткнулся на то что если из кафки пытаются сделать кролика и это довольно своеобразный велосипед получается
По опыту хождения по собесам чаще встречается rabbitmq (хотя учитывая что там с masstransit происходит пока не понятно что там будет в будущем).
Фронт делают на всем чем только можно, это вопрос слабо связанный с тем что там на бэке крутится. У нас фронты делают его на react + typescript.
В дополнение к прочим ответам советую посмотреть в NATS в 1 вопросе. Понятно что это гораздо более нишевое решение, но мне очень понравилось.
Тем более, на джаве я всё-таки чуть-чуть кодил, просто после шарпа возвращаться на неё это как пересесть на старую Ладу с новенькой иномарки: вроде ездит, но уже давно привык к другому уровню комфорта.
А?))
Шикарная статья, спасибо огромное, прочитал с удовольствием, хотя не очень люблю "многабукф"
Удачи на новом месте
Немного обидно за Go. Почему считаете его унылейшим языком?
Нет ООП, нет перегрузки, нет ко-контравариантности, нет встроенных инструментов для работы с коллекциями и так далее. Вообще не понимаю, как на таком языке строить солюшен-архитектуру. Но возможно я просто завидую, что гошникам много платят! :)
ко-контравариантности
ко-ко-ко вы хотели сказать?
На самом деле в го просто немного другой подход к программированию, который отличается от принятых например в C#/Java и также важно понимать, что го используется для более узкого круга задач и изначально проектировался как более простой и прозрачный язык, хотел бы немного обсудить ваши тезисы:
Нет ООП - в привычных терминах ООП скорее урезано, интерфейсы работают проще и наследования нет, вместо него используют встраивание. Тут лично мой опыт, но его практически всегда достаточно, даже в крупных проектах(я имею ввиду те, что пишут на го).
нет перегрузки - её нет, но если что-то похожее нужно то вполне можно заменить при помощи Functional Options Pattern, будет одна функция, в которую вы сможете передавать разные параметры, опять же код будет посложнее, но в целом это не прям проблемно вроде
нет ко-контравариантности, тут я так понимаю подразумеваются также и ковариативность и т.д., тут опять же в таком виде как в Java их нет, но если такое поведение реально нужно в проекте его можно добиться, хотя оно конечно будет реализовано не так красиво
нет встроенных инструментов для работы с коллекциями - прям встроенных вроде нет (только для базовых типов, что-то есть) но после ввода дженериков можно либо что-то готовое использовать либо самому написать, да там есть ряд ограничений, но не сказал бы что на практике это реально часто мешает (опять же го проекты) да и для большинства задач это хватит.
не понимаю, как на таком языке строить солюшен-архитектуру - тут бы хотелось услышать подробнее, что подразумевается. Вроде СА никак не привязана к языку.
Ну вот смотрите, у вас почти по всем пунктам ответы: "есть но урезано", "не так красиво", "можно самому написать" и так далее. Язык это инструмент. Если мне инструмент сначала нужно самому допиливать под довольно типовые задачи энтерпрайза, то это, на мой взгляд, неудачный инструмент.
Вроде СА никак не привязана к языку.
Указанные мной средства нужны, чтобы очертить разработчику зону его власти, за которую он не должен выходить, или его прямо компилятор по рукам ударит. Чтобы на уровне статического анализа показывать, как ведёт себя домен. Если домен сложный (в энтерпрайзе это часто), то для описания его поведения нужна сложная система типов. Вот в DDD один из корневых принципов это изоляция доменных моделей и агрегатов от слоя приложения, как гошники решают эту проблему?
Ну вот смотрите, у вас почти по всем пунктам ответы: "есть но урезано", "не так красиво"
Так мы же и рассматривали минусы, я же сразу отметил что в целом в го подход к разработке отличается от c#/java. Изначально язык проектировался так, чтобы уйти от большого количества абстракций, и быть ближе к разрабам на C.
Если мне инструмент сначала нужно самому допиливать под довольно типовые задачи энтерпрайза
Можете конкретный пример привести, я говорил только про то что "можно" самому дописать, а можно взять готовое(для многих в го не проблема написать типовую функцию для работы с коллекцией) кому что удобнее
Если домен сложный (в энтерпрайзе это часто), то для описания его поведения нужна сложная система типов.
Тут тоже услышать бы реальный пример, на го вполне успешно написаны сложные инструменты типа докера, кубернетеса, терраформ, в банковской сфере есть Monzo да и многие компании используют го
Вот в DDD один из корневых принципов это изоляция доменных моделей и агрегатов от слоя приложения, как гошники решают эту проблему?
Если кратко то через интерфейсы и пакеты.
В целом больштнство современных проектов вы можете писать без какой-то боли. Но писать на нём так как в C#/Java, то вы вероятно встретите негативную реакцию. Т.к. просто другой подход в языке используется.
P.S. Вы написали много про проблемы, поэтому хотелось бы услышать реальный пример на уровне фичи или бизнес задачи
Извольте. Есть в одном сервисе две сущности: письмо и документ.
Пусть у письма бывают статусы: создано, отправлено.
У документа бывают статусы: создано, согласовано.
Никакая из этих сущностей не является композиционно составной частью второй: они вполне себе живут изолировано. Но иногда к письму может быть приложен документ. И в таком случае сменить статус письма с "Создано" на "Отправлено" (то есть отправить письмо) можно только тогда, когда документ в нём согласован. Типичная энтерпрайз задача на минималках.
Как на Go будет выглядеть модель данных, которая не даст использующему её программисту сломать инвариант?
Как на Go будет выглядеть модель данных, которая не даст использующему её программисту сломать инвариант?
type Document struct {
id string
status documentStatus
}
type Letter struct {
id string
status letterStatus
document *Document
}
В целом можно примерно так сделать, для простоты в одном пакете разместил. В случае который вы описали, логичнее всего добавить к письму информацию о документе, ниже то как работа будет выглядеть с точки зрения обычного программиста в комментах вывод
func main() {
doc := NewDocument("doc-1")
letter := NewLetter("letter-1")
letter.AttachDocument(doc)
err := letter.Send()
fmt.Println("1. Send:", err)
doc.Approve()
err = letter.Send()
fmt.Println("2. Send:", err)
err = letter.Send()
fmt.Println("3. Send again:", err)
}
/*
1. Send: attached document is not approved
2. Send: <nil>
3. Send again: letter already sent
*/полный код (ряд моментов упростил но как пример думаю подойдет)
Вот вам пришлось добавить композицию там, где по бизнесу её нет (включить документ в письмо). Это усилило coupling. На таком мелком примере проблем нет, но что если на самом деле таких сценариев много, и к письму кроме документа может быть приложен протокол, отчет, акт сверки итд. И у каждого свои правила. Вы не только в письмо добавите кучу полей, но и письмо начнет становиться божественным объектом, бизнес-логика из других контекстов протечет в него.
Можно обойтись и без композиции, например отедльную абстракцию сделать под отправку письма, где каждое вложение будет проверяться отдельно. Думаю это будет +/- так выглядеть
type Attachment interface {
IsApproved() bool
Type() string
}
type LetterService struct {
attachments AttachmentRepository
}
func (s *LetterService) SendLetter(l *Letter) error {
atts := s.attachments.GetAttachmentsForLetter(l.ID())
for _, a := range atts {
if !a.IsApproved() {
return fmt.Errorf("attachment %s not approved", a.Type())
}
}
//...
return nil
}"допиливать под довольно типовые задачи энтерпрайза" если у вас большая корпорация типа СберАвитоЗона, то все паттерны и типовые задачи с высокой степенью вероятностью за вас уже сделаны разработчиками "платформы". А вот избыточная вариативность скорее вредит: чем проще и "стандартнее" код, тем проще засунуть "на весло" новичка, чтобы он загребал жсоны в кафку.
PS есть опыт разгребания "разного" на c#, java, go - в общем гошный код читать легче, даже если он написан "наркоманами".
Да, ещё лет через пять го допилят до вменяемого уровня и можно будет пользоваться.
Мне кажется вам надо быть более взрослым, и более специалистом что-ли, если уж вы метите в лиды - и должны понимать, что нет плохих или хороших языков(унылых или не унылых). Все языки, которые успешно используются - хорошие. Просто какие-то лучше подходят для одних задач, а какие-то лучше для других.
я просто завидую, что гошникам много платят! :)
А почему им столько платят?
Этот вопрос не даёт мне покоя.
Ну тут либо все в бизнесе дураки и не лечатся, либо причина все-таки есть.
Причина проста — как и множество других инновационных технологий: кто-то притащил в энтерпрайз "потому что крутые пацаны из гугла придумали", а потом это уже приходится поддерживать. А на этот энтерпрайз тоже со стороны понасмотрятся и давай это барахло в пет-проджекты тащить...
Так оно и расползается постепенно.
кто-то притащил в энтерпрайз "потому что крутые пацаны из гугла придумали"
Ясно. Ваш ответ: "Все дураки"
Отнюдь. Я не считаю всех дураками. В мире в целом и в IT в частности полно умных людей. В IT даже, я склонен думать, в целом уровень интеллекта в среднем даже выше, чем в среднем по миру (тут всё-таки головой приходится думать).
Но вот большинство, включая тех, кто зачастую принимает решение - да, дураки. Что вы, в общем-то наглядно демонстрируете, своим нелепым обобщением, полностью проигнорировав суть мною написанного.
Go создан чтобы писать микросервисы. Простой язык, среды выполнения нет, нет зависимостей. Самое то для запуска в том же кубере. То, что на нем пытаются писать все подряд вплоть до сложных монолитов - не проблема языка.
Хмм, позвольте возразить, но «тимлид» в энтерпрайзе это чисто менеджерская должность. Программировать на ней получается разве что программистов в аутлуке.
Должность выше сеньорской, в которой помимо технического менеджмента дозволяется залазить непосредственно в код, называется «техлид». И совершенно иные вводные.
Сразу видно специалиста - 150 лайков за 6 часов
В следующий раз пишите, что у вас опыта не 15+ лет, а 7-10 - отбоя от скринигов не будет ;)
тоже была такая идея, но не успел проверить на практике. А почему думаете, что так будет работать?
очевидно же, что айтишник в 30 лет превращается в замшелого деда с закаменевшим мозгом и остальные 35 лет своей карьеры повсеместно внедряет некротехнологии вместо качественных современных решений. Это всё потому что научиться новому он с окаменевшим мозгом не способен: чуть ослабил внимание и он опять внедрит свои некротехнологии, если не остановить вовремя. /s
Тараканы в целом есть и они достаточно массовые, чтобы стоило их учитывать и максимально резать информацию о деятельности больше 10 лет назад, включая информацию о возрасте.
Тоже пришёл к аналогичному наблюдению
Блин, я программером стал в 33 года. Перешел с менеджерской ветки в ИТ (там дорос до ген дира). А стаж программера сейчас у меня 15 лет. И занимаюсь я сейчас высоконагруженными проектами, как менеджер/техлид. И я скажу так - база в ИТ сейчас та же, что и 30 лет назад. А если под "технологиями" понимать фреймворки/языки/подходы, то да, они меняются и развиваются. Но тут как с иностранными языками - после пятого или шестого они учатся очень легко и языки одной группы не очень интересны. Хочется экзотики. Корейский или суахили.
В моём понимании тимлид это как раз сеньор с развитыми софт-скиллами (которые я у себя считаю сильной стороной). Если в рамках их оценки я сеньор, но не тимлид, то, значит, не увидели моих софт-скиллов совсем.
Я думаю, проблема в этом. Т.е. вы переоценили свои софт-скилы. Как автономный разработчик, которому можно дать задачу для самостоятельного выполнения, вы подошли. А вот как разработчик-управленец (который должен условному джуну объяснить не только "как" делать, но и "почему"). В команде могут быть джуны-миддлы-сеньоры с таким же поведением, как ваши интервьюеры. Т.е. уводить ваши рассуждения на условное "неправильное использование lock". Вы не смогли организовать работу в команде с такими сотрудниками, а других для вас нет.
Вышеизложенное является исключительно IMHO, основанное на описанном прохождении собеседований.
Хорошо быть молодым - резюме туда, резюме сюда :) В ноябре-декабре искал работу - тоже .NET, тоже после тимлидства. Из немногих собеседований больше всего понравился T-Bank - очень четко, по делу и с обратной связью. Но последнюю встречу с командой отложили раз, отложили два - ситуация на рынке не та, чтобы разбрасываться офферами, так что просто пошел в ПСБ. Готовился по похожей литературе, но не увидел популярного "кабанчика" - для собеседований это полезно. А еще полезно leetcode уровня easy - просто для навыков быстрого решения типовых задач. Искал работу порядка месяца-двух и считаю, что мне еще повезло.
Литкод решаю периодически просто для разминки, да (easy и medium). Да, у меня заняло всё около двух месяцев тоже.
До кабанчика что-то руки так и не дошли, даже не купил его.
Кстати, как в итоге в ПСБ? Я слышал что Астра, плохие процессы и легаси, но при этом есть деньги. Они меня хантили пару лет назад, когда я ещё не искал работу новую.
нормально :)
Во-первых, как обычно - ПСБ большой, зависит от команды, проекта, технологий и пр. Во-вторых, как обычно :) - всегда есть куда расти. Это банк, поэтому ИБ и легаси, но и не совсем стоячее болото. А раз банк, то и деньги водятся. Так что есть и плюсы и минусы, но в целом я совершенно не жалею, что попал сюда.
ETL-разраб/DWH-инженер. Собесился 2 года назад, просил определенный оклад - мне бесшовно его и дали + квартальные и годовые премии которые реально платили. По деньгам было лучшее предложение на тот момент. Плюс 146%, перекрывает кучу минусов. (как выяснилось - индексации нет, некоторые старички с лычками повыше - получают меньше. Самому просить - есть нюанс, в самом конце поста)
Собесился как etl/dwh-разраб с уклоном в python -> получил в итоге java (ну окэй, десятый+ ЯП у меня в списке, не вопрос)
По работе: 1 задачка на неделю работы (если делать спокойно, вдумчиво, обрабатывать неожиданные кейсы и пр) по факту растягивается на полгода-год-полтора в изи, т.к. выдачу доступа дают месяцами, потом эти доступы слетают... Даешь тестеру задачу - завтра в jira он будто уволен - послезавтра он пишет, что у него слетели все доступы и он их неделями восстанавливает...
Импортозамещение... самый топ пока Confluence -> Naumen - страницы просто не открываются, вендор на щщах советует вручную очистить в браузере js-классы... (доступы в конфлюенс уже забрали)
Я работал с десятком компаний, но такой уровень эффективности... У меня теперь НОЛЬ комплексов и полностью отсутствует синдром самозванца.
ПО старой версии, плагинов нет, офис класса B (бывшая промзона) на дербеневке - серый убитый монолит, чайники постоянно в накипи, далеко от метро пешком, спасает наличие удаленки (вход в контур с корп. ноута по 10 минут), НО надо иногда ездить в офис оформлять доки (читай ниже)/обновлять токен/etc (+ первые 3 месяца ездишь в офис, у меня уже начал глаз дергаться).
В ЛАБ РУЧНОЙ документооборот ВМЕСТЕ с электронным банковским (да, дубликат, 2 отпуска оформляешь в 2 конторы). Надо закладывать полдня на оформление бумаг (и да, прям потом по внутренней почте, бумаги в конверт, клееем смазать надо хорошенько обязательно...). Тоже отродясь подобного нигде не видел до текущего момента.
Помимо денег плюсом выступила ненапряжность (в моем конкретно кейсе). Пару раз до ночи поработать пришлось, но в целом месяцами ничего порой не делаешь, готовишься к собесам там.
В этом году срезали всем квартальную, с задержкой в 3 месяца выдали годовую. Пошли массовые сокращения армии народу взятых 2-3 года назад по импортозамещению - наверху по деньгам не договорились там. Помянем.
Кста, когда я шел в ПСБ я прошел и в Т-Банк, но там эйчар на 2 недели просто пропал безмолвно, хотя тех секции мне сказали всё ок (грейда мне не говорили кстати).
В итоге я уже сижу бумаги в ПСБ оформляю - мне сказали мне нашли место в python-команде на пообщаться... Скоростя адские.
Ну и сейчас я ищу работу и несколько в шоке. Я больше года к собеседованиям готовился на архитектора/лида в лайт режиме, но ковырял всякую теорию (репликация, согласованность, ACID/CAP/etc) - могу сказать, что всё это мне пригождается, НО ЭТОГО НЕ ДОСТАТОЧНО.
Самое забавное, что очень много проблем в собеседующих
Сталкиваюсь с тем, что интервьюеры сами не знают о чем спрашивают (не редко удивляются, что ACID-изоляция Serializable в Oracle - не соответствует заявленному уровню, а является Snapshot-isolation, хотя заявляют что читали Клеппмана...), удивляются что с FULL JOIN можно получить t1 * t2 в максимальном случае, а не t1 + t2 (уже не раз на таких натыкался), хотят опыт внедрения чего-то по принципам DAMA-BOOK (прям в вакансии написано) хотя такого понятия нет в природе, а есть литература типа DAMA-*BOK* (DAMA-DMBOK, DAMA-DMBOK2, DAMA-PMBOK, etc) и т.д.
Перчинку добавляет то, что всё АйТи пронизано терминологическими конфликтами. Реплика, реляционность, согласованность, serializable, DDD (Data-Driven? Domain-driven? Development/Design?), ООП, ACID/CAP и т.д. и т.п. - у меня уже десятки заметок со списком противоречивых цитат практически по любому определению в ИТ - как в таких условиях за час хоть что-то проговорить нормально - мне пока не понятно. Когда ты просто изучаешь тему по ИТ ЛЮБУЮ (прям нормально, с выписыванием цитат по заметкам) - ты будто бомж на помойке роешься
Сейчас сижу жую каскад какой-то лабуды про Data Mesh, data governance, и подобное...
Вообще конечно цирк. Я прошел сотни собесов, вне зависимости от оффер/отказ ни одного не вспомню собеса который бы внятно мог раскрыть мои плюсы и минусы. Можно просто таро раскладывать - тот же успех будет. Не говоря об опыте, когда на месте разраба в бигтехе типа яндекса сидит чувак ГОДАМИ который просто с нейросетки не думая закидывает код (его потом правят сеньоры и оно летит в прод), и от него избавляются только после серьезного расследования где предъявляются скриншоты с его инстаграмма где он пьяный хватает теток за задницы в тот момент когда отпросился с работы "по болезни"... (я уверен, что он кому-то литкод-собес проводил, 146%)
Будто с рептилиями общаешься, ей богу...
Еще добавлю. Есть такая мулька типа "устроиться по знакомству". Представьте - так вышло, что вы понравились одному ИТ-гению-шизоиду (который кстати сам годами долбился в разные места), который профессиональный математик, его резюме рассматривают на миллионые вакансии как решателя диффуров, он закрыл ряд проектов для FAANG типа амазона и пр., он сам стал тимлидом датасаенс отдела в бигтех и так нравится своему руководителю (ребенку основателя компании), что тот ему индексирует зп регулярно и он щас получает по потолку тимлид вилки. Он был вашим руководителем пару лет, а щас просто дружите.
Вы значит с ним в раз в месяцок в кальянной сидите, пыхаете, обсуждаете всё, от баб до видов расспараллеливания (суперскаляры, SIMD, очередные терминологические конфликты например по "векторизации" и т.д.)
И тут у его конторы под вас появляются разные вакансии. Этот тимлид просит напрямую ваше резюме и отдает своему hr-у. Итого эйчар получил резюме с рук ОЧЕНЬ крутого чувака любимого в компании, который сам регулярно проводит собесы и прочее с ревью - "очень хороший специалист".
Реакция этой компании? Надо прогнать по всем этапам собеседований! (Ну и на эту позицию я не пошел т.к. у них потолок вилки оказался хуже чем моя текущая зп). Ноль баллов плюсом накидывает рекомендация, ЗЕ-РО
Кстати, на другие вакансии на которые я щас хожу - в этой конторе меня не рассматривают, хотя есть фит технический
Я к чему - если вы думаете, что вам нетворкинг как-то там поможет обойти этот цирк - я вам желаю удачи, сквозь смех того джокера в исполнении Хоакина...
P.S.: именно из этой конторы полтора года пытались уволить того вредителя который с ИИ пушил голый код в репо. Чувак кстати успешно прошел все стадии в ОЗОН (и устроился уже), который нашел алмаз в этом hr-болоте... Помянем.
Реакция вашей компании? Надо прогнать по всем этапам собеседований!
Это везде сейчас так. Неважно, какой у человека опыт. Неважно, сколько у него выступлений завершенных проектов, выступлений на конференциях, выпущенных книг, участия в Open Source, проектов на гуглплеях и русторах. Есть какая-то формальная процедура прохождения собеседования. Хочешь - не хочешь, а через неё проведут кандидата, даже если сама процедура крайне далека от совершенства.
Да да да, я про то же самое, не рекомендую никому обольщаться. Вкладываться в опенсорс и т.п. тоже дело гиблое
А вот литкод это да!
А есть вообще смысл в LeetCode? Хотя бы на собеседованиях кто-нибудь смотрел там аккаунт, или это пустая трата времени?
Я на литкоде был, аккаунт есть. Готовился перед тиньком 2 дня и перед яндексом еще пересмотрел свои записи. В тинек прошел. В яндекс нет.
Готовиться имхо стоит, я с такого рода задачами лично ессесно как и 99% программистов не сталкиваюсь вообще никак и никогда. Либо столкнулся с чем-то очень отдаленном похожим, решил через SO/AI, причесал и забыл. Так что кроме как на литкоде больше с этими задачами больше нигде и не встретиться.
Моя проблема среди прочего в том, что я с ЯП определиться не могу, в прошлый раз на js решал, в этот на python надо было, а у меня элементарные вещи в моменте вылетают типа как разбить строку на токены (забыл про .split) т.к. вчера я работал вообще с bash-ем. Мне мои навыки работы с зоопарком технологий в работе помогают, и резюме украшают, но когда надо с конкретной бестолковой детализацией конкретной технологии возиться по памяти - тут проблемы, а бигтехному конвееру это всё понятно до лампочки, и рот открывать нет смысла.
Возвращаясь к литкоду: есть своеобразные плюсы, когда например становится чуть-чуть яснее как устроены те же индексы в БД, но и без литкода там для пользования всё понятно было бы.
Мне лень прям упарываться. Если ждет литкод сессия - чуть повспоминал задачки старые, порешал что-то если предложили методички hr - и вперед крутить рулетку. Дальше многое зависит от настроения интервьюера. Я в Тинек прошел с меньшими знаниями, чем не прошел в яндекс, просто тогда мне попался очень позитивный такой чувак, который не стеснялся мне подсказывать и в итоге мне выкатил кучу похвал в ревью.
Тут еще не угадаешь с форматом. В Яндексе за час ожидали решения 3ех задач (я успел 2 и 3ю только понял как делать, но не успел написать), в тиньке за час тогда была 1 или 2.
Лотерея. Полная.
выпущенных книг, участия в Open Source
Повод скинуть 50к от зарплаты
Типа, раз он и бесплатно может работать, то зачем ему платить больше, всё равно кодить будет.
Опенсорс - повод вообще не брать!! Если после работы остается время на опенсорс - значит недорабатывает на нас чувак адски, это жесткий минус (исключение - если вы за ведение опенсорса получаете деньги от работодателя, например в кликхаусе пашете)
Привет, подписываюсь под каждым словом) Кроме того, подозреваю, что кому-то может быть страшно брать на работу слишком умного: "А вдруг он окажется умнее меня?".
удивляются что с FULL JOIN можно получить t1 * t2 в максимальном случае, а не t1 + t2
Можете пояснить, что вы имели ввиду?
Если ключевые поля, по которому идет джоин, содержат дубликаты значений - то будет перемножение. Я на практике пару раз попал на это за все время работы программистом, когда джоин был не по PK/FK
Семантически inner join по определению в стандарте выводится через декартово произведение с дальнейшей фильтрацией по условию джоина. Full outer join просто добавит к результату inner join-а строки из обеих таблиц, не попавшие в inner join.
Интервьюверам надо изучать SQL не по диаграммкам с кружочками, а заглядывая в стандарт.
Зачем мне это объяснять? Я знаю, что
c) If a <join condition> is specified, then let T be the multi-
set of rows of CP for which the specified <search condition>
is true.
То есть join может свестись к декартовому произведению (CP) при неудачном search condition. Я просто спрашивал, что там за звездочки и плюсики, причем тут full outer join и декартово произведение, почему именно full outer join (full outer join по сравнению с inner join никакого нового декартового произведения не даст)
Как говорится, я подумал, и мы решили: минимальная мощность full outer join двух таблиц - это максимальная мощность одной из них. А максимальная мощность full outer join - это мощность декартова произведения его таблиц, что является максимальной мощностью inner join-а. Это к вопросу - зачем было приплетать редко используемый вид джоина, если можно было обойтись базой в виде inner.
Ну вот любят интервьеры гонять тебя в качестве интерпретатора SQL-запросов. Один из базовых вопросов это "скока min/max строк можно получить соединив две таблицы"? Речь доходит до FULL JOIN
Ты говоришь - перемножение. Тебе говорят "ЧАВО?!". Там максимум t1+t2. Ты говоришь - дубликаты по ключу. Тебе в ответ: ыыыыыыаыаыаыа какое-то непонятное я запомнить не могу, чето типа "ну а кто сказал что есть дубликаты", ты "а кто сказал что их нет?" и понеслась
Ну и на всякий случай для самых непонятливых:
WITH
tbl_1 AS (
SELECT 1 AS department_id, 'VAL1' AS department_name
UNION
SELECT 1, 'VAL2'
UNION
SELECT 1, 'VAL3'
),
tbl_2 AS (
SELECT 1 AS department_id, 'VAL1' AS department_name
UNION
SELECT 1, 'VAL2'
UNION
SELECT 1, 'VAL3'
),
tbl_fin AS (
SELECT *
FROM tbl_1
FULL JOIN tbl_2
ON tbl_1.department_id = tbl_2.department_id
)
SELECT * FROM tbl_fin
Запустить можно тут https://sqlize.online/sql/psql15
В том-то и дело, что дело до full outer join-а не должно было дойти, если речь шла о том, какое максимальное количество строк вернёт любой джоин при любом условии объединения. Full outer join не может вернуть больше строк, чем inner join если join condition всегда true (Cartesian product)
Что за дичь, хспде... Такие запросы в проде вообще где встречаются?
Я full join почти никогда не использовал, либо мб в паре экзотических случаев, на которые наткнулся случайно.
Но на собесах уже ни раз ни два и не три full join гоняют. Помню я уже получил 3 оффера на DWH, а тут меня просит собеседующий написать full join без full join... (для всех интересующихся: right + left + их union) А я в этот момент забыл что вообще этот join возвращает которым я никогда не пользовался. Собеседование на этом и закончилось, ахах
Но шизики они эвривере, кто-то прокоментировал этот кейс в духе "ну ля как ето не пользовался, а как же таблицы сверять?"... Емае... Про существование 100500 способов сверок таблиц в зависимости от инструмента и ситуации я ему даже вдаваться не начал.
Настроения бодаться с его субъективной практикой помноженной на эго по средствам криво вспоминаемых конкретных кейсов и додумках в режиме вербальной перепалки двух кожаных-sql-интерпретаторов мне было влом...
А не поделитесь заметками? Думаю, будет интересно составить из этого какую-нибудь статью или мини справочник.
1 точка = 1 заметка. По ИТ суммарно их сейчас около 1500 из 4к (обвел). Пока что. Боюсь на хабр не влезет) Да и чтобы их внятно читать у меня свои кастомные js-скрипты и набор обсидиановских плагинов.
Когда-нибудь я напишу читабельную для стороннего человека статейку/справочник наверное (не факт), но пока ограничусь местными комментариями)
Помимо денег плюсом выступила ненапряжность (в моем конкретно кейсе)
Пошли массовые сокращения армии народу взятых 2-3 года назад по импортозамещению - наверху по деньгам не договорились там.
Как по мне, эти 2 пункта плохо сочетаются - ненапряжность с последующим разгоном болота
Ну как есть. В большим корпорациях можно потеряться в процессах, но происходят и сокращения или отсутствие индексаций (коллег сокращали и из ОЗОН-а и спортмастера и еще откуда угодно - никто не защищен).
Но тут как факт надо принять - ПО нормального нет, всё старое, всё без плагинов, всё через согласование с пояснениями в духе "не верблюд", все работают очень медленно (приемник релизится-релизится да не вырелизится годами), ДИБ выдает доступа месяцами к БД СВОЕГО ЖЕ ОТДЕЛА В ДЕВ/ТЕСТОВОМ КОНТУРЕ, потом неожиданно их забирает (и надо еще месяц возвращать), много откровенно странных архитектурных решений которые надо пояснять и исправлять
Ну т.е. тут инициативу проявлять просто некуда. Ну ты скорее со всеми переругаешься, сотрешь в ноль нервы, выхлопа никакого, всё-равно уйдешь т.к. "не вписался в вайб отдела", но при этом ты не готовился к собесам, а занимался хз пойми чем (не секрет же да, что корреляция между собесами и работой - НИКАКАЯ + ценность твоего опыта для других работодателей ограничивается только началом разговора с hr и всё)
Ну и изначально я не знал НАСКОЛЬКО всё весело (опыт незабываемый, на всю жизнь)
Поэтому когда попадаешь в такую ситуацию - трать время на подготовку к собесам желательно на вакансию повыше. Рано или поздно либо сократят либо зп не проиндексируют. Я этим и занимался. Рынок неприятно удивляет всё-равно, но могло быть и хуже если бы я чем-то другим маялся.
Наверное поэтому и коллеги со стороны источников и заказчиков поголовно сквозь рукава работали (по 2 часа на конфколле онлайн пытаются в логи посмотреть своего сервиса чтобы понять, че у них там происходит)
Все эти конторы развели цирк из собеседований и получают то что и заслужили - вместо реальной работы ее разработчикам выгодно вкладываться в подготовку к собесам (ну потому что я лично знаю n-тимлидов который в личных разговорах ничтоже сумняшеся так и заявляют "а че слушать их про опыт работы - тошнят уже" (да и на хабре тут масса таких авторов). Ну тогда спрашивается - а зачем пройдя к тебе на работу мне работать, если это на рынке ценности не имеет? Я прохожу собес на python - сажают на Java. Смотришь вакансии - везде зоопарк технологий указан, из которого ты на текущем месте задействуешь 1-2 шт. Ну буду делать задачи по минимуму и готовиться к другим собесам, окэй). Иначе сократят/не проиндексируют, а с голой жопой на рынке сидеть опасно (есть и где-то жить то хочется всем)
Надо терь юзать ИИ соискателям, потом работодателям контр ИИ, потом контр на контр-ИИ соискателям, потом работодателям как на экзаменах по ин. языкам задавать вопросы ТАК, чтобы ни ИИ ни носители не могли сдать на 3 т.к. не понимают, чего от них хотят (ну это уже щас и происходит)
Современные подходы требуют современных решений. Обесценивайте опыт соискателей дальше! Получите@распишитесь
недавно вышел на рынок(ETL/DWH) спустя несколько лет и чет ахуел от этих собесов, потом оказалось что уже недостаточно просто прийти и попиздеть с тим лидом как было лет 7 назад
Что-то у вас карма была отрицательная - наверно, некоторые из описываемых тимлидов себя узнали.
В маленьких компаниях не так, у нас работники ценятся. Меня, например, именно их опыт в первую очередь интересует: если человек более-менее успешно уже занимался всем тем, что нам нужно от него, то с высокой вероятностью и у нас сможет это делать.
Карма у меня отрицательная была по двум причинам: писал очень редко (мне ток недавно перестали каждые комменты модерировать) + во-вторых я как-то отписался под постом про падающую демографию базой из Антона Сорвачева (по-черно-юморному ессесна) - меня тут же местные заминусовали. Вопросы правового положения мужчин в обществе у нас подниматься не любят нынче. Ну да ладно.
Посты про мой рабочий опыт щас начали мне выравнивать карму.
Про компании: я был в двух мелких и в двух крупных.
В первой мелкой конторе всем принципиально мало платили. Это политика компании была. Я туда залез с голой Ж, набрался опыта, потом ее надо было сбрасывать срочно, т.к. ты сидишь на 50к, а на рынке тебе уже 120 платить готовы (~120к в этой конторе получали только директора, 2019 год шел). Ну там да, текучка была адовая, но пара спецов там всё-равно задерживалась (на таких мазохистах и демпинг рынка держится, мой им низкий поклон)
Во второй мелкой - в ИТ-консалтинге, я работал на проектах для крупных. Там было комфортно вполне себе. Приходилось работать конечно, но я только за, опыт набирал. Но там тоже спецы по деньгам звезд с неба не ловили. И у меня лично проблема начала ощущаться, что я работаю на R, который на рынке уже просто умер, денег в контору он не приносил (а я на кухне меряние внесенным баблом выслушивал регулярно). В то же время я чем только не занимался в зависимости от проекта (аналитика/бекенд/фронтенд/МЛ/девопс на докерах/в кубере как-то сервис поднял и т.д.)... Я просил меня уж куда-то определить во внятное место, а не совать меня на 3 разностековых проекта, и только не на R... И в итоге меня решили отправить на проект чисто на R, по мутной-ГПХ-схеме на 3+ месяца. Поднимать с нуля сервис. Я не захотел и нашел себе +50% DWH/ETL в текущий ПСБ.
Но вообще там да, комфортно было, в офис приезжаешь иногда, бухаете уже с 14 часов, атмосферненько.
Да, и еще там конфликт у меня был. Классный проект на МЛ и петухоне который я зарелизил - отдали следующий этап другому чуваку, а меня перетащили на другие проекты. Тот другой ничего кроме петухона не знал и был в возрасте. И вот он выкатил там новый модуль... Этот модуль написал без единого комментария и документации, и его концепт никак не коррелировал с запланированной мной дорожной картой для этого продукта. У меня были там большие надежды, думал выкатить классную штуку - а пришедший разраб всё похерил. Он при этом даже со мной не советовался, хотя я за ним сижу в офисе. Этот же разраб собирал на себя кучу негативных отзывов от других коллег. Сроки завалены. Как он планировал модуль выкатить в прод - непонятно (бекендеры и фронты при интеграции этого решения каждый перекур "угарали"). Что в итоге получилось - не понятно, но заказчику умудрились это продать всё-равно с болью. Дальше этот кластер модулей развивать уже не захотел заказчик. Я сгорел. Я вижу откровенного вредителя, и поднял вопрос о том, что он не компетентен, приложил скриншоты, пункты, аргументы... иии... Ничего. Жалко его было гендиру. Ну и я вместо того чтобы на этом хорошем проекте работать - был на проект на R отправлен опять (из всех возможных - единственный на котором я не хотел быть)... На том и ушел оттудава.
Щас в ПСБ тут 95% работают как тот чувак (особенно ДИБ), я поэтому абстрагировался, иначе никаких нервов не хватит. В Х5 когда я был - была та же фигня. Там где наш экспериментальный отдел в связке с ИТ-консалтингом выкатывал быстрые рабочие решения за 2 недели - департамент больших данных выкатывал тормозное решение за год. Если посмотреть на криворукость любых продуктов бигтеха то становится понятно, как там работают (никак)
Сейчас мною заказчики довольны, задачки подкидывают, я их по лайту сквозь ИБ и кучу процедур согласования по полгода клепаю - все счастливы, никакой токсичности, вайб пойман. Но опять таки - массовое сокращение, welcome to the circus (эта песенка отлично описывает происходящее щас на рынке, рекомендую)
Ну и в дополнение: денег столько, сколько я получаю даже сейчас (2 года, без индексации) - мне в прошлой конторе бы не платили, т.к. я и так по верху местной вилки получал. В мелких компаниях судя по всему денег так себе платят. И сейчас я ищу работу - мне мелкие конторы не пишут( Все крупные. Деньги там. В этих сраных бигтехах с их 100500 этапами.
Кажется, про R снова заговорили последние годы
Да он дрейфует в присмерти уже десятилетие, где-то там сям он всплывает но не более. В какой-то момент в аналитике сравнялся с питоном, где-то в районе 2014-2017, но и всё дальше. В РФ тот же Яндекс (обожаю эту контору епт) начал генерить вктатышей на Python на своих курсах, R вытравил, остальные за ним как песики побежали.
Сейчас вакансий на R нет, интервью по R нет, когда пытаешься внедрить проект на R - тебя встречают хлопая глазами по 5 рублей "а че не питон". Когда задвигаешь в резюме R на дно и говоришь что питонист - тебе уже начинают hr написывать сами активно.
Язык R я люблю очень. Лучшее что я видел на рынке за всё время. Господи я его люблю хотя бы за то, что он УМЕЕТ СЧИТАТЬ С ЕДИНИЦЫ ТВОЮ МАТЬ (я бы головы отрезал всем тем гениям которые взяли за моду поголовно в каждом ЯП считать с 0. Давайте мы сразу будем битовый код делать, 0-1-0-1, машинам же так удобнее?)
Векторизованность - это круто. Там где ты в питоне напишешь 10 строк кода - в R это будет одна. (я честно говоря глубоко про себя python презираю. Он не имеет скорости Java/C/Rust, но и не имеет емкости и удобства синтаксиса как в R, пандас после tibble/data.table это как на ладу с феррари переехать, годы прошли а ощущения те же. Polars уже получше, но без R-овских пайплайнов такое себе... Пайплайны... Аааааааа... Тоска накрыла. Свободы работы с environment-ами python не дает и близко такую, как R. В общем питон это просто какие-то сопли ни туда, ни сюда. Будто пишешь на джаве, те же циклы в каждую дырку по делу и без, но без тех же скоростей, без многопоточности из-за gil и пр)
Но в R нет денег. Меня добило, что RStudio переименовалось в Posit и распыляет деньги вместо развития языка R - на дублирование фреймворков типа Shiny на Python. Я сдался в этот момент. Ключевая поддерживающая язык контора уже под рынком прогнулась. А куда мне то?
А вот деньги мне нужны в первую очередь. Хаты по 20-50 млн стоят. И надоело в конторе на кухне слушать про то, что наш отдел не приносит бабки в компанию.
я бы головы отрезал всем тем гениям которые взяли за моду поголовно в каждом ЯП считать с 0
Но у этого же есть математическая подоплёка. Индексация с нуля это не мода, а удобство вычислений. Например, когда нужно разместить элементы с шагом N, то координата i-го элемента будет равна i*N, и таких задач очень много. Размещения, сортировки, группировки, выборки, там везде математика красиво сходится, если считать с нуля, и некрасиво, если с единицы.
Хаты по 20-50 млн стоят
Москва, видимо? Налог на пафос же :)
Но у этого же есть математическая подоплёка
В математике всё-таки считают с единицы...
И когда я хочу получить первый элемент но пишу arr[0], а второй arr[1] - мне это ОЧЕНЬ режет глаза.
Хитрые алго-кейсы типа i*N встречаются сильно реже в практике, чем когда просто пытаешься обратиться к элементу, я бы тут смело +1 писал подчеркивая особенность ситуации и был бы счастлив.
Я активно пользовался языками построенными на обоих вариантах, годы практики, и мне всё-таки ближе счет с 1, хотя помню такое только в R. То, что какую-то логику можно подкрутить под любое решение - это понятно.
А так, педалировать дальше тему счета с единицы не вижу хочется, я готов остановиться на "вкусовщине", субъективщине и прочих "общечеловеческих" тормозах))
Урррааа, минусовать начали!))0 А то я уже переживать начал...
Ахаха, работаю последний год в банке (не Т, не Сбер), как же все знакомо))) Ненапряжность после работы в айти-компаниях, включая интеграторов, даже пугала первое время. Все очень неспешно. Но премии платят регулярно, с деньгами пока проблем нет. Пенсионерская такая работа)
О да, прошлая работа у меня была ИТ-консалтинг, а щас у меня масса коллег предпенсионного возраста тут, разговоры про дачку, рассаду... эх. Яблоки с дачи дарят, ибо их пихать некуда, мешки насобирали у себя там. Но им зп не индексируют, получают они меньше новопришедших (хотя у ряда из них лычка на 2 грейда покруче), это важно и надо иметь ввиду.
Сокращение щас тоже вяло идет, сперва испугались, но щас я так понимаю процесс будет идти до конца года, так что я ищу работу относительно спокойно, неспеша и вертя носом.
Ооо, прям накатило - etl в большом вендоре, мы в галере на оутсорсе. 3 месяца переговоров в стиле а я вот тут поправила 2 строчки в extract скрипте на pandas, перенесите в глю пожалста :)
Интересное описание ситуации, спасибо, что поделился.
"Скорость, качество, самостоятельность" - хороший старт, но собеседующий, скорее всего, ждал структурированного подхода к оценке эффективности команды: по каким наблюдаемым признакам ты как лидер понимаешь, что команда действительно работает хорошо, а не просто выглядит занятой.
Я в таких случаях ориентируюсь на 7-8 параметров, каждый из которых можно подкрепить конкретными метриками:
Прогнозируемость
Оцениваю, насколько команда укладывается в план:
% выполненных целей спринта
Стабильность Velocity за последние N спринтов (график без сильных колебаний)
Доля «перетаскиваемых» задач между спринтами
Скорость доставки (TTM)
Как быстро команда превращает задачу в результат:
средний / максимальный Time to Market (от «Ready (DoR)» до релиза (DoD))
Lead Time for Changes (по данным CI/CD)
% задач, завершённых менее чем за X дней
Качество
Насколько надёжно работает продукт:
Bug rate по окружениям (staging, production)
% багов, найденных на этапах ревью/тестирования
Time To Detect / Time To Resolve (инциденты в проде)
Кол-во замечаний на код-ревью по критичным категориям
Инициативность и вовлечённость
Проактивность команды:
Кол-во технических улучшений, предложенных и реализованных в квартал
Кол-во pull-запросов, инициированных без внешнего запроса
Участие в RFC / архитектурных обсуждениях
Обратная связь от стейкхолдеров
Удовлетворённость бизнес- и внешних команд:
Кол-во эскалаций/жалоб от продактов
Прямые отзывы с ретро / 360 обзоров
Индикаторы доверия: самостоятельная передача новых фич команде без лишнего контроля
Коммуникация и доверие
Насколько команда зрелая внутри:
Ретроспектива: уровень доверия по 10-бальной шкале
Число нерешённых конфликтов
Частота/эффективность внутренних sync’ов без фасилитации снаружи
Автономность и управление блокерами
Способность доводить фичи без внешней помощи:
Кол-во внешних зависимостей для завершения задач
% задач, где потребовалась эскалация
Среднее время от выявления блокера до эскалации
Влияние внешних зависимостей
Блокируют ли другие команды результат:
% фич, завязанных на чужие API или команды
Среднее время ожидания разблокировки
Наличие альтернативных путей (фаулбэки, изоляция, контракты)
Вот для чего разрабу или тимлиду знать system design? Вроде как, это зона ответственности архитектора, который в определённые моменты сходит за консультацией к базистам и сетевикам. Бизнес рисует и планирует, а реальность диктует другое, причём чуть ли не сразу. Наверное, самый главный и первый вопрос в system design должен быть: А сколько денег Вы готовы потратить? А то на бумажке можно рисовать любые замки, но когда денег хватает только на сарай, нет смысла тратить время на обсуждения постройки дворцов.
Для кругозора. На мой взгляд настоящий профессионал в разработке должен понимать и сопредельные области - system design, архитектура, системный анализ, БД, сети, тестирование, быть немного девопсом и т.д. Не прямо все сразу и не во всех деталях, конечно. А вообще мозг это мускул, его тоже тренировать надо.
Для кругозора и сопредельных областей, можно попросить тогда ещё собеседуемого спаять что-нибудь или спроектировать цод с расчётом эпюров и коммуникаций под то решение что получилось в system design. Проблема system design в том, что это разговоры об абстрактном и там нет правильного ответа, зато очень легко подзавалить собеседуемого и прогнуть под меньшие деньги. К примеру, в system design будет разговор за георезервирование, чтобы был низкий пинг для пользователя и меньше данных гонять через полсвета, а в реальности будешь делать это резервирование, потому что того требуют власти: США, Европы, России и тд. При проектировании системы, архитектор может не один месяц бегать по базистам, сетевикам, ибешникам, консультироваться с коллегами по цеху и в конце защищать свое решение на арх. совете. И тут system design - разговоры об абстрактном на 1-2 часа.
К пуговицам претензии есть?
Систем дизайн применим не только когда надо запилить новый инстаграм. Есть куча текущих задач, требующих знаний паттернов проектирования. Банальный outbox может потребоваться в рамках имплементации довольно простенькой фичи, к проектированию которой бессмысленно привлекать архитектора.
Спасибо, весьма познавательно.
Магнит с Адонетом позабавил, конечно.
Ахах, Озон. Приходила ко мне рекрутерша из озона. Немного оо себе:. Net-чик, стаж более 10 лет, как в аутсорсе так и в продуктовых компаниях. Живу в Черногории. Сначала вроде бы все было хорошо, первый созвон, поговорили об опыте. Но потом выяснилось несколько... "незначительных" деталей и уточнений, а именно:
Оформление через Казахстан (ок в целом), но нужно прилететь лично. Я то не против, но вот оплачивать такое путешествие, оформление рвп, ИНН, банковского счета и прочих бюрократический радостей жизни я должен за свой счет
"К сожалению, у компании нет возможности сейчас выдать вам технику, поэтому работать придётся на своей." При этом свой ноутбук нужно отдать на поругание их СБ чтобы они полностью его форматнули и накатили свой образ 10ки (потому что 11й у них нет и по барабану, что для твоего девайса под 10 может и дров не быть). Ага, ага, побежал покупать себе отдельный ноут за 2к евро с гаком, чтобы превратить его в корпоративный кирпич.
И все за баснословные 320тр/месяц ДО налогов. Нет, зарплата даже в тенге не полагается. Только в рублях по курсу.
Итого на то, чтобы только устроится работать в эту замечательную контору мне предложили потратить ~4000 евро своих денег и этак три недели своей жизни. Даже и не знаю, почему я отказался от столь щедрого предложения...
Чего-то выглядит как экономия на спичках, конечно.. Даже оставляя зп за скобками.
Правда не исключаю что они нарывались на людей исчезающих в закат с ноутбуками после (или даже до) первого дня работы и таким образом себя страхуют. :))
Так себе страховка. Корпоративный ноут нынче зверь такой, что кроме работы ни для чего не пригоден. Диски зашифрованы, биос аппаратно залочен и хрен ты чего с этим сделаешь. К тому же, вот уж даром мне нужно это приключение - ехать в Казахстан и тратить несколько недель на всю бюрократию ради одного ноута, будь это даже супер новый мак м4. Моё время и нервы точно стоят дороже.
А великолепные продукты, написанные командами разработчиков с таким уровнем понимания (и с окладами 300+..500-, но это не столь важно) с нами в одной комнате?
На окладе 300-500 очень часто задачи — чистить Авгиевы конюшни, про которые писать-то стыдно.
Сам разгребаю сорокалетнее легаси, написанное реднеками-шизофрениками, за верх этой вилки.
Была крч одна утилита, которая загружала очень слабые клиентские машины под 0 тем, что сперва САМА выполняла балансировку между серверами кафки (накатка обновлений на машины - месяцы), потом делала дорогостоящий TCP-коннект к кафке (у нее ж нет http-интерфейса, но кого это волнует, ставим, в резюме кафка круто смотрится ж)...
Система построенная на данных с этой утилиты постоянно валилась, имела кучу жалоб, и т.д. и т.п.
Эту утилиту написал корп. архитектор (у них хорошие оклады, и под 800 доходят) который настолько этой утилитой гордился, что ажна назвал ее в честь своей фамилии
Аминь
Жаль не могу найти - однажды давно попалось видео типа реального собеса на ютубе в тинькоф. Там был какой-то тип (со стороны тинькова), стриженный под машинку, который матерился в эфире. Оставило неизгладимое впечатление.
Но меня порадовало, что есть компании, которые стараются различать тим-лида и тех-лида. Относительно недавно была статья от сотрудника Альфа-Банка, по которой можно было сделать вывод, что там эти роли объединены.
Спасибо за уроки по Garry's mod, именно с них 15 лет назад начался мой путь в IT
Собеседовался в Банк год или два назад, но не в разработку. Осталось негативное впечатление, так как не смогли найти общего языка с интервьюером, но это полбеды. У меня просто другая корпоративная реальность , которая не пересекалась с реальностью Т-Банка. Убил второй интервьюер, который сидел час на собесе и всем своим видом (собеседование было с камерой) показывал то ли ему неприятен я как кандидат, то ли ему вообще тут неприятно находиться и лучше бы он сейчас пил тот самый лавандовый раф. Так как я очень хотел на тот момент в Т-Банк, я никак это не прокомментировал, но иной раз на подобных собеседованиях (благо это были единичные случаи) говорил сразу, так как неприятно наблюдать незаинтересованного интервьюера.
Чаще всего, как бы ты ни прошел собеседование, оффера не будет.
Ну, может, это у него лицо такое) У разных людей разное понимание нормальности. С чем-то можно смириться, с чем-то нет.
У меня был опыт технического интервью, где инженер сидел в труселях. Не, не явно, но иногда было видно, когда он крутился на кресле.
Было интервью, где руководитель забыл прийти, его выцепили, видимо, в кафешке на обеде. Мало того, что он подключился без камеры, задавал вопросы невпопад и явно с потолка, так еще и ел, судя по звуку. Этот этап я прошел, но дальше уже не пошел, т.к. для меня это звоночек, что будет такое же отношение внутри компании.
и всем своим видом (собеседование было с камерой) показывал то ли ему неприятен я как кандидат, то ли ему вообще тут неприятно находиться
О, у меня тоже так было, правда, в другом банке. Сидел человек с очень недовольным лицом, задавал вопросы с таким же лицом. Потом, когда я вышла на работу, то из всего коллектива больше всех дружила именно с этим коллегой) Очень приятный человек оказался в жизни)
Понапридумывают слов всяких... Я самоучка - фрилансер (в основном в юнити) уже лет 15, ни одной книжки не читал, только документации 🤷 читаешь это все, и страшно даже пытаться в какую то контору писать.
Кстати, что такое эйчар и оффер? Ну, оффер - это что то с выключателем, наверное, связано, а эйчар?
Оффер - оферта. Эйч ар - кадровик
Просьба не путать эйчаров с кадровиками. И близко нет ничего похожего.
Отдел кадров, также известный как отдел по управлению персоналом или HR-отдел, - это подразделение в организации, которое занимается всеми вопросами, связанными с работой сотрудников. Он отвечает за подбор, наем, адаптацию, обучение, развитие, мотивацию, увольнение персонала, а также за ведение кадрового делопроизводства и соблюдение трудового законодательства.
Может быть в Вашем понимании HR - это аналог кадрового агенства, которое как раз ведет поиск сотрудников?
Эйчар относится к отделу кадров, так что формально это и есть кадровик, почему их стали так отдельно называть, потому что классический кадровик - это такая тётушка которая громкогласным голосом шлет всех приходящих к ней на три буквы и чтобы они не возвращались без правильно оформленных документов и вообще не требовали никаких справок и ходили в строго определенные часы с 13 до 13.10 по четным средам каждый второй месяц квартала.
у HR в данном случае выполняет ф-цию независимой связи работника и организации в отрыве от непосредственного руководства
грубо говоря если ваш начальник козёл, вы не можете пойти к его начальнику без нарушения субординации, вам надо идти к HR у которого есть обычно план действий на такой счет
обычный кадровик этим не занимается
"A" char т.е. символ с кодом 01000001 в ascii, или если начинающий то с маленькой буквы "a" char с кодом 01100001
Эйчар - HR. HR-менеджер («эйчар», сокращение от англ. human resources — кадровая служба) — это специалист по управлению персоналом.
Оффер (от англ. offer — предложение) — это коммерческое предложение для клиента, в котором описано, что предлагают, на каких условиях и почему именно сейчас это выгодно.
Вы же сами используете слова "юнити", а в комментариях у себя "шарпа". Что за шарпа, юнити? Это же тоже не русские слова, и даже не устоявшиеся англицизмы. Так что в чём проблема посмотреть эти слова в гугле?
Спасибо автору, очень подробно описал проблемы современного найма. На мой взгляд, это происходит из-за того, что процесс недостаточно автоматизирован в плане отсутствия мостиков между реальными задачами и собеседованиями.
ИИ должен будет решить эту проблему через сбор профиля сотрудника и подготовку материалов для собеседования.
Таким вижу будущее проекта "Граф Компетенций"
Собесился в 2GIS весной на Senior девопса. Стандартно было интервью с HR, одно интервью с командой, техническое и финальное, с руководителями и HR. На техническом прям долго мучали по докеру. Вот, наверно, половину времени от всего интервью. Спрашивали много про слои, кэширование. Стандартно Линукс, кубер. Спросили про опыт в Ansible, мониторинг. Сказал, что работал, знаком, но работаю далеко не каждый день, делаю время от времени разные точечные задачи. Интервьюер задал пару вопросов, сказал, ну, ок.
По итогу делают оффер, говорят, мол, ну у вас нет Ansible и мониторинга, поэтому вы до синьора не дотягиваете, мол, мидл+ в нашей градации. Поэтому делаем вам оффер процентов на 10 ниже, чем просил изначально, но так и быть, через полгода на перформанс ревью можно будет обсудить повышение зарплаты.
Взял денек подумать. Решил для себя, что это так себе звоночек и где гарантии, что на перформанс ревью мне снова не скажут, что ты вот чууууть-чуть снова не дотягиваешь? Видел такую ситуацию на одной из работ, когда у ребят крутили морковкой перед носом, но повышения не было. В итоге, отказался. Сказал, что между "нет знаний вообще" и "не использовал каждый день" есть большая разница. Когда отказался, пообещали поговорить с командой, пересмотреть сумму, но решение уже было принято.
По интервью вопросов нет, все понравилось, но вот момент с попыткой срезать денег - не очень.
Что бы вы выбрали с учётом всех вводных? Представьте, что вам предложили в Т-Банке 1.2X-1.25X.
При выборе между "Тбанк" и "любой другой компанией" я бы выбрал любую другую компанию.
2ГИС классный сервис, сам им пользуюсь, ещё с 2000х годов когда он только появился. Да, сейчас актуальность сильно подрастерялась от поисковиков, но всё равно в ряде случаев крайне полезная штука при ориентировании в ТЦ и поиске входа.
Собеседовался во многие перечисленные тут компании на тимлидские позиции, в некоторые и не один раз. В частности в Магнит (оффер), в Озон (оффер), в Т-Банк (оффер), в 2ГИС (отказ), в МТС (отказ), в Яндекс (много-много раз, были и офферы и отказы), в Mindbox (отказ).
Хочется сказать что в комментариях и в статье есть одна когнитивная ошибка - обобщение, представление компании в виде некоего монолитного супер-разума. Что опыт одного трека собеседований можно переложить и экстраполировать. Это безусловно так, но лишь отчасти. Можно примерно понять как принято собеседовать, но это лишь поможет не совершать очевидных ошибок. Но не защитит больше ни от чего. Ни от произвола интервьюера, ни от перекосов.
А перекосы эти идут из самой природы корпоративных практик. Довольно часто в компаниях приняты некие "практики". Но они приняты наверху "кем-то", и "навязаны" вниз. Они могут быть составлены "умными" людьми, по их собственным субъективным мнениям о том или ином грейде, или роли, которые могут не совпадать ни с вашим мнением, ни даже с мнением того кто хотел бы взять вас в команду.
Например встречается практика нескольких интервью когда по технике собеседуют одни, по систем дизайну другие, потом идет фит с командой. На этом фите команда (ее тимлид на самом деле) прочитав неопределенного качества отзывы о предыдущих собеседованиях, и поговорив с вами полчаса (и полчаса рассказывая о себе) должны понять подходите вы им или нет. Это защищает компанию глобально от того что тимлид будет нанимать за красивые глаза, но в то же время подставляет тимлида под то что нанимать людей по очень очень короткому впечатлению. И тут люди ведут себя по разному. Кто-то предпочитает не рисковать и брать только при 120% уверенности (глаза красивые и голос бархатистый, и погода в этот день хорошая).
И что самое печальное - в результате таких практик в процессе интервью участвуют много людей которые не заинтересованы в найме (точнее он им безразличен). Им ничего не стоит поставить отказ или грейд ниже за мелкий недочет, просто из чувства душевного снобизма, и потому что не им потом с этим человеком работать. Они как бы "охраняют" компанию от плохих кандидатов, и в этом видят свою миссию.
К этому добавляется еще один слой сложности. Довольно часто внутри компании формируется какая-то подсознательная субкультура, которая может быть не выражена в каких-то формальных стандартах или регламентах. Какие-то мемы, предпочтения (как например отказ от ОРМ в Озон, который я люто поддерживаю и продвигал пока там работал). Такие факторы часто работают как система свой-чужой, и значат иногда больше чем формальные ответы на формальные вопросы из методички. Сразу видно кто "наш" а кто "какой-то не такой". А оправдание этому решению можно подогнать постфактум.
Получал отказ например потому что осторожно говорил что "мне лично Канбан нравится больше чем Скрам, хотя безусловно у того и другого есть плюсы и минусы, просто это мой личный опыт". Отказ был разумеется объяснен тем что ребята работают по Скраму. Хотя казалось бы - при чем тут это? Тимлид должен уметь работать с разными методологиями, адаптироваться к контексту команды и проекта. Но нет - не подошел по "культуре".
Ну и наконец, человеческий фактор никто не отменял. Бывает что те кто собеседует (этот конкретный индивид) совсем не хотят этим заниматься в данный момент, делают это не из любви к собеседованиям, и это отрывает их от важных задач. Но надо. Тут вступают в игру всякие когнитивные искажения когда задача повторенная миллион раз кажется очевидной даже самому тупому дебилу. А если именно вам она не встречалась, то значит вы сами знаете кто вы. А другой интервьюер будучи в ресурсе сделал бы всё по другому.
В итоге получается что любое собеседование - это лотерея. Слишком много переменных, слишком много субъективных факторов, слишком много людей которым до вас нет дела но которые могут поставить крест на вашем найме. Можно готовиться, можно изучать практики компании, но в конечном счете многое зависит от того на кого вы попадете, в каком они настроении, и насколько вы случайно попадете в их картину мира о том каким должен быть хороший кандидат. Не стоит воспринимать отказы как приговор своим навыкам - возможно просто не сложилось.
Собесился я как-то ради интереса в Авито в рамках weekend offer тоже с тем посылом, чтобы "переучиться на Go". На чём алго проходил не помню, кажется на Python, мне на нём проще алгоритмы писать, хотя основной язык у меня C#. И эту часть я прошёл довольно бодро. А завалился я уж прям разве что на system desing interview, которое проходил там первый раз в жизни. Опыт забавный, мне понравилось. Не понравилось только то, что не получил никакой обратной связи. После долгих пинков HR-а, мне сказали, что "все заняты более успешными кандидатами, прошедшими на weekend offer", в общем, я не успешный кандидат, зачем мне что-то отвечать, "неудачники нам не нужны", как говорится. ))
А я был готов переехать на Go. И на скрининг по Go очень хорошо ответил на мой взгляд, хотя даже таториал до конца ещё не прошёл. Прикольный язык, хотя и своеобразный.
Считайте, повезло ) Полностью согласен с автором статьи, что Go - уныл и по факту это второй похапэ, чуть апгрейженый. Впрочем, для некоторых задач оно подходит и работает на отлично. Что не делает необходимым его профессионально изучать и использовать.
Из личного опыта: знакомый позвал в компанию, которая набирала на Go. А я джавист и менять пока смысла не вижу... Но ради более высокой ЗП в потенциале, решил глянуть. Открыл их официальный туториал, почитал... Уже к дженерикам исплевался весь. Столько костылей я реально видел только в пыхе. Но там это простительно т к это "Hypertext Preprocessor " и это всё для чего изначально его создавали. C Go ситуация иная - его проектировал опытный человек и поддерживала это Google... И получилось то что получилось. В общем больше я к Go вернуться не смог.
его проектировал опытный человек и поддерживала это Google
Чтобы делать массовый дешёвый набор тушканчиков.
Так что Go программист может стоить больше чем Java/C# , а тем более Rust/Scala лишь кратковременно, года два максимум пока их не начнут также массово выкидывать с работы
Тут как посмотреть. Разброс зарплат в ИТ большой. Я знаю php-программиста, который вполне хорошо зарабатывал уже в тот момент, когда абсолютно всем было ясно, что серьезные проекты не надо начинать на php. Всегда есть организации с легаси и всегда есть "opionated guys" в организациях, которым нужен именно похапе/Го. Так что ЗП там будут как минимум на уровне (вспомним так же такие вещи как COBOL и FoxPro. Да, сейчас вакансий на такое мало, но ЗП там только выше) Что касается "тушканчиков", в общем то тоже, что и например, на python - порог входа одинаковый. Поэтому я считаю тут дело не в них.
Питонистам надо хорошо знать библиотеки, тысячи их. И сидеть в отладчике. То есть быть задротом. Мне такое не нравится.
Про отладчик это сарказм был ? Я отладчик со времен Дельфи и VB использую. Да, я знаю, что можно консолью отлаживаться, и умею это, но зачем ? это в 100 раз дольше.
Был у меня курьез с этим же знакомым пэхапистом - показал ему отладчик как то раз... Оказывалось - он был не в курсе что такое есть :) Сейчас естественно пользуется в случаях когда логика сложнее 2+2
Надёжнее логи писать. Отладка в многопоточном режиме - это боль, ненавижу её. Поэтому пишу всё в логи и таким образом понимаю, как всё работает, что происходит.
Нет, не сарказм
Когда ты описал бизнес логику в типах и сделал невозможными невалидные состояния тебе гораздо меньше надо тестировать, тем более в отладчике
Go - язык придуманный гуглом чтобы даже офисный работник, из языков программирования последний раз видевший в универе VBA, не облажался. Подходит для очень узкого круга задач и только для них. Почему именно в РФ его начали тащить вообще везде и пытаться сделать из него универсальный ЯП общего назначения, подобный C# или Java - вопрос не столько к архитекторам и менеджерам, сколько к санитарам той клиники, из которой эти самые менеджеры и архитекторы сбежали. Про уикенд-оффер я тоже как-то побаловался интереса ради. После скрининга получил приглашение на собес и настолько унылым он был, что хоть убей даже не вспомню, о чем был разговор. Но получил отказ, да и ладно. Не то, чтобы сильно хотелось.
вопрос не столько к архитекторам и менеджерам, сколько к санитарам той клиники, из которой эти самые менеджеры и архитекторы сбежали
Господи, сколько раз я задавался этими вопросами...
Go - язык придуманный чтобы люди перестали заваливать друг друга на собеседованиях вопросами типаКакой порядок инициализации статических блоков, если в классе есть статик-блок, статические поля и статические методы с сайд-эффектами?
илиЧто будет, если создать циклическую ссылку в del в Python и забыть про неё?
Чтобы перестали писать в продакшен коде остроумные однострочники типа [(lambda f: f(f))(lambda f: (lambda x: 1 if x == 0 else x * f(f)(x - 1)))(n) for n in range(5)]
а занялись делом.Перекладывали JSON в SQL и обратно
Ну я в целом о том и толкую - язык, созданный по-быстрому скидать crud-микросервис и забыть о нем. А никак не "серебрянная пуля" чтобы превратить вашу самотрансформирующуюся шаттл-субмарину с вертикальным взлетом легаси-экосистему в суперпроизводительную вундервафлю.
занялись делом.
Выписывали многоуровневые if err ==0... На каждый чих и шаг в сторону?
Go - язык придуманный чтобы люди перестали заваливать друг друга на собеседованиях вопросами
Не помогает, все равно заваливают: "можно ли в defer поменять возвращаемое значение" или любимый блок про append с реслайсингом. Задротство(пардон) оно всегда одинаково.
С Т1 была со мной любопытная ситуация
Я вышел на рынок, обновил резюме на ХХ.ру, были отклики, звонки, среди прочих был Т1 Иннотех, так кажется они обозначились. Звонит ЭйчАр и говорит:
- нас заинтересовало ваше резюме хотим вас собеседовать
-готов, говорю я
-перед собеседованием, по имеющемуся соглашению, мы должны предупредить вашего текущего работодателя что будем вас собеседовать.
Я конечно немного призадумался, такого в моей практике не было еще, но дал добро. Они действительно позвонили текущему работодателю и внесли ненужную смуту, а сами меня не то что не пригласили на собеседование, но даже больше не вышли на связь с ответом по причинам, по которым собеседование не состоялось.
Считаю это некрасиво.
пс. Все сказанное выше применительно к соисканию должности ОдинЭс Консультанта.
Гы, очень странная тема, может это и не Т1 вовсе, а услуга доносов текущим работадателям? :))
в Т1 очень странное СБ, проходил там собеседование, но Сб, кажется, не прошел (HR сказала что просто приостановили набор, ага), там была анткета на сотню полей, где я разве что анализы от врачей не прикладывал
А в чём смута? Ну захотел человек на собеседование сходить, в чём проблема? Люди приходят и уходят. Людей нанимают и увольняют. Отделы создают и закрывают. Вполне штатный процесс. Работа — это работа, а не жена.
-перед собеседованием, по имеющемуся соглашению, мы должны предупредить вашего текущего работодателя что будем вас собеседовать.
Это нарушение антимонопольного Закона, как минимум. Если они настолько тупые чтобы подписаться под таким то может и не стоит к ним идти
на будущее: пишите "левые" ФИО и названия компаний, где работали. Потом легко объясните это происками спамеров (они правда парсят резюме)
Ну и какой итог? 300к в наносекунду, ой в месяц 300 тысяч на руки получили? ) Вывод то какой по итогу всех собесов?
Но ведь весь блок "Финал", включая текст под спойлером — это вывод по итогу собесов.
Сейчас все детали работы под NDA обычно, включая зарплату. Коллегам то озвучивать зарплату нельзя, не то что на весь интернет )
Если NDA противоречит законам юрисдикции, то оно идет лесом юридически ничтожно.
Федеральный закон от 29.07.2004 N 98-ФЗ (ред. от 08.08.2024) "О коммерческой тайне":
Статья 5. Сведения, которые не могут составлять коммерческую тайну:
о численности, о составе работников, о системе оплаты труда, об условиях труда, в том числе об охране труда, о показателях производственного травматизма и профессиональной заболеваемости, и о наличии свободных рабочих мест;
Тем не менее, заработная плата может быть персональными данные работника (программист Олег у нас в компании Y зарабатывает 300 к₽/с), поэтому про коллегу рассказывать нельзя. Но можно сказать, что программист у нас в компании Y зарабатывает 300 к₽/с.
Ну, я так понимаю, это не "коммерческая тайна", а просто внутренние правила компании, с которыми ты соглашаешься, устраиваясь к ним на работу. Не знаю, насколько это законно.
Это профанация, которая конфликтует с законами, но подается под видом серьезной бумаги. Равно как документы на иностранных языках без перевода, запрет на трудоустройство к конкурентам после увольнения, какие-то конские прописанные штрафы и подобные финты, не предусмотренные ТК.
Запрет на трудоустройство к конкурентам, как правило, оформляется не в виде договора с сотрудником лично, а в виде "соглашения о неконкуренции и непереманивании сотрудников" с этим самым конкурентом (картельный сговор, ст. 178 УК РФ). За это по-идее ФАС должна сажать на бутылку, но в реалиях РФ всем как обычно.
нужно параллельно читать из кэша и из БД (если в кэше нет)
Разве это параллельно? Или я читаю как-то неправильно? Я просто всегда считал что параллельно, это когда мы в одном потоке читаем из кэша, а в другом потоке в это же время читаем из БД.
А тут вроде как - "Если в кэше нет, то читаем из БД" Разве это не последовательно?
А вы были бы отличным интервьером по нынешним стандартам! До столба так сказатб
А что не так? Разве в программировании не нужно следовать формальным требованиям?
Ох, ну ладно, мне для Вас ничего не жалко!
Перспектива 1: есть потребность в функционале чтения: из источника А и из источника Б. Оба? Оба! Есть условие - "в зависимости от" - из источника Б если не удалось из источника А
А теперь представьте человек пишет тираду на 100500 букв, хватается за мысль - "вот тут я реализовал функционал чтения из двух разных источников" - мозг выдал "параллельно" - окэй, побежали дальше дописывать 100500 букв.
Перспектива 2: Распределенные системы - это подвид множества концепций параллелизма (в ряде с SIMD, асинхронностью, суперскалярами, и пр). В распределенных aka параллельных системах реализовывают параллельное чтение данных. Можно через реплики, можно через шарды (сегменты? ноды? Терминологией какой БД пользуемся ща?), можно через redis-кеши, можно еще как-то на выбор. С точки зрения распределенной БД - чтения параллельные, распределены между этими n-нодами.
Но тут человек может в моменте думал с точки зрения БД о чтении, а не с точки зрения приложения.
Перспектива 3: а может человек пишет распределенный сервис, который будет развернут на n нодах, и этот "многосерверный сервис" будет параллельно читать из кеша и из БД?
Какая угодно может быть логика в мозгу в моменте. Я тут ничего критичного не вижу. Таким ходом можно почти каждое предложение мусолить.
А теперь я переведу этот конкретный кейс на общую картину (да, натяну сову на глобус). У меня лично цепляние к словам прям наболевшее. Я работаю с кучей ЯП, фреймворков и пр, там везде терминологические конфликты встречаются, как у автора с Heap (память/структура данных, например) - и прям снова ощущаю это чувство когда интервьер пытается из меня щипцами вытащить какую-то хрень СЛОВО В СЛОВО засевшую у именно у него и именно сейчас в голове и он недоумевает с того, что у меня в голове всплывает куча возможных трактовок и я пытаюсь составить некий опросник для него, чтобы понять, чего от меня хотят.
"Как же так?! Я же это спрашиваю по 100500 раз на дню! Незя не знать что я щас думаю, нельзя!"
Здесь слово "параллельно" используется не в строгом техническом смысле. Что-то типа "Я параллельно убираю на кухне и готовлю обед", при этом я вряд ли одной рукой убираю и в этот же момент другой рукой мешаю суп. Просто эти два процесса перемешаны во времени на большой длительности.
Но на реальном собесе интервьюеры в том числе попросили меня написать версию, где да, чтение буквально идёт всегда из обоих источников, и отдается то, что завершилось быстрее.
И далее он пару минут рассказывает, почему SQL-запросы лучше, чем ORM
О! Я согласен с Магнитом! Я уже 10 лет как ни в одном из проектов не использую ORM-ы.
Большое спасибо за обзор) Оч интересно было читать)
После твоего рассказа чувствую себя тупеньким)
А LeetCode нигде не смотрели? Есть вообще смысл там задачи решать?
Мне показалось или среди
Лидера организатора
Архитектора
Опытного
Зубрилы задрота
почти везде выбирали последнего?
Ну и цирк. Меня больше всего забавляет, что среди собеседующих каждый первый - эксперт по всем вопросам, который всё знает и всё умеет, от кандидата требует держать в голове информацию обо всех инструментах во всех сферах, хоть как-то связанных с разработкой, причём по состоянию не раньше, чем на вчера, но это никак не отражается ни на качестве продуктов в плане стабильности и скорости работы, ни на качестве библиотек, которые попадают в опенсорс (привет, бэм-стек!), ни на качестве внутренней архитектуры, которая, впрочем, в любой конторе не является примером для подражания, ни на зарплатах, которые при таком отборе и такой нагрузке, как предлагается в топах, должы быть раза в полтора выше, ни на знаниях бывших сотрудников, которые приходили когда-либо ко мне на собес.
Проще курьером пойти работать, чем в этом цирке участвовать, честное слово. И для кукухи полезнее, и хоть какая-то физическая активность после десятилетий оквадрачивания жопы об стул.
Задрота ищут
Я и говорю
Не, не так. Я на своем веку могу перечислить реальных задротов по пальцам. Это те самые шизоиды которые могут в соло за недельку наклепать сервис который потом будет кормить целый отдел в бигтехе (не преувеличиваю).
Эти задроты годами по собесам ходят (пусть и не активно), и выстреливает раз в 5+ лет по случайности (вредители находят всё сильно быстрее и получают больше, опять таки примеров массу знаю откровенных "альтернативно одаренных" на хороших позициях)
Тут ищут не задротов. Тут просто цирк. Ради цирка. Как у Пелевина - кровососы упивающиеся страданиями.
Бабло имущие просто деньги швыряют в карго-культы. Это ж ИТ.
А с кого собственно спрашивать? С того, кто снимает город чтобы подписать каббальный брачный контракт с 55-летней страшной бабкой (при том, что бывшая залетела в топ форбса чисто разводом не работав и не неся никаких рисков первого лица топ-компании)? С тех, кто тратит лярды на меряние длиной яхт? Или тех, кто спускает на золотые унитазы в 55ом пентхаусе в мертвой дубайской пустыне? За бюджеты то решения они принимают.
Особую перчинку в эту историю подбрасывают местные мазохисты которые на щщах утверждают что разрабы лям рублей не заслужили (а кто заслужил?) имея рынок недвиги с ценниками под 50-100 млн просто за обычные неплохие квартирки 2-3 комнаты в обычном хорошем районе хорошего мегаполиса. О чем мы вообще говорим тут...
Особую перчинку в эту историю подбрасывают местные мазохисты которые на щщах утверждают что разрабы лям рублей не заслужили (а кто заслужил?) имея рынок недвиги с ценниками под 50-100 млн просто за обычные неплохие квартирки 2-3 комнаты в обычном хорошем районе хорошего мегаполиса. О чем мы вообще говорим тут...
этот абзац особенно доставил! спасибо!
По этому поводу чего сказать - верхний перцентиль недвиги все же будет базово доступен только для руководящих должностей, а тут обсуждаются линейный персонал. В Калифорнии же то же самое, примерно, как зп в IT выросли также выросло и жилье и в итоге все равно верхний срез простым айтишникам из ФААНГа не доступно, к сожалению, как и у нас.
В Калифорнии же то же самое, примерно
в отличии от РФ, в США совершенно не обязательно жить непременно в Калифорнии чтобы за окном оставалась цивилизация, а когда я мониторил цены на дома, они вполне доступны айтишникам...правда если тут начать обсуждать это всё скатится в спор что дом должен быть пренепременно кирпичным большим и теплым (как в РФ строят обычно) без учета того что в США далеко не везде -20 зимой
Ну я намеренно говорю о топовых центрах притяжения. Цены выше тоже для Москвы взяты скорее всего. В регионах - миллионниках, а там жизнь и "цивилизация" вполне тоже есть (вот недавно был в Нижнем, например- очень понравилось все), можно за 10-15 приличную квартиру взять, при этом удаленно работая на столицу, что уже не кажется таким недоступным
В России ОЧЕНЬ много строят каркасников, так что тезис об "обычном большом кирпичном доме" выглядит сомнительным.
Я не считаю США/Канаду мерилом чего-то качественного хотя бы чуть-чуть. Я реально думал туда поехать (есть рабочая виза в канаду), много рекламы, но после нормального изучения вопроса, ты натыкаешься на то, что там откровенный ад:
Дорогая и недоступная медицина (тонна куллсторей и пруфов)
Автомобилизм головного мозга (для меня минус, я не хочу связываться с авто)
Дорогая недвига
Годовые собесы в FAANG-и
Уволить могут одним днем
Адские переработки - это норма
Отпуска и прочая - нет
Наркоманы и шумные шизики повсюду (то что в калифорнии/ванкувере творится - в Москве и близко не снится)
низкие пищевые стандарты, Whole Foods (или как оно там пишется) будет как минимум дорого
Английский язык (он ужасен, соре. Я отзанимавшись с репетитором 2 года пытаюсь посмотреть Х-files без субтитров, я вместо речи от Скалли (или как там) ее слышу змеиное шипение. Ужасный язык всем от и до, изучаешь его и 10 раз за час плеваться будешь отсутствием логики у ВСЕГО в нем)
ЛУЧШЕЕ предложение в канаде что я увидел на линкдн - 200к кадов в год ДО налогов спустя год собесов в амазон, недвига стоит 2-3 млн КАД-ов. Как на это накопить? Ответом служат вереницы домов на колесах в калифорнии
Северная Америка - это просто адовый трудовой лагерь. Приезжать и обеспечивать своей кровью там велферы неграм ("меня в школе учили что в Африке негры") - это да.
факторы довольно субъективны, потому что и отпуска бывает и переработки не всегда, недвига сопоставима по ценам с Российской (подчеркну, нельзя сравнивать сами дома с российскими при этом)..я когда почти намылил лыжи туда в начале 22 года, вполне рассматривал домики в пригороде NY и по ценам они были сопоставимы с моим домом в подмосковье, с ипотекой конечно. разве что они были не кирпичные
наезд на английский вообще странный...да он для русскоязычного сложен, особенно американский (по этому нельзя учить английский-английский, иначе реально будет шипение).. а вот логики нет как раз в кириллических языках если их сравнивать с английским, мы просто привыкли
Ответом служат вереницы домов на колесах в калифорнии
это не ответ, у нас вереницы человейников за МКАДом выполняют эту роль, был бы у нас такойже климат как там, у нас тоже бы люди так жили...посмотрите на дома в тысячах СНТ, где люди живут на птичьих правах (там до сих пор через суд надо постоянную регистрацию делать?)
По теме английского языка:
Там всё очень плохо, при этом я понимаю, что ввиду распространенности этого языкового уродца в мире - мне противостоять аргументу "миллионы мух не могут ошибаться" - очень сложно. Я кину основные детальные аргументы, а там уж дальше каждый при своем мнении и останется, но мб чето в голове отложится
Фразовые глаголы: They brought the matter up at the meeting yesterday. В середину фразового глагола (turned down) впихиваются другие слова. Давайте по русски так начну говорить "они по этот вопрос дняли на встрече вчера". Я причастные/деепричастные обороты то считаю антипаттерном языком и сам стараюсь ими пользоваться пореже, т.к. когда описывая мысль А ты встаешь по середине мысль Б, а потом продолжаешь описывать А - это прям сильно сбивает с толку и снижает градус взаимопонимания
Вышеприведенная шиза порождает следствия, например "индусский английский". Тебе пограничник говорит "Cagan!". Ты переспрашиваешь 5 раз - он это повторяет 5 раз. После детального выяснения оказывается что он просто обрезал конец первого слова и начало второго, имелось ввиду Come Again. Так же есть в пример PAW please который подразумевает Pay Now и т.д. и т.п.
Я был в Армении и общался с кассиром которая выучила русские слова за пару недель до (ввиду поехала релокантов). Я будто с обычным русским человеком общаюсь, всё четко ясно и понятно. Нет такого, что я поеду общаться в Москве, Ереване или во Владивостоке - и будут разные акценты. Невинные шаурма/шаверма это ничто относительно разности диалектов между East/West Sides одного города в Штатах или тех же районов города Лондона (те же кокни и т.п.)
Про то, что поголовно написание слов не соответствует произношению - надо рот открывать?
Though, tough, through, thought, thorough, queue, etcВзять например
would- форморобразующее слово, https://enginform.com/article/9-sluchaev-ispolzovaniya-modalnogo-glagola-would созвучное с "дерево" используется в 9 разных вариантах, о котором можно догадаться из некого "контекста" (мне в 50% случаев на любой вопрос о том, что может иметься ввиду этим словой/фразой репетитор как мантру повторял "зависит от контекста, контекста, контекста...")Звук th - для людей без передних зубов. Смотришь сериалы - порой останавливаешь момент, а там актер как змея язык высовывает наружу будто плюется...
Точность: "Я буду читать книгу" и "Я прочитаю книгу" — оба предложения говорят о будущем времени, но первое указывает на процесс, а второе на завершённое действие. В английском это будет просто "I will read the book", что требует дополнительных разъяснений для такой точности. Русский: "Подошел к окну и увидел свет" (мужской род) или "Подошла к окну и увидела свет" (женский род). Английский: "Came to the window and saw the light" — без указания местоимений нельзя определить, кто это был: мужчина или женщина.
Мертворожденные времена. I had arrived home и i arrived home - оба переводятся как "я приехал(а) домой". При этом не понятно, в чем была проблема просто использовать понятный just now? Нет, завезли наркоманскую had конструкцию, умники, очень удобно (нет)
Бестолковые 3и формы для ~100 популярных слов, типа buy/bought (buyed - язык же сломается да?). ЗАЧЕМ?! УБЕРИТЕ
Синонимы - эвривере они. Дайте мне адвоката! Загуглите как переводится attorney - и адвокат и прокурор. В газетах просто пишут "attorney" - и как хочешь понимай.
Дайте мне ВОДЫ! https://www.youtube.com/shorts/KNMdazuvDcU (5 вариантов произношения воды перечислил автор ролика, но вообще их там без конца куча: уа, ва, ува, вате, уате, ваэр и т.д.).
Идиомы, идиомы, идиомы - тысячи их, без конца, все что нельзя выразить понятными словами из-за непонятных конструкций и 100500 языковых исключений затыкается костылями в виде бесчисленных идиом, которых в сотни раз больше чем в русском
Ну и статистика@факты:
https://ru.wikipedia.org/wiki/Реформа_английской_орфографии
Дети, говорящие на языках с более фонетической орфографией (например испанском, итальянском, чешском или немецком), достигают уровня англоязычных детей, учившихся читать 2,5 года, за один год
https://www.scientificamerican.com/article/two-thirds-of-american-kids-cant-read-fluently/
64% восьмиклассников в США либо совсем не умеют читать, либо с трудом складывают буквы в слова. Теперь вопросы образования будут решать штаты без вмешательства федеральных властей.
https://dzen.ru/a/YNGQ5UG_fH365Nap
Одна из очевидных проблем в том, что русский язык звонкий, громкий и четкий, а английский – более приглушенный, мягкий и шипящий.
https://martin.kleppmann.com/2014/11/25/hermitage-testing-the-i-in-acid.html
Если мы хотим надеяться на рассуждения о безопасности параллелизма, нам сначала нужно понять, какие именно гарантии предоставляют и не предоставляют существующие базы данных. Нам нужно выразить эти гарантии в терминах точно определенных, проверяемых свойств (а не неопределенных предложений на английском языке в документации)
Обращение к издательствам: пожалуйста, ПЕРЕВОДИТЕ термины - https://habr.com/ru/articles/771628/
– Ну подумаешь, – скажет воображаемый собеседник, – нашёл один неудачный термин. > Но так-то, [[ENGLISH (Английский язык)|английский язык]] – образец точности формулировок и технической строгости!Да в том-то и дело, что сам по себе язык – не образец. Наличие множества независимых компаний-производителей, развивающих собственные платформы, с одной стороны – благо, но с другой – не очень. Потому что сначала компания пишет код, а потом придумывает название, не давая себе труда посмотреть, была ли идея реализована раньше, и нет ли у неё готового названия.
Русский язык и близко не считаю эталоном. Однако:
Язык то не международный, у нас такой только англ по миру. Максимум региональный.
У него хотя бы как пишется так и слышится в 95-99% случаев.
А так то вообще давно пора делать и массово глобально переезжать на нормальный синтетический язык который должен быть под внятной релизной политикой (например пакеты изменений существующих слов и концептов не чаще раза в 10 лет)
Офигеть, вот это разнос. В историю!
ух как, и реальные придирки и сравнения с русским с попытками сказать что наше произношение очевидно же лучше потому что мы же говорим во как четко ;)
не то чтобы есть смысл оппонировать к субъективизму но всетаки отмечу чуть чуть
Про то, что поголовно написание слов не соответствует произношению - надо рот открывать?
Though, tough, through, thought, thorough, queue, etc
полно языков с такими "косяками", русский кстати тоже...все эти жи-ши, ча-ща и т.п. это попытка научить детей правильно произносить слова которые пишутся не так как звучат... пресловутая ё которую массово игнорят, дощь-дождь - скажете что это диалект? а вот представте что диалект стал основным типом языка - американский английский это диалект английского - он стал шипящим и мягким, это просто история развития
чтобы понять как это работает - почитайте дореволюционные книги на русском, там от словооборотов мозг сломать можно
созвучное с "дерево" используется в 9 разных вариантах, о котором можно догадаться из некого "контекста" (мне в 50% случаев на любой вопрос о том, что может иметься ввиду этим словой/фразой репетитор как мантру повторял "зависит от контекста, контекста, контекста...")
опять же в русском полно такого
вы вот не замечаете, но например вот слова
"вошёл, вышел, подошёл, отошёл" - для нас это одно слово, для человека некириллического это 4 совершенно разных слова которые надо произносить так в зависимости от контекста который совершенно не очевиден относительно слова
есть прям совсем классика
"Чашка стоит на столе", "вилка лежит на столе" - в чем разница? в интернете полно смехуечков на эту тему и единой системы как это применять кроме как железобетонно заученных шаблонов в детстве типа "птичка на столе сидит, а кошка рядом - стоит, и чучело из птички стоит - хотя чучело в совершенно томже положении находится как и живая птичка" - опишите понятную формулировку чтобы вы совершенно рандомное слово на русском сразу сказать правильно?
Звук th - для людей без передних зубов. Смотришь сериалы - порой останавливаешь момент, а там актер как змея язык высовывает наружу будто плюется...
а этож совсем просто, (аргументация с плевками...кринж просто), вы помните как в детстве учили букву Р, Ш, Щ и насколько это сложно? так вот в английском языке (и вообще подавляющем числе язков мира - нет звука Р потому что это тупо сложно и нафиг не надо, по этому существует звук th который легко произносить детям сразу
а вообще есть в Африке языке где есть звуки который ни вы ни я ни англичанин никогда не воспроизведут если не выросли там, давайте насмехатся над ними, какие они отсталые да?
без указания местоимений нельзя определить, кто это был: мужчина или женщина.
потому что вы привыкли жить в мире точного указания пола человека..вопрос тут скорее в том почему так получилось и зачем это нужно
возьмите испанский например, там есть останки обращения к обычному простолюдину и к уважаемому господину (ustedes) ... в русском это слово "Вы" ..а в английском такого аналога нет и используется уже доп слово Sir и вариации и т.п. представляете, они друг друга не уважают!
Бестолковые 3и формы для ~100 популярных слов, типа buy/bought (buyed - язык же сломается да?). ЗАЧЕМ?! УБЕРИТЕ
в русском языке у каждого слова есть 100500 вариаций, у нас словообразование построено на приставках-суффиксах-окончаниях - у них это всегда отдельные слова, логика меняется служебными
то что они разные - это историческое наследие, и то что английский это помесь немецкого языка с отдаленным запахом латыни
идиом которых в сотни раз больше чем в русском
их не в сотни раз больше, вы это замечаете потому что просто учите напрямую, также английский более распространен и на него сильно влияет это
Русский, современный русский язык, очень многое в себя вобрал из Испанского, Французского и Латыни, вы это примечаете или думаете что многие наши идиомы и выражения самые правильные и верные? огромное количество привычных нам слов и выражений растут из Испании-Франции, просто мы к ним привыкли
У него хотя бы как пишется так и слышится в 95-99% случаев.
ну нет же, посмотрите какие ошибки делают дети в 1 классе, ребенок не может буквально ни одного слова написать на слух без ошибок
"Мая мама сделала пирок и щас панисет ево к нам штобы паесть" - совершенно типичная история с написанием-произношением
А так то вообще давно пора делать и массово глобально переезжать на нормальный синтетический язык который должен быть под внятной релизной политикой
только вы никого не заставите на него переехать
вон был эсперанто...кому он нужен?
аргументация с плевками...кринж просто
Пожалуй, остановлюсь только на этом
"вошёл, вышел, подошёл, отошёл" - для нас это одно слово, для человека некириллического это 4 совершенно разных слова
А тут я уже совсем сломался. Я человек "кириллический" и я вижу 4 разных слова...
Я не сильно филолог и придумал сходу эти примеры
Вообще по значению это одно слово где один и тот же корень , также как в английском его аналог come
Кстати именно по этому come - неправильный глагол который черти как пишется в разных временах по неочевидным причинам..в русском точно такие же фокусы есть
У него хотя бы как пишется так и слышится в 95-99% случаев
Не смешно. У меня дочка учится писать, пишет как слышит. Даже близко нет этого вашего "как слышится так и пишется". Условно в любом незнакомом слове половина букв написано не так, и понятно почему. Потом, конечно, запоминает.
К синтетическим языкам не испытываю ничего кроме недоумения. Взять тот же эсперанто. Арабам, китайцам, индусам бесконечно далёк, поскольку проектировался под носителей языка из центральной европы. Но и для европейцев тоже непонятно зачем. Тот же испанский или английский намного богаче, контента на много порядков больше, да и полезней с точки зрения общения
Though, tough, through, thought, thorough, queue и т.д.
Передают вашей дочке привет)
https://ru.wikipedia.org/wiki/Реформа_английской_орфографииДети, говорящие на языках с более фонетической орфографией (например испанском, итальянском, чешском или немецком), достигают уровня англоязычных детей, учившихся читать 2,5 года, за один год
Ну и статистика тоже)
Ну и по поводу искусственного языка
1) Когда-то французский по миру ходил. До этого латынь римлян. И ничего - переехали, щас вот пересели на англ. Живем
2) Искусственный язык базировать на латинице - это логично. Исторически языки основанные на латинице самые распространенные по миру, и те же Китайцы каждый день англ буквы видят. Зачем велосипед изобретать, если уже есть с чем работать, что у многих в мозгах сидит, даже у Индусов/Китайцев/Африканцев/etc
3) я не считаю эсперанто хорошим языком. Как минимум его крышечки это мертворожденный путь в никуда. Вот эти вот
c — [ц] (явно под влиянием польского)
ĉ — [ч]
ĝ — [дж]
h — [h] как в английском
ĥ — [х] как в русском, используется редко, в основном для передачи иноязычных имён и названий, например ĉeĥo «чех»
j — [й]
ĵ — [ж]
ŝ — [ш]
ŭ — неслоговое [у] (звук, похожий на английский [w] или белорусский [ў])
Эсперанто это язык с хорошей задумкой, но недоделанный.
А так правильно конечно сделать нормальный язык, убрать из него исключения и контролировать единым центром его развитие периодическими реформами, чтобы такого как Though, tough, through, thought свет больше не видел.
На своем веку я это чудо не увижу. Маловероятно. Ну что ж поделать, люди не логичные. А меня работа приучила всё-таки использовать логику. Так что страдаю.
Тут придётся выбирать: живой человеческий язык или язык без исключений. Они ведь не просто так возникают
Языки не просто так возникают, да. Это целый кластер косяков передающийся из поколения в поколение тысячелетиями. Как у Пелевина в его рассказе про жуков навозников:
Часть навоза дадим тебе мы с мамой, а потом ты научишься находить его сам
А выбора тут нет. Денег в синтетических языках нет. Они есть в Though, tough, through, thought, thorough, queue
Уточню, имел ввиду, что исключения возникают не на пустом месте. Как только языком начинают пользоваться живые люди, то они меняют язык под себя, потому что им так нравится. Вот будет два слова "четыредцать" и "сорок", люди станут использовать то, что удобней, а не то что логичней. И филологам лет через ***цать только и останется констатировать, что норма языка поменялась
Ну да. И для таких ситуаций, когда естесственный язык оброс всякой лабудой - некий центральный орган инициирует реформу орфографии. Это конечно костыль, а не нормальный синтетический язык, но лучше чем ничего. Как было с русским языком. Избавились например от ЯТЬ-ей - и слава богу. Тут вон мой критик/оппонент выше пишет про страшные словообороты в дореволюционном.
Но англоязычные рептилии так почему-то не могут: https://ru.wikipedia.org/wiki/Реформа_английской_орфографии хотя у нас тут смогли. Удивительно да? Ну раз уж начали в сортах естественных битых языков копаться...
Вопрос ребром: вернуть логичный четыредцать, оставить удобный сорок или волевым решением изобрести четыредесять? Логика неизбежно выйдет из чата, наплевав на все центральные авторитетные органы
Сербы машут рукой. Они же и письменность привели к фонетике сравнительно недавно.
Двадесять. Тридесять. Четридесять. Сербский язык по формам намного логичнее русского, внезапно. Только 7 падежей вместо 6 (но и в русском "звательный" падеж не вытравили до конца, он просто возникает только в разговорной речи).
Давайте по русски так начну говорить "они по этот вопрос дняли на встрече вчера"
Вы так удивляетесь этому словно никогда немецкий (предок английского, между прочим) не учили и понятие Trennbare Verben вам незнакомо.
Дружище, ты меня прям заставил первый комментарий за всю жизнь на хабре написать. Читаю твои комменты в этом треде и такое ощущение, будто у нас с тобой одна голова на двоих. Абсолютно разделяю твои взгляды как на рынок труда в ИТ сейчас, так и на эмиграцию. 12 лет в программировании
Я видел и неэффективных задротов.
Про Пелевина согласен
И про вредителей
Мазохисты занимаются вполне разумной пропагандой: заставляют напомнить IT-ам, что времена "лампового мира" заканчиваются, кормовая база сужается. Теперь от нас ждут стахановской работы и меньше умничать.
Я поддерживаю фиксацию факта сокращения "кормовой базы", надо снимать ИТ с хайпа, чтобы сюда не лезли все подряд.
Но всё-таки хочется пропагандировать самоуважение, и если у спеца нет спешки со сменой работы - не соглашаться на фекалии и почаще вертеть носом да требовать для себя любимого больше денег. При этом всегда следить за рынком, его трендами и бабками.
Сегодня большую ставку выгрыз ты - подтянешь рынок наверх, за тобой и остальные потянутся.
В остальном - я тут просто выговориться хочу, потому что когда пообщаешься с шизами, которые на щщах говорят что "нафиг мне смотреть на опыт кандидатов" и "литкод - это показатель чего-то", то прям тошно становится. А тут к моему удивлению меня даже лайкают, от души отлегает, не все с ума сошли еще
В остальном - я тут просто выговориться хочу, потому что когда пообщаешься с шизами, которые на щщах говорят что "нафиг мне смотреть на опыт кандидатов" и "литкод - это показатель чего-то", то прям тошно становится.
Надо быть терпимее. Да, сперва кажется, что мир полон идиотов (причём даже там, где ты не ожидал их увидеть). Потом приходит понимание: они всё же не совсем идиоты. Шнурки умеют завязывать, бутерброд правильной стороной держат, так что колбаса на пол не падает. Обычные люди. Работу делают, семью воспитывают, хобби там всякие. В чём-то преуспевают, может даже во многом. Вполне могут стать крутыми специалистами в своей области - IT в том числе. Просто не всем дано быть умными в широком смысле.
Потом приходит понимание
Да нифига не приходит. Чем больше я узнаю про что-то, тем больше вижу косяков, которые перемножаются на Пелевинский закон обратной чайной ложки, согласно которому ложка дегтя шкварит всю бочку меда
Что понятно - так это что ради денег можно и потерпеть и смириться и т.п. это я освоил нехотя, куда денешься
А из перечисленного я только с бутебродом соглашусь, остальное у меня горение вызывает, чем и как там люди маются. (шнурками не пользуюсь из принципа, для зала есть кросы на BOA, работу делают все хреново, института семьи щас нет, 80-103% разводов и т.д.)
Вот что реально есть, так это вездесущая https://ru.wikipedia.org/wiki/Дуккха (сцука, хром не умеет нормально копировать url-ссылки русскоязычные, со второго раза спец. плагином удалось скопировать без кракозябр... а вы говорите работают они...)
О, таким знакомым повеяло :)
Тоже зимой искал работу (Java Senior), прошёл около десятка разных мест - от небольшого подрядчика до бигтеха и от продуктовой конторы до крупных аутсорсеров и больших банков. Повидал широкий набор типов собеседований. Хотел даже по следам написать такую же статью, но поленился. А теперь чем дальше, тем меньше остаётся в памяти.
Перед каждой секцией эйчар высылал страницу со ссылками и рекомендациями, как готовиться, это сразу плюс. Там чаще всего были названия книг и ссылки на видеоролики с мок-собеседованиями.
А какие книги и ссылки рекомендуют там?
Конкретный список у меня не сохранился, но самые полезные в моём случае вещи я привёл в финале статьи.
Мартин Клеппман "кабанчик" про распределенные системы щас популярен. Вчера вот на tropper мемас видел недавно про него.
Но кстати заслуженно. Ты когда пытаешься погуглить что такое та же "линеаризация" - всё-равно в эту книгу утыкаешься, все комментаторы в тырнетах на нее ссылаются.
Очень интересная и познавательная статья, Благодарю !
И еще:
Цитата
"Дело даже не в том, что нужно делать что-то якобы плохое. Просто это как работа в ритуальных услугах: ты постоянно будешь сталкиваться с негативными и болезненными сценариями в жизнях людей".
А вот тут позвольте с Вами не согласиться, Объясню почему.
Касаемо "ритуальных услуг" - мир и природа так устроены - человек смертен, и зачастую смертен внезапно. И Вы, работая в этой отрасли, конечно же будете испытывать стресс и негативные эмоции, однако Вы, не творите ЗЛО сами и не потворствуете и не содействуете другим людям, которые творят ЗЛО или несправедливость (что есть разновидность ЗЛА.)
А вот во 2-м случае - Вы, если бы стали работать, то стали бы в некоей мере содействовать ЗЛУ. ============= Лично в моих глазах, в случае 1- профессия эмоционально очень тяжёлая, (и поэтому не каждому подойдёт) но вполне благородная, а вот в случае 2- всё наоборот. Желаю успехов.!
я написал за 10 на yield'ах
Я думаю в этом и была ваша проблема. Вам дали картбланш, вам дали типовой алгоритм, а вы пишете код сами. Возможно идея была в том чтобы проверить как вы пользуетесь современным инструментарием, а вы вместо того чтобы задать промпт ЧатГПТ - писали руками.
Ну, нанимали всё-таки разработчика, а не промпт-инженера )
Нет, идея в том, чтобы посмотреть, как кандидат решает задачу. Нам важно получить качественный результат. Знаете алгоритм, потому что выучили его раньше, дошли своим умом, загуглили или попросили ChatGPT - второстепенно. Важно, чтобы вы понимали, что именно вы сделали, и несли ответственность за результат.
Если вы написали алгоритм через ChatGPT, но понимаете, как он работает, и довели его до production ready - ок. Но если вы не понимаете то, что он выдал - не ок.
А при первом созвоне честно предупредил, что я нахожусь в состоянии почти получения оффера от другой компании. Ха-ха.
А, всё понятно, классический "сглазил" :)
Денис, привет! Это Максим Маркелов, Engineering Manager из Mindbox, я проводил твое собеседование. Спасибо, что описал свой опыт - у нас в культуре открытости это нормально.
От себя поясню: я отказал тебе после первой встречи, потому что, несмотря на уверенный технический уровень, показалось, что у нас разные подходы к работе и взаимодействию. У нас много открытой ОС, в моей команде много джунов. Мы ценим, когда инженер может принимать обратную связь не только от лидов, но и от джунов.
Ты выглядел человеком с ярко выраженной индивидуальной позицией, но чувствительным к роли и весу слова. Для меня это риск - нарушается психологическая безопасность. Я принял решение не продолжать, чтобы не тратить твое время. Тем более, что были другие кандидаты, с которыми был больший фит по культуре.
Собес, на котором мы были - это первичный собес по софтам + одна техническая задачка. Делаем в таком формате, чтобы сократить время наше и кандидатов на отбор, если на первом этапе понимаем, что не подходим друг-другу. Полноценный технический собес - это должен был быть следующий этап.
Привет, спасибо за отзыв. Но почему нельзя было так и сказать в обратной связи? Я бы абсолютно нормально это воспринял. И было бы понятнее, чем то, что мне написали, причём только после моего вопроса :)
Не все готовы сходу получать ОС после собеса, поэтому даем ее по запросу. Мы не теряемся после собеса, обычно в течение 2-3 рабочих дней возвращаемся в ответом. Тут ты пришел раньше)
Почему изначально была такая формулировка - человеческий фактор. Неточно выразили причину отказа. У себя внутри публично обсудили ситуацию. Поэтому я пришел опрозрачить решение, тем более, что его принял я.
Собственно, вот и пример работы нашей открытой культуры. В отдельный канал пришел разработчик, скинул ссылку на твою статью. Канал публично доступный. Началось обсуждение, признали, что ответили не прозрачно. Улучшаемся.
Спасибо, что раскрыли интересные подробности о работе в вашей компании - думаю, это многим будет полезно, а не только Денису.
Предположу, что средний возраст в командах у вас невысокий, до 30?
У нас высокие требования к качеству и продуктивности, выше среднего по рынку. Мы не скрываем этого, и многие приходят именно за этим: расти и делать сложные задачи.
Но это не значит, что мы поощряем переработки. Мы не бежим спринт, мы бежим марафон:
– есть ежеквартальный опрос о нагрузке
– EM'ы регулярно отслеживают баланс и состояние ребят в команде
– если человек стабильно перерабатывает, это сигнал, что что-то сломано: в оценке, в процессе или в коммуникации. Это надо чинить.
Да, рост требует усилий, а не просто поработать доп. часы вечером. Это может быть инициатива, взятие доп. ответственности.
Что касается возраста, в компании есть люди 20+, 30+, 40+. В моей команде средний возраст - 29 лет.
лошадь работала в колхозе больше всех, но директором так и не стала, ггг
Пользуюсь случаем, немного попиарю вакансию в свою команду SecOps - https://hh.ru/vacancy/79405175
Занимаемся продуктом безопасности (авторизация, права доступа, ролевая модель, журналы событий) и повышением безопасности всей разработки (SIEM, сканеры уязвимостей, аспекты безопасной разработки).
Команда только формируется, можно быстро вырасти в лидирующие роли.
Но... это ведь та же вакансия, на которую я откликнулся. А как же два кандидата на более поздней стадии найма? Я уже неделю как работаю в другом месте, а вы всё вакансию не закрыли?
Да, искали двух сеньоров. Одну позицию закрыли, вторая еще в поиске.
Если бы подход был “берём любого, кто откликнулся” - команда уже была бы собрана. Но хочется долгосрочных отношений. Так что да, подбираем долго, зато метко.
Они все разбежались после вашей статьи.
Упс :) А есть ли эта реальная вакансия?
На счет открытых зарплат. Время собеса ограничено, жаль, что не смогли полноценно раскрыть суть. Но про голосование мы не говорили, а про кулуарную обсуждение я отвечал. Давай чуть прокомментирую.
Зарплаты открытые, каждый сам:
- ставит себе цели, которых хочет достичь
- зарплату, которую хочет получать после достижения этих целей.
Цели выравниваются в соответствии с целями трайба и грейдом. Ты как сеньор не можешь сказать, что хочу получать +100к и при этом буду делать обычные однодневные задачки. Цели обсуждаются с менеджером, он помогает их сформулировать.
Если никто не считает повышение неоправданным, карточка на повышение ЗП проезжает в бухгалтерию, и ЗП повышается.
Если цели слабые или ЗП не соответствует им, то к тебе в комменты придет команда/менеджер/любой сотрудник компании и подсветит этот момент. У тебя будет возможность скорректировать цели/ЗП. Если ты этого не делаешь, то тебе могут заветировать повышение. Тогда будет организована вето встреча, где вы либо попробуете договориться, либо делегируете принятие решение третьему человеку, которому вы оба доверяете решение.
Такое случается крайне редко, за год работы в компании я с таким не сталкивался.
Плюс такого подхода еще и в том, что ты в карточке подводишь результаты работы и просишь оставить ОС всем, с кем работал - с командой, с другими сотрудниками. Т.к. процесс повышения публичный, то все видят твое повышение, и могут оставить тебе фидбэк, если вы взаимодействовали. И ты публично можешь на него ответить, в том числе не согласиться. Как раз такой механизм и позволяет избежать кулуарного поливания грязью - если не согласен, скажи об этом публично.
В общем, это описание подтвердило для меня, что вы примешиваете к работе инженера чрезмерно большое количество, прости, мышиной возни: с этим договориться, тому понравиться, там собрать обсуждение и так далее. Так что ты совершенно правильно понял, что мы не сработаемся, за что спасибо. С моей точки зрения технический специалист высокого класса должен эффективно и правильно решать технические задачи, а коммуникациями заниматься в рамках минимума, необходимого для естественного человеческого взаимодействия в команде, не больше. А здесь игры престолов отнимали бы очень много внимания.
Работаю в майндбоксе почти два года, никаких игр престолов не заметил. Всё максимально комфортно и с уважением к людям. Карточки на ЗП очень эффективный способ роста, где ты можешь получить полезную обратную связь в моменте. Работать от целей считаю полезнее, чем просто делать задачки из беклога. Ставишь себе продуктовые цели, которые приносят компании деньги и достигаешь их. В итоге, все в плюсе: компания зарабатывает на новой фиче, ты повышаешь себе зарплату до нужного уровня.
А больше всего мне нравится открытость: я могу пойти к любому человеку (хоть к джуну из соседней команды, хоть к CTO), чтобы обсудить решение какой-то проблемы, если считаю, что он в контексте и может помочь. Или вовсе написать в публичный канал с архитекторами и найти оптимальное решение среди многих.
Но в обычной здоровой корпоративной среде я тоже ставлю себе продуктовые цели и тоже могу с любым коллегой любого ранга, который в контексте, обсуждать решение. Просто в обычной среде мне не нужно одобрение джунов, чтобы доказать свою экспертизу )
Никто и не требует ходить с обходным листом по джунам и запрашивать их одобрения. Культура даёт возможность каждому сотруднику высказаться, но вовсе не обязывает этого делать. И да, если кто-то выразит сомнение в твоём решении, то тебе придется обосновывать его и доказывать свою экспертизу, не важно джун это сделал или архитектор. Из этого и рождаются лучшие решения, принятые совместно.
рождаются лучшие решения, принятые совместно.
А кто несет ответственность если коллективное решение принесло убытки?)
Чет вспомнилось: В 2009 году из Google уволился ведущий дизайнер Дуглас Боумен (https://www.cnet.com/news/google-designer-leaves-blaming-data-centrism). Цитата из его блога:
Да, это правда, что команда в Google не могла выбрать между двумя оттенкамии синего, и поэтому тестировала 41 оттенок, чтобы увидеть, какой из них лучше. У меня недавно была дискуссия о том, какой должна быть обводка: 3, 4 или 5 пикселей, и мне было предложено доказать мой выбор. (прим. перев. очень сложно доказать разницу в 1 пиксель). Я не могу работать в такой среде. Я устал обсуждать такие незначительные дизайнерские решения. В этом мире есть более интересные проблемы с дизайном.
а кто несёт ответственность за совместные решения?
У нас - всегда тот, кто решение принял. Даже если оно было “коллективным” - это значит, что человек выслушал, обсудил, но сам взял на себя ответственность и последствия. Иногда это несколько человек, если решение действительно общее.
Ошибки, конечно, случаются. Но за счёт прозрачности и открытой обратной связи их не нужно скрывать, они быстро всплывают и обсуждаются по существу.
Пример из практики.
Миддл из моей команды (назовём его Геннакер) участвовал в проекте другой команды. Там техлид долго “прорабатывал архитектуру” и зарывался в неважные детали. Геннакер начал задавать вопросы, в какой-то момент эскалировал до архитектора. Архитектор включился, посмотрел, разобрался - и помог принять более простые и адекватные решения.
Никто не испугался того, что это делает миддл. Никто не защищал “священное право сеньора”. Это и есть культура, где важно качество решений, а не иерархия.
Ошибаться можно. Но если ошибка повторяется или ломает другим работу - у нас есть карточка “несчастья” (аналог желтой карточки в футболе). Это не скандал и не выговор. Это формальный способ зафиксировать, что что-то пошло не так: сформулировать, в чём именно проблема, предложить путь выхода, договориться о сроках.
Если несчастье не лечится - честно расстаёмся.
Свобода решений работает только там, где работает и ответственность. И у нас она работает.
Из этого и рождаются лучшие решения, принятые совместно.
Булшит какой-то.
Эксперт потому и эксперт, что не должен доказывать каждый раз кому попало, что он не верблюд.
А если каждый раз вместо принятия оптимального решения, основанного на опыте, надо заниматься доказательством того, что твой опыт никуда не подевался, то нафига вообще в таком случае эксперту у вас работать? Это уже не корпоративная культура, а сектантство.
Я не понимаю, где вы читаете "каждый раз"?
Тривиальные и очевидные задачи проезжают без каких-либо вопросов. Да, бывают ситуации, когда сеньор без знаний домена предлагает не самые лучшие решения и ему об этом открыто говорят более осведомленные в проблематике ребята, которые не обязательно должны быть равного или выше грейда. И все обсуждается на здравом смысле, так как у всех одна цель: сделать крутой продукт, а не вставить друг другу палки в колёса.
> Эксперт потому и эксперт, что не должен доказывать каждый раз кому попало, что он не верблюд.
Это может быть в другом месте джуны это "кто попало", а у нас они уважаемые и компетентные люди, с которыми очень приятно работать. И если эксперт не может (или не хочет, козыряя грейдом) объяснить свою точку зрения, то вопросы будут скорее к эксперту, чем задающему вопрос.
> оптимального решения, основанного на опыте
Опыт - вещь субъективная. Открытые дискуссии не только помогают собрать коллективный опыт всех заинтересованных, но и шарят этот самый опыт между людьми, что не менее ценно.
Лично мне в удовольствие объяснить человеку свою точку зрения, когда я принимаю какое-либо решение, в выигрыше все. И я могу получить обратную связь и что-то улучшить, и собеседник ценное для себя усвоит.
> сектантство
Хохотнул, была у меня похожая мысль во время трудоустройства :D
Но потом втянулся (промыли мозги)
Это может быть в другом месте джуны это "кто попало", а у нас они уважаемые и компетентные люди, с которыми очень приятно работать.
А как с таким подходом удаётся избежать ситуации "каждый суслик в поле - агроном"? Не бывает такого, что уважаемый и компетентный, но пока ещё малоопытный джун возомнил себя офигеть каким экспертом и громко лезет всюду со своим очень важным мнением, хотя объективно ему бы пока что лучше молчать и учиться?
Т.е. когда идёт злоупотребление вашей системой не со зла, а просто, напр., из-за юношеского максимализма?
Да, такие ситуации бывают. Иногда джун правда начинает “агрономить” не по делу, а просто потому что уверен, что “наконец-то можно говорить вслух”, и хочет проявиться. Это нормальный этап.
Что с этим делаем:
публичные обсуждения и обратная связь часто сами выравнивают поведение: когда тебе аргументированно отвечают на каждый наброс, быстро учишься говорить по делу. Плюс подсвечиваем, что у обсуждения должна быть цель, а не просто похоливарить (если это не оффтопик какой-нибудь).
вне критичных путей можем дать попробовать “сделать по-своему”, с возможностью ошибиться и потом отрефлексировать
если ситуация не лечится, заводится “карточка несчастья” (по факту как жёлтая карточка в футболе): что не так, план исправления, сроки. Если не помогает — честно расстаёмся.
Так что да, допускаем ошибки. Но не бесконечно и не без последствий.
сектантство
Блин, а ведь точно. Теперь у меня в голове модель укладывается. Структура, очевидно, работает: компания прибыльная, продукт продаётся и функционирует. И люди внутри, кажется, действительно верят в их систему, вон как тут защищают её. Но при этом у системы есть много сомнительных для внешнего наблюдателя признаков, начиная от показного противопоставления себя общепринятому и заканчивая более специфичным ритуалом отбора, чем это обычно бывает.
Это же секта. Прямо по пунктам: противопоставление обычному, ритуалы, замкнутость, отличие своих и не своих, истовая вера адептов в учение, и даже фактическая стабильность и работоспособность системы. Дословно прям, теперь идеально всё сошлось, спасибо!
Каждый видит то, что хочет видеть.
Мы не говорим, что наш подход идеален или единственно верный. Мы свои подходы заимствовали у разных компаний: Neflix, Spotify. В РФ похожие практики есть у DoDo и Райфайзена. Рассказываем, как устроено у нас - с плюсами, минусами и фактами. Кому-то это интересно и полезно. Кому-то удобнее назвать это сектой, сомнительно, но окэй.
Но если на аргументы и открытость в ответ прилетает набор ярлыков - это уже не диалог. А значит, бессмысленно продолжать.
Из этого и рождаются лучшие решения, принятые совместно.
Или закрываются проекты из-за перерасхода бюджета на прирания на совещания
Можно сутками рассуждать как правильно циклы реализовывать в задаче по реализации критической фичи...для этого модератор в команде нужен, но это не всегда работает, я видел многодневные баталии в ревью когда съезжали дедлайна из-за этого...
Совместные решения это хорошо, пока все понимают для чего они работают и это понимание едино для всех, а вот когда у вас в команде 15 человек, это уже не всегда возможно
Спасибо за точку зрения! Да, такое бывает и в таких местах тоже приходилось работать. Текущее место работы я и выбрал по причине того, что тут во главе угла здравый смысл.
> закрываются проекты из-за перерасхода бюджета на прирания на совещания
Компания продолжает рост даже в текущих непростых условиях на рынке РФ, можно ли сделать вывод, что перерасхода не случается и открытый подход работает?
Отдельно скажу, что получаю мега-кайф от общего канала с архитекторами всех команд, где можно жестко зарубиться за какую-нибудь серьезную продуктовую фичу и в итоге получить не только новый ценный опыт, но лучшее, выверенное решение. Первый раз такое встретил именно в майндбоксе.
Смотри, никто в Mindbox не требует “одобрения от джунов”, и у нас нет “голосования” по техническим решениям.
Но мы считаем нормой, когда любой человек может задать вопрос, если что-то кажется ему спорным. И ты как инженер должен объяснить свою позицию. Не потому что ты “не эксперт”, а потому что в инженерной культуре доказательства и прозрачность важнее статуса.
У нас можно принять решение самому - без согласования и обсуждения. Но если оно затрагивает других, ты обязан прозрачно уведомить тех, на кого оно повлияет. Это основа доверия и зрелости.
Если кто-то задаёт вопросы, ты можешь:
— обсудить и учесть их аргументы,
— объяснить, почему делаешь по-своему,
— сослаться на свою экспертизу.
Но если ты просто “сделал и всё”, не объяснил, не выслушал - тогда любой может наложить вето. Это защита от закрытых и потенциально вредных решений.
При этом вето - не запрет, а старт диалога. Ответственность все равно остаётся на тебе, просто придется обосновать, почему ты уверен.
И да, часто вообще никто не спорит. Но возможность поспорить - это и есть безопасность.
Вполне разумно звучит, скажите насколько полезно формализация этого принципа открытости. Например, в своей команде мы всегда делаем презентацию и обсуждение крупных решений. Если есть серьезные возражения, то отправляем ответственного на доработку идеи. Но при этом не вижу смысла подключать ребят из других команд на часовые обсуждения - у них вся работа встанет. В целом вызывает вопрос поверхности привлечения не погруженных спецов...
Принцип открытости работает не только в разработке. Он распространяется на всю компанию. Мы не делаем “открытость ради открытости”, а хотим, чтобы любой, кого задевает решение, мог быть услышан.
Во-вторых, мы сильно выросли: за 2 года с 234 до 420 человек. Это помогает компании эффективно развиваться.
Открытость != “зови всех на каждый созвон”.
Мы уведомляем, даем возможность подключиться и высказаться, если хочешь или это тебя касается.
Не касается? Не подключаешься. Но если затронуло, у тебя есть возможность включиться обсуждение/принятия решения.
Это не мешает работать, наоборот, помогает не принимать решения в слепую.
Кажется, это требует высокой самодисциплины и вовлечённости. А как быть если человек важен в обсуждении, но он не проявляет инициативы высказывать свое мнение из-за закрытости ?
Да, самодисциплина и вовлечённость реально важны. Без этого открытость не работает.
Если человек молчит, но его мнение важно, есть несколько способов:
можно подойти напрямую и обсудить тет-а-тет,
можно пингануть в личке, созвоне или комменте
можно взять ответственность за решение на себя, но проговорить, что человек не принял участие в обсуждении.
У нас нет культа “все обязаны участвовать”. Но если ты участвуешь - твой голос считается. А если молчишь, это тоже ок, просто решение может быть принято без тебя.
Не читал весь тред. Можно пару вопросов?
Разработчик может узнать о прибыли компании и о доходах топ менеджеров?
Разработчик может узнать о прибыли компании
Не только разработчик, вообще любой сотрудник может узнать о прибыли компании, ее расходах и доходах. Более того, мы ежегодно в своем публичном блоге публикуем результаты года. Например, вот итого 2024 года. Там и финансовые показатели, и количество клиентов, и данные по сотрудниках.
о доходах топ менеджеров?
Доходы топов - тоже публичны внутри компании. Как и цели, по которым они себе ставят ЗП. Если у сотрудников возникают вопросы по эффективности их работы, они могут публично их задать. Открытость у нас не выборочная.
Да, такая культура накладывает свои ограничения - требует больше взаимодействия между людьми, интеграции возражений. Это накладывает ограничение и на найм - сложнее нанимать хороших специалистов, потому что не каждому подходит наш формат работы.
При этом такой подход дает свои плюсы - больше прозрачности и эффективности. Компания с 2009 по сей день выросла с 10 до 500 сотрудников с выручкой под 3 млрд. Что подтверждает, что подход приносит пользу.
Привет!
Правильно понимаю, что рядовой разраб должен вместо работы изучать продуктовые метрики и искать точки роста, чтобы самому себе поставить задачу? Чем тогда продакт занимается?)
И высший приоритет тоже сам разработчик себе выставляет, чтобы баги не мешали поднимать ЗП?
Без негатива, в самом деле интересно, как это у вас работает с учетом недостатков реального мира)
Блин, если чудо произойдет и когда-нибудь я прорвусь в бирюза - я бы это даже попробовал. Я в качалочку хожу для поддержки боевого духа и могу спорить до посинения по теме эффективности, доказывая что я Дартаньян, а оппонент - *АС. Я так понимаю, я просто в диспутах всех раскидаю и мне поднимут ЗеПку, так это работает?
А еще у меня специфические шутки. 25-50% компании будут с меня орать, остальная часть хейтить, каеф (я так оффтоп чатик на одной из прошлых работ разрушил, солярого)
Первым же голосованием тебя уволят )
Я так понимаю, я просто в диспутах всех раскидаю и мне поднимут ЗеПку, так это работает?
Не сработает. У нас ЗеПку поднимают не за “всех раскидал”, а за “всех выслушал и сделал нормально”.
У нас каждое внутреннее демо - это ор, мемы и специфичные шутки. Уверен, тебе зайдет)
Привет!
Правильно понимаю, что рядовой разраб должен вместо работы изучать продуктовые метрики и искать точки роста, чтобы самому себе поставить задачу?
Нет, не совсем так.
За метрики, точки роста и продуктовую стратегию у нас отвечают продакты. Разработчики не заменяют продактов. Никто не ждет, что миддл будет сам анализировать бизнес и “придумывать себе работу”.
Но мы поощряем инициативу. Если ты заметил проблему, которую можешь решить, и это в контексте команды, ты можешь поднять эту задачу сам.
Ты не обязан это делать. Но если хочешь, тебе дадут фидбек, помогут, подскажут, выровняют по целям.
Это работает в связке с EM, командой и продактом - никто не один в поле.
И высший приоритет тоже сам разработчик себе выставляет, чтобы баги не мешали поднимать ЗП?
Тоже нет.
Приоритеты команда определяет вместе на викли. Учитываются задачи продакта, баги, техдолг, технические улучшения - все взвешивается.
Цель для ЗП человек ставит сам, но в рамках задач команды и своего грейда. Это может быть:
– залидить проект
– сократить алерты
– улучшить DevEx по части пайплайнов и т.п.
Если цель не совпадает с приоритетами команды или выглядит странно - EM или команда это подсветят, и цель скорректируют.
Так что “выставить себе левую цель, чтобы апнуть ЗП” - не сработает.
Мы не требуем инициативы, но даём все инструменты для тех, кто хочет брать на себя больше.
А рост, ЗП, ответственность - идут за реальной пользой, а не за “активностью ради активности”.
Бирюза - это не про то, что нет руководителей. Это про взятие ответственности и доведение до результата. Если ты опытный сотрудник, который в компании работает годы, то твоя экспертиза ценнее, к тебе чаще прислушивается. Но это не значит, что твое решение имеет больший вес - его можно оспорить.
Если интересно, вот интервью о культуре и реалиях у нас - https://jobs.mindbox.ru/dev/ .
Вижу прямое противоречие между "твоя экспертиза ценнее" и "твоё решение не имеет большего веса". Конечно, имеет. Это буквально определение экспертизы: более высокий вес мнения эксперта.
Криво мысль выразил, переформулирую ее.
Экспертиза важна. К мнению сильных инженеров прислушиваются чаще, потому что за их словами обычно стоит опыт, контекст и зрелость.
Но в наших командах решение побеждает не потому, что ты старше или авторитетнее, а потому что оно ведет к результату.
Если сеньор месяц проектирует идеальный микросервис по всем канонам DDD, а другой просто делает качественно и доводит до продакшна, мы выберем второго. Даже если другой - это джун или миддл.
экспертиза ценнее, к тебе чаще прислушивается.
Но это не значит, что твое решение имеет больший вес
Спасите меня пожалуйста... И мне с этими людьми надо общаться, и эти люди будут давать мне оценку... Е* рот этого казино... И никуда от них не скрыться...
Бирюза - это "теперь вы сами себе погонщики, радуйтесь"
любопытно.
Кажется, все стало слишком формальным и IT превращается в бездушную машину для зарабатывания прибыли компаниям. В реальной работе ты должен проявлять творческий подход, который сильно связан с кругозором, интуитивным и спонтанным движением, поиском логической связанности для создания финального решения. Тоже касается софт-скиллов - хорошо, если ты внедряешь скрамы, покеры, но что если ты не приятный в общении скользкий тип ))
Я догадывался, что при собесе в бигтехи происходит цирк, но чтобы до такой степени...
Все это выглядит так, будто народ поголовно валит снег с больной головы на здоровую (кто то по своей инициативе, а кого то заставляют). По итогу, собеседующие- это просто выдернутые из рабочего процесса люди, которые далеко не всегда будут заинтересованы в проведении собеса. Причем, на каждый этап нужен свой собеседующий, И если тебе не повезет и никому из этой цепочки собес нафиг не сдался, то ты, как соискатель, идешь нафиг и пофиг на твои навыки, реальный опыт и знания.
Еще добавим к этому то, что собеседует тебя суммарно 3-5 человек, каждый из которых имеет свою компетенцию и именно в ней сильнее всего, а ты один и должен в каждой из этих компетенций ответить более чем достойно.
Ах да, совсем забыл. Еще может оказаться так, что вакансии как таковой нет и что ты тут вообще делаешь, не сильно понятно.
Суммируя, можно задать вопрос. А почему бы собесы не проводить именно тем командам, которые заинтересованы в нахождении человека с конкретными компетенциями?
В итоге, секций получится 2: одна с HR, а другая с членами команды, где тебя будут спрашивать про твой опыт (для понимая того, что в тебя в целом можно закинуть) и про те задачи, которые требуется закрыть новым сотрудником в данный момент
Все так. Зачастую на собеседование дергают рандомного разработчика рандомной команды просто потому что ну очень надо, а некому. Многие из таких "выдернутых" из процесса людей не очень-то представляют процесс собеседования как таковой. Как спрашивать, что спрашивать - в итоге получается каша из "примерно помню как меня собеседовали" и "ну наверное что-то такое кандидат должен знать". Отсюда рождаются банальные, достаточно бестолковые но буквально общеупотребимые вопросы, которые задают абсолютно все. Например, вопрос про три поколения GC мне задавали на вообще всех собеседованиях за последние четыре года. Понятно, что я это знаю. Понятно, что любой, кто читал про .NET это знает. Равно как и любой, кто прошел больше одного собеседования, потому что даже если ты совсем твердолобый, то не с первого, так с пятого раза пойдешь и погуглишь. Как это сакральное знание влияет на написание кода? Да никак, конечно. Просто надо что-то спросить, вот и спрашивают.
Про две секции - в нормальных компаниях, которые ценят не только свое время, но и время соискателя так все и происходит. Если компания не Яндекс, который свято уверен, что работать в их конторе такая большая честь, что можно соискателя месяц по литкод-задачкам гонять и потом еще месяц думать.
Может это будет звучать очевидно, но для многих это не так, судя по комментариям: чтобы хорошо пройти собеседование не обязательно дать правильные ответы на каждый вопрос. Задача интервьюера - нащупать слабые места и глубину знаний кандидата, а не прогнать по формальному чек-листу и подсчитать сумму баллов. То есть результат определяет достижение необходимой глубины по всем важным областям, а не количество правильных ответов.
Если вас умудрились "завалить" только на вопросах-ультрахард, где нужны энциклопедические знания или специфический опыт, то вы - большой молодец и наверняка получите респект от интервьюера, хотя и не ответили. Если же кандидат знает везде, но лишь по верхам - то дальше рискует не пройти, не смотря на количество правильных ответов.
Как это сакральное знание влияет на написание кода?
Если вы знаете устройство платформы, ее сильные и слабые стороны, это позволит делать более производительный, экономный по ресурсам код. Это позволит со знанием дела анализировать проблемы по памяти и пользоваться профайлером.
Не знать совсем глубоких нюансов или забыть детали - это нормально и едва ли это "снимет баллы". Но если кандидат позиционирует себя опытным специалистом, а при упоминании поколений объектов делает совсем круглые глаза и/или несет окровенный бред, то это, как минимум, повод насторожиться и прощупать базу. Может это единственный пробел, тогда это не проблема, но если там откроется бездна, то использование избитого вопроса окупится сполна.
Согласен, если человек этого не знает, конечно, это повод насторожиться. Но я бы на месте интервьювера, если спросил про GC и в ответ сразу слышу про три поколения и цикл сборки - сразу бы прервал и продолжил с другими вопросами, потому что время не резиновое, а если человек в курсе про поколения, значит он про это читал и знает. Ну это так, мысли вслух. К слову, некоторые интервьюверы именно так и делали, что ок на мой взгляд.
Про профайлер и проблемы памяти в целом тоже соглашусь, только вот в 99.99% проектов на .NET этого не требуется. За 10 лет в разработке я только несколько раз встречал задачи, требующие глубинной оптимизации и профилировки, потому что, будем честными, абсолютное большинство бэкенд-задач - перекладывание JSON'ов по CRUD'ам и если там и есть узкие места, то они как правило упираются в БД а не в бизнес-логику. Разумеется, мое мнение не более, чем ошибка выжившего и я уверен, что есть люди, которые именно критикал-перформансом на .NET занимаются большую часть времени, но личная статистика говорит, что таких скорее всего сильное меньшинство.
Уже 500 коментариев, вряд ли мой кто-то прочитает. Но просто кратко изложу.
В Великобритании вначале искал работу полгода, интервью все разные с разными методами. После этого работал в разных команиях (в том числе американских) и нигде не видел никакой системы ни со стороны проходящего, ни со стороны проводящих. Посути в основном один на один или с несколькими сразу и в основном разговор. В итоге откуп на индивидуальное понимание каждым как он хочет или видит, или, скорее, как чувствует. Доходило до смешного, что один может сказать про кандидата совершенно противоположное другому.
Есть доступные тренинги, где есть хоть какая-то система оценки чего человек реально сделал. Но не слышал чтобы кто-то кроме меня эти тренинги из бывших коллег проходил. Если честно, даже сам не знаю как на интервью показать себя, на словах все люди хороши наверное. Самое классное - когда можно показать что умеешь и тогда видишь, что у людей глаза загораются.
Сам от собеседований на новую работу обычно многого теперь не жду и спокойно к ним отношусь. Особенно если нельзя себя показать в деле, то результат абсолютно случайный. Может и есть способ как-то себя показать чисто используя разговор, но я его не знаю.
Ну за что так с "кофе"?
после шарпа возвращаться на неё это как пересесть на старую Ладу с новенькой иномарки: вроде ездит, но уже давно привык к другому уровню комфорта
Как я собеседовался в Ozon, Т-Банк, Mindbox и другие крупные компании