Похождения глазика или о граблях в топ компаниях
Всем привет!
Спасибо коке и махмуду за тёплые слова. Извиняюсь за задержку, во первых адское лето регулярно говорит мне: "севодня лежиш", а во вторых у меня ушло куда больше времени на эту статью из-за паровоза мыслей (когда говоришь А, и вспоминаешь, что неплохо бы сказать Б, В и Г, а упомянув Б... ну вы поняли).
Здесь я поделюсь своим опытом с Амазон, Майкрософт и Гугл, а так же паре трюков с ними, которым я научился, пока собеседовался с ними по нескольку раз.
Для контекста, мне 7 годиков как кодеру на C#, потому джуном меня назвать не получится. Но для любого от 1 года опыта на brainfuck тоже подойдёт.
#1. Как выглядит сам процесс
В целом, он похож на 99% у всех троих. Все этапы состоят из одного из двух ингредиентов: задача по алгоритмам и поведение (о них чуть ниже), меняется только способ их проведение (и здорово меняется, на самом деле). Этапы у всех такие:
- 15 минутное интервью с рекрутером, которому ты рассказываешь про свои последние год-два опыта. Или просто о себе. Или о гипотетической ситуации. Вопросы абстрактные, запутанные, но всё сведётся только к одному шаблону, и об этом ниже.
- Тестовое задание на платформе типа leetcode. За ограниченное время, нужно решить задачи по алгоритмам, о них тоже подробнее ниже. Во всяком случае, так было до ChatGPT, который щёлкает их как орешки. После, не сталкивался
- 45 минутное интервью с действующим разработчиком
- 3 интервью с алгоритмами и 1-2 по поведению (4-5 всего) в течении одного - двух дней.
- результат: когда как, могут ответить в течении двух недель, а могут и за два дня
#2. Как попасть в этот процесс?
Здесь это - самый кусючий фильтр. Чёртова лотерея. Подаёшь заявки, десятки их и... "к сожалению бла бла бла, попытайтесь в другой раз". Неприятно, и по самооценке бьёт (особенно заметно после нескольких десятков попыток).
Пидор, если у тебя часто возникают мысли, "а не дурачок ли я?" и "зачем мне это?", то ты не один. Это нормально. Можно даже пройти собес в слабую компанию чисто для поднятия духа.
Если взглянуть на это с другой стороны, в одну вакансию за 3 дня накидали 400 заявок. И такое с каждой, рекрутер не в состоянии обработать их все.
Так же, не помогают и массовые увольнения, что были раньше: меньше рекрутеров, больше конкуренции из уже бывших сотрудников этих компаний.
Мне повезло: в 2021 и начале 2022, мне написали сами все эти 3 компании. Правда, был отсеян на последнем этапе у всех трёх. В этом году не написали, и мне удалось в процесс только с гуглом, за счёт поддержки рекрутера (чел буквально за пару дней меня закинул не просто в процесс, а сразу в последний этап).
#3. Интервью: Поведение
Техника STAR (или SAR) - сильнейший инструмент на моём опыте. Сперва было непросто понять как это работает, особенно на фоне 14 принципов лидерства Амазон (о них немного здесь https://habr.com/ru/articles/645045/, но ради бога, это лишь метрики, с ними можно свериться, но не ориентироваться, пользы мало, а дезориентации много). Но, с практикой это превращается в BFG9000.
Для тех, кто не знает, STAR - это когда ты отвечаешь по шаблону:
- Ситуация/Задача — Situation/Task: Где, когда это произошло, почему это важно?- Действие — Action: что ты лично сделал, как ты это сделал, кто ещё учавствовал?- Результат — Result: как ты измерил выхлоп этого проекта? Какие результаты у тебя вышли? * Экономия затрат, получение дохода * Считай в цифрах, чтобы дать понять объемы, размеры, масштабы * Изменение в процентах, годовые улучшения * Время выхода на рынок, время реализации, экономия времени * Воздействие на заказчика, команду * Улучшение качества
Так же, приглашаю уделить 10-15 минут (не больше) этой статье, чтобы просто иметь представление о том, что это и с чем её едят: https://habr.com/ru/companies/netologyru/articles/691510/
Не больше, чтобы не циклиться на деталях, лучше это понимается на примерах.
Так же, помогает смена ролей. Вместо "ты собеседуемый и пытаешься понравиться хорошей компании" на "ты - тренер и помогаешь джуну понять, что к чему". Сразу исчезает давление, посторонние мысли в голову не лезут, и ты делаешь то, что привык делать (надеюсь, если нет - самое время пробовать).
Вернёмся к STAR. Рассмотрим пару примеров. Тебя просят рассказать о своих достижениях:
а) Ты занимаешься скучной фигнёй вроде разработки приложения для менеджеров по продажам для понимания клиентов.
б) Может, работаешь с большим легаси приложением - швейцарским ножом для внутреннего потребления в компании.
в) Ну или пишешь плагин чтобы было проще программировать роботическую руку, отвечающую за упаковку.
В любом случае, ты решаешь себе задачки, затем забываешь о них и занимаешься своими домашними делами. Какие вообще достижения??
Как подготовиться:
Возьми любую задачу что ты решал и ответь себе на вопрос: что за проблему оно решило? Главное - цифры.
Задача:
а) Ты добавил фичу, проверяющую пользовательский ввод, если ты бэк.
б) Передвинул пару кнопок, если фронт (конечно, работа у ребят будет посложнее, но я специально беру максимально тупые примеры). в) Ты исправил баг в приложении на компьютер, когда пользователь работает ногами, и приложение внезапно красится в "горячий розовый".
г) Эм... ты написал драйвер на ассемблере, что работает на 10% быстрее предыдущего за счёт квантовых вычислений и расщипления чёрных дыр на атомы.
Решённая проблема (что было до этого - проблема, и что после - результат):
а) Пользователи раз в день* вводили неверные данные. Это нарушало работу нашей системы и нам присылали задачи их исправить. Такая задача занимала час в день. С введением этой фичи, я сэкономил 1 час работы, это 1 час разработчика каждый день
* - даже если не знаешь сколько точно, лучше по наитию назвать конкретную цифру; будь готов обосновать, в этом примере у тебя было 50 менеджеров по продажам и кто-то да ошибался (если нет, то убеди себя что действительно было, хотя откровенно врать - так себе идея)
б) У нас был неинтуитивный пользовательский интерфейс (*зевок*). Это заставляло продажников тратить в среднем по 1 минуте в день на поиски нужных кнопок, когда они работали с приложением. Всего у нас 10 продажников. Итого, я этим сэкономил примерно 1 час в неделю, а так же избавил продажников от стресса (пункт: влияние на заказчика, команду) путём улучшения качества софта (тоже пунктик).
в) Нам раз в неделю* поступали жалобы об интересном баге (о котором написано выше). У нас не было точных метрик (если же были - используй!), но где-то 10 пользователей из 50 всего натыкались на этот баг, из-за которого они перезагружали приложение, чтобы сбросить странный цвет, и потом писали негативные отзывы о нас**. Что я сделал: я обнаружил, что в определённом сервисе есть неучтённый случай работы пользователя ногами и добавил туда проверку. Так, я исправил этот баг, и снизил кол-во негативных отзывов о нас с 1 в неделю до 1 в квартал.
* опять же, конкретная цифра
** не забыть про то, какая была проблема
г) У нас хороший продукт. Одно из достоинств/один из недостатков его - скорость. Чем быстрее - тем выше конкурентноспособность приложения, ведь тогда продукция выходит быстрее / администратор работает быстрее и более слажено.
Понимая это, я предложил способ его ускорить. Он основывается на ... (описано выше). Я разработал подробный план действий, потому не было сложности в том, чтобы его одобрить. Его и одобрили. Затем, я за 3 месяца выполнил эту часть, используя стиль змеи и прочие микро компоненты.
У меня получилось ускорить процесс на 10%, что ... (повторяешь то, что написано в начале этого пункта, да и идея, надеюсь, понятна).
Перевод в STAR:
Падажжи, так мы уже перевели это в STAR. Что остаётся, это обозначить для себя, где заканчивается одна часть и начинается другая. Ну и добавить деталей, чтобы это звучало как история, а не голый шаблон. Но это придёт с опытом. Опытом писателя или говорителя.
Итоги:
Насколько хорошо это работает? Мой опыт слишком мал чтобы говорить однозначно, но мне удавалось куда проще впечатлять любую компанию на данном этапе, отплёвывались всегда на чём-то другом.
Разумеется, если роль зовётся "XXL лид разраб на облаке", а ты пилишь мелкие веб приложения, то такой пробел техникой не закроешь. Но можно подать себя более выгодно, если есть хоть какой опыт (именно лидом и именно облако) и ты умудрился попасть на собеседование.
Кто-то обратит внимание, что я привожу в примеры задачи, когда техника подразумевает проекты. На самом деле, она работает в любом масштабе, и я не заметил разницы (буду благодарен если кто-то из внутренней кухни расскажет, есть ли она, и какова).
#4. Задачи и Алгоритмы
Немного метрик. У меня всего где-то 300 решённых задач + кой какой опыт с компаниями ранее. Этого не хватило.
У этого блогера (
) их под 600, и его взяли. Правда, он не только их решал, но ещё и объяснял, и делал видео.Получается, надо додрочить эти алгоритмы как раз до 600 штук чтобы был высокий шанс пройти эту часть (люди с 3000+ решенными задачами за годы, ебать вы высокие). Так ли это - узнаю через пол года/год :)
Есть небольшая разница между компаниями. Майкрософт подбирает задачи из leetcode, а Гугл ещё и добавляет какую-то заковырку.
В последнем этапе у всех трёх есть отдельная комиссия, сравнивающая результаты от кандидатов. Гугл говорит, что они тестируют то, как ты думаешь, такими задачами. На это и был мой ориентир тренировок.
Результат: не хватает эффективности. Решаю я их слишком медленно для формата "45 минут на всё" и запинаюсь иногда. То есть, обратное от того, что говорят, надо именно придрочиться к алгоритмам.
## Язык программирования?
Вообще похуй (с). Писал на своём без проблем. С brainfuck будут проблемы потому, что это brainfuck.
ПыСы: если вы дошли до сюда, то большое спасибо, что прочитали! Я буду рад любой критике, много ли воды, слишком ли разжевывал, чего не досказал, ошибки, может сумбурно получилось или непонятный стиль. Буду даже удивлён если что толковое получилось из этого безумного хаоса мыслей и пережитков.
Тебе фидбэк пришел о том, что именно решения алгосов стали слабым звеном, или это сложившееся у тебя мнение?
Я правильно понимаю что ты под каждую вакансию переделывал резюме и писал отдельный кавер леттер?
Я так делал с другими компаниями в наиболее развитых странах (США, Англия, северные страны, Швейцария). С ChatGPT это стало делать куда проще. Но всё в молоко
HR - сканируют кейворды.
Dev - тут описание проектов, это повод для разговоров и оценки знаний. Но тоже сканируется, так что писать стоит по шаблону: краткое описание, перечень выполняемых обязанностей, стек технологий. Попалоо мне как-то CV челика, который решил, что "им же скучно шаблонные резюме читать" и написал его в форме литературных рассказов - я его ненавидел еще до интервью. Угадайте как он прошел тех. собес?
С интернациональной компании вот есть инфа, что сейчас в США и Канадах всяхик в резюме ни грамма правды нет(вирус про "лайфхаковое" резюме распространился) и прям на интервью приходится узнавать про реальный опыт(был ли он вообще) и что-то спрашивать. Если приплюсовать к этому GPT с его способностью щелкать алгоритмические задачки, я бы сказал, что сейчас умение оценить человека просто с ним пообщавшись - ахренеть ценное. НО! С этой всей толерастией и "эффективностью", компании продолжают идти путем стандартизации и цифровых метрик, где их все больше будет ебать GPT, прочие нейронки и смекалистые соц. инженеры.
Встает вопрос стратегический: хотите ли вы работать в компании, где большинство сидят на своих местах не потому, что они любят свое дело, а потому, что они хорошо умеют наебывать статистические метрики корпы? Я лично считаю, что опыт работы будет сомнительным, а психологическое давление, разрушающее самооценку и нервы, высокое. Нужны вам по жизни разъебанные нервы и умение выживать корпоративных дрязгах?
А вот ценность, как раз, представляют практические знания: проектирование архитектуры, теория сетей, ос и распределенных систем, и прочее, прочее. Увы, менеджерки в погоне за гуглом организовали каргокульт, и вместо действительно нужных специалистов нанимают гениальных сортирователей списков, которые превращают кодовую базу проекта в неподдерживаемое дерьмо, потому что ПРОЕКТИРОВАТЬ они не умеют в принципе. Гугл использует эту методику, потому что богат и может себе позволить найти задротов, нанять их на годовой контракт, а потом отсеять тех, кто не имеет инженерных навыков. Все остальные тупо повторяют за ним, не понимая сути.
Поэтому вроде бы и спрашивали за решения/влияния/метрики
Ну так проверяют как раз это + ещё и сколько человек задрачивал свой навык либо как быстро соображает, что для компании одно и тоже.
К тому же, обзорное знание и понимание нотации, как по мне, тоже недостаточный навык. Чем больше ты задач прорешал, тем выше шанс, что ты столкнешься с какой-то ситуацией и поймешь, что в ней можно применить вс "я пытался в велосипед, потом погуглил алгоритм и сделал ктрл с ктрл в, либо ниасилил".
Причем как всегда в программировании, ты думаешь что тебе не нужна математика, пока ты не сталкнешься с задачей, решая которую ты подумаешь: "а неплохо было бы иметь года 3 математики за спиной", а алгосы и математика идут рука об руку.
Исходя из всего этого, вариант тестировать людей литкодом - далеко не худший вариант
Вообще нет. Проверяют способность решать алгоритмические задачи на скорость. В реальном продакшне не бывает ситуации, когда тебе надо вот прям щас быстро написать алгоритм сортировки, иначе сервис взорвется и компания разорится. Ценность представляет понимание структур данных, умение искать и всесторонне анализировать алгоритмы применительно к предметной области. Иными словами, литкод-задачи не имеют вообще ничего общего с реальностью.
> Чем больше ты задач прорешал, тем выше шанс
Ну вот тебе ситуация. Дан эмулятор клавиатуры, который по какой-то причине не работает в Apple UEFI и не позволяет зайти в его загрузочное меню, а вот в Bootcamp уже работает. Что делать будем? Сколько задач литкода надо прорешать, чтобы разобраться в этой проблеме?
> алгосы и математика идут рука об руку
Я на хабре в похожей теме писал, что это подмена понятий. Инженерное искусство состоит в умении хорошо скомпоновать готовые решения, сделать конечный продукт поддерживаемым и простым в расширении, а так же в умении видеть необходимость оптимизации, когда нужно делать что-то новое. Если готового решения не существует, пойти и разработать свое собственное. Если не хватает экспертизы — посоветоваться с кем-то. Программист — это в первую очередь инженер (как инженер-механик). Есть программисты-ученые (это как физики), которые занимаются computer science. Написание продакшн-кода — это почти несвязанный с этим процесс. Но многие этого не понимают и продолжают нанимать физиков для закручивания гаек.
> далеко не худший вариант
Далеко не, просто один из худших.
Золотые слова. В реальной наботе никому не интересно как эффективно ты сможешь реализовать BFS -достаточно знать что это такое и суметь нагуглить шаблонное решение. А вот понимание того что и зачем ты делаешь (например где надо воткнуть резиленс при запросах к чужому АПИ, где лучше падать сразу, а где надо сразу писать письмо лиду соседней команды с просьбой починить их гребаное АПИ) - дрочение литкода этот скилл дать не способно.
>Дрочение литкода не имеют ничего общего с реальностью
Не смогущий в дженерик алгоритмы человек по какой-то причине должен смочь разобраться в тех же алгоритмах, но присущих специфической деятельности?
Есть миллион областей применения, где дрочения литкода ничего не дает, однако в рамках дать типовую задачу и посмотреть как решает - вполне себе. Всё остальное - это размывание аргумента
Ты подменяешь "базовые знания алгоритмов" на "дрочение литкода". Не надо так.
Потому что потом приходит тело на собеседование с резюме в котором гордо указано количество решенных задач на литкоде, и в итоге при решении тестовой задачи пишет лютейшую неподдерживаемую хуиту и/или неспособно написать xUnit тесты для своего решения.
Не подменяю. Литкод позволяет демонстрировать сказанное.
>Потому что потом приходит тело на собеседование с резюме в котором гордо указано количество решенных задач на литкоде,
Просишь показать решения, просишь решить самостоятельно на время, раз он такой охуенный, получаешь понимание - знает человек алгосы или нет, что и требовалось изначально.
Я вот с ходу от силы тройку названий алгоритмов сортировки вспомнил. При этом мне не приходилось, на моей памяти, ни разу писать руками алгоритмов сортировки, поиска, поиска пути (на самом деле, их даже копипастом практически не приходится использовать).
Если мне понадобится - я загуглю перечень алгоритмов под мою типовую задачу, посмотрю на их сложность и скопирую.
Задачки на leetcode решал. Забавно. Но практическую пользу вижу лишь для автоматизированного отсеивания части народа, который вообще не может ни в каком виде решить ту или иную задачу.
Подтверждаю. За 5+ лет кровавого энтерпрайза с Java не было такой хуйни ни разу. Там скорее - у нас наебнулся проадкшен в 3 ночи, на вот кусок логов, ssh-консоль, 20 минут - ебись!
В геймдеве такого не встречал за 9 лет, чтобы надо было алгоритм знать. Тригонометрия, векторная алгебра или работа с матрицами - да, надо было знать, алгоритмы - нет.
Всё гуглится в момент потребности (а такое ой как редко бывает) - главное знать, что твоя задача является типовой и для неё есть готовые решения. Ну и понимать что такое О-нотация
Straw man argument. Можно перевернуть - уже упало и надо быстро чинить как раз алгос. Смысл таких примеров? Сказать, что надо пойти гуглить готовое решение?
>Ну вот тебе ситуация. Дан эмулятор клавиатуры, который по какой-то причине не работает в Apple UEFI и не позволяет зайти в его загрузочное меню, а вот в Bootcamp уже работает. Что делать будем? Сколько задач литкода надо прорешать, чтобы разобраться в этой проблеме?
Шанс, а не "ликтод покрывает все задачи". Как это в вашей голове вяжется с компонованием готовых решением, я, честно говоря, так же не понимаю. Найти место, где литкод не поможет - проще простого.
> Написание продакшн-кода — это почти несвязанный с этим процесс.
Есть очень разные продакшен коды. Кто-то делает бд, кто-то скручивает железки, кто-то джсоны перекладывает, кто-то перекладывает джсоны в терабайтах, абстрактно говоря. Сужать рамки до "реальный продакшен код" - это no true scotsman аргумент.
Если мне прилетит на код ревью "высокооптимизированное" решение задачи, которое потом невозможно ни сопровождать, ни оптимизировать - то оно полетит в реджект. Потому что если у меня есть задача, которая выполняется раз в неделю в ночь на воскресенье - мне пофиг будет она крутиться 15 минут или полчаса. Мне не пофиг покрытие тестами, и модифицируемость этого решения. Мне не пофиг чтоб эта задача была реализована за день, а не дрочилась неделю.
Если решение не покрыто тестами, то это по умолчанию не решение, так что тут согласен, в реджект и пофиг какое оно там умное или глупое.
>Если мне прилетит на код ревью "высокооптимизированное" решение задачи, которое потом невозможно ни сопровождать, ни оптимизировать - то оно полетит в реджект.
Честно говоря, на этом можно сворачиваться
> надо быстро чинить как раз алгос
Если такая ситуация произошла, то вас всех, фанатов литкода, надо гнать в шею с проекта, потому что вместо того, чтобы рассчитать нагрузку и заранее все расписать, вы наговнякали алгоритмик и прикнули, что и так сойдет. В реальности же, в такой ситуации сервис отключается, анализируются логи, выполняется разбор полетов и уже потом всё это дело фиксится. Если же компания на этом капитально теряет деньги, то сервис не будут стопать, а просто сдеградируют, ограничив хотя бы часть нагрузки. Никто в здравом уме не будет переписывать алгоритм, чтобы не разъебать всё еще больше, потому что последствия могут быть непредсказуемыми.
> Найти место, где литкод не поможет - проще простого.
Проще найти место, где он не поможет, чем то, где поможет. А если он не покрывает даже 1% работы разработчика - он нахуй не нужен. Вон, О-нотация и обзор алгоритмов по кнуту - и достаточно.
> Есть очень разные продакшен коды.
Всё продакшны имеют одну общую деталь: на них нельзя ставить неконтроллируемые хотфикс-эксперименты при аварии. Точка. Это сводит на ноль полезность наговнякать алгоритм за пять минут.
Хотел бы я что-нибудь добавить, но как-то и нечего даже.
Ваш спор выглядит как спор студента-олимпиадника и человека, который непосредственно разработкой занимается
Тут вопрос найти место где литкод поможет. Я за много лет пока не нашёл
с другой стороны задрачивание даже абстрактных задачь таки развивает. Вот я в душе не еду за литкод и пол года тому таки не с первого раза написал А* и алгоритм дейкстры даже с методичкой. С третей стороны - если бы не знакомый студент со своими лабами, я бы вообще никакой а-стар не писал. А с четвёртой - я и не в гуглоле же.
Насчёт развития я вот тут совсем не уверен. Делал только потому что было по кайфу на тот момент сделать. Но не уверен, что это хоть как-то какие-то мои скиллы прокачало.
Именно. Реальность такова
Напрямую «алгоритмическое мышление» мне очень редко понадобилось применять, когда стоят задачи для оптимальных поисков элементов в коллекции, или когда их несколько и комбинируются эти коллекции нетривиально. 3-4 раза в году.
Пересмотрев гайды и видео решения же, я научился… лучше рисовать диаграммы.
А так да, алгоритмы устарели, написать простенькое приложение на хорошем IDE будет куда полезнее. Особенно, когда остаётся куча отчаянных задротов, берущих кол-вом задач.
Система у них в этом плане простая, смотрят у кого лучше результаты. Что, в связке с самими алгоритмами, и делает её такой неэффективной.
реальной практикой во всём этом ёбанном бреде даже не пахнет:
1. кто-нибудь дал реальный код и попросил дописать фитчу или найти баг?
2. кто-нибудь дал устаревшее гавно мамонта и попросил с ним разобраться?
3. когда нибудь вообще имитировали на собесе работу в команде а не тет-а-тет?
или им нужны вундеркинды-одиночки-велосипедописатели с нуля?
Читал/слышал еще про лайфхаки с рефериалкой для североамериканских фирм. Процесс упрощается в разы, если тебя рекомендует кто-то изнутри компании
Хорошо бы компании когда-нибудь поняли, чем они на самом деле занимаются, и искали человека под задачи, а не требовали всё подряд или то что на самом деле в их работе не используется.
Похоже всё как человек выше писал: такие задачки способ найти задротов, а задроты и рады работать больше получать меньше.
Чтобы всё сделать, надо было и реверсить особенности протоколов USB для девайсов, и писать патчи на ядро, и прошивки для МК, и микросервисы на питоне для эмбеддеда, и видеостриминг с нуля на сях, и прочее, прочее. У меня большой опыт в архитектуре и распределенных системах, плюс я линуксоид-олдфаг с нулевых, поэтому осилил.
Короче да, чем больше знаешь - тем лучше. И желательно без привязки к одному языку.
У меня стори не очень ординарная и мне сейчас сильно повезло находится на том месте, где я сейчас нахожусь. Тем не менее, хочу соскочить.
Если кратко: 9 лет работал врачом (я пилил об этом пост где-то год назад), переучился на программиста, почти 2 года на галере писал скрипты на шарпе, недавно меня схантили (буквально 2 недели на новой работе), но тоже ебучие скрипты на шарпе, хоть и платить стали х2.5. Конкретно сейчас учу реакт, потом сяду за го, но соскакивать буду сразу после реакта. Вряд ли тебе такой нужен ))
Но голанг обязательно выучу, это да.
шарп уже выиграл синтаксисом и он идеален во всем
> компилируемость + асинхронность
это плюс го?
серьезно?
не врывался бы с ноги
Один обсирает шарп, другой обсирает го и оба друг друга не слушают )
В шарпах тоже есть асинхронность и многопоточность (вот это да!), но она накручена на него сверху, и это произошло уже после того, как язык полностью сформировался. Подстраиваясь под современные тенденции, Microsoft добавила к своему языку многопоточность, а потом одну абстракцию над ней, потом другую.
Го изначально был спроектирован так, чтобы быть многопоточным. При этом он легко компилируется в исполняемый файл и ему не надо при этом стопицот библиотек весом овер 100мб, чтобы взлететь, он просто компилируется в экзешник и всё.
Ну и остальные штуки по поводу синтаксиса и прочих плюшек, которые изначально закладывались в го.
Ты ему ответил, чтобы он учил нормальный язык. Что подразумевает, что шарп не дотягивает до нормального ))
тоесть этой фразой ты как бы сказал что шарп говно
>Для остальных: в шарпе ничего плохого нет, кроме того, что это цугундер windows-only, в то время как сейчас все среднестатистические бекенды работают на линуксах. И так уж сложилась, что на шарпе под линуксы почти не пишут, за исключением какого-нибудь легаси.
а вот тут как бы полная не проф пригодность твоя
и да, прости, но я увидел твое сообщение которое ты удалил, неужто совесть заиграла? я отвечу мне не западло
> Ты задал вопрос;
задал
> Получил ответ;
получил ответ уровня шарп говно учи другое
> Ответ тебе не понравился;
верно, ответ хуйня
> Ты начал всех хуями крыть.
только тебя
Нет. Ты читать не умеешь.
> а вот тут как бы полная не проф пригодность твоя
Безработный шарпист ты, а профнепригодный я, лол.
> неужто совесть заиграла?
Нет, просто решил быть последовательным и не метать бисер перед свиньей.
> Нет, просто решил быть последовательным и не метать бисер перед свиньей.
чувак, ну это быдлячество с твоей стороны
а по поводу профнеприпригодности он скорее всего имел в виду то, что
шарп уже давно на линуксе (.net core). Лично мне не приходит в голову ни одной причины, по которой стоит выбрать питон, а не шарп на бекенд под линукс
.NET Core, новая (с 2016) экосистема для шарпа, она кроссплатформенна. Работает на линуксе в том числе. На нём довольно просто создавать всякую всячину, в теории. На практике, к примеру лучше использовать ангуляр/реакт как фронт и общаться по REST чем мудохаться с неповоротливыми Blazor и WCF. Но веб АПИ или десктоп делается просто.
Потому, это уже не цугундер только для винды, и не стоит смотреть на него как на говно.
Я учил раст, и пробовал го. В первом делал сервис бас (ну, базу, получать и отправлять эвенты асинхронно), со вторым пробовал делать веб сервис. Работаются неплохо, и много хорошего о них слышал, но у меня мало опыта чтобы судить объективно.
Как бы то ни было, осторожнее со словами. Пренебрежительное отношение к чему-либо - гиблое дело, оно бьёт в первую очередь по твоему комьюнити, отталкивая людей и формируя стереотипы. Я ознакомился с Линуксом лет на 10 позже чем мог бы именно из-за такого
Взял бы шарп, либо тайпскрипт (с го не знаком, но судя по отзывам он неплох). Строго типизированные языки поддерживать в разы проще. Да дистанции поддерживать нетипизированный код - это адище грёбаное. Потому нормальные люди вместо JS юзают TS, например.
При этом шарп не сложен в отличие от плюсов и выразительнее джавы.
> потому питонистов тупо больше, чем шарпистов.
Сложно поспорить, что их больше, но полагаю, что причины не совсем в том, что он хорош как язык, а в том, что ему дохера лет (а из этого следует большое количество готовых решений и замкнутый круг - много питонистов -> часто используется для проектов -> большая потребность в питонистах -> много питонистов).
> А если важна, лучше писать на любом компилируемом в нативный код языке
Шарп медленее плюсов не потому что плюсы компилируемые, а шарп нет, а в основном из-за сборщика мусора. Остальное - экономия на спичках. При первом запуске шарповский код превращается во вполне производительные команды.
При этом шарп не настолько медленее плюсов насколько он их проще.
В питоне строгая типизация.
> ему дохера лет
Лет дохрена, но не будь он хорошим языком, на нем бы не писали. Вон, Ruby почти его ровестник, моложе года на четыре, но никому не нужен по причине отбитого синтаксиса и более медленного развития. Главная фишка питона тех лет, имхо - при сильной типизации он сохраняет возможность жонглирования объектами, за счет чего получается писать более компактный код бизнес-логики.
> Шарп медленее плюсов не потому что плюсы компилируемые, а шарп нет, а в основном из-за сборщика мусора.
В го тоже сборщик мусора, но работает он все равно быстрее, и при этом его сильно проще деплоить, потому что это один статический бинарник. Плюс богатые средства отладки и очень быстрая асинхронность из коробки.
пардон. я про явную
ну и то, что оно навернётся в рантайме сильно ситуацию не спасает. Нужно чтобы ругалось до выполнения.
> Лет дохрена, но не будь он хорошим языком, на нем бы не писали.
Javascript *картинка с плюшевой обезъянкой*
На выбор языка для проекта то, "хорошй" язык в вакууме или нет влияет далеко не в первую очередь.
Тот же джаваскрипт при всём удобстве "жонглирования" объектами для больших проектов использовать нельзя ни в коем случае.
> В го...
Не щупал его. Возражений не имею, вероятно это хороший выбор
А вот в жс динамическая слабая типизация, буквально худший вид из четырех возможных вариантов. Тс фиксит это, но под капотом это все тот же угребищный жс.
Чтобы питон не ругался на типы в рантайме, были придуманы аннотации. Если ты реально пишешь код с аннотациями и затем запускаешь mypy, то он отловит тебе все ошибки типов еще на этапе разработки. Это особенность питона: когда делаешь проект, сразу к нему подключаешь pylint+flake8+mypy+vulture - и всё, тебе ничего больше не страшно. При этом динамическую типизацию у тебя никто не отбирает, и если очень надо - можешь пожонглировать объектами.
А ещё явная/неявная, при том, что хоть она статическая или динамическая, хоть сильная или слабая
> Тс фиксит это, но под капотом это все тот же угребищный жс.
Под капотом да. Но если ты принудительно не отключишь валидации при сборке и не натыкаешь any в код, то о косяках с типами узнаешь из IDE, а не в рантайме.
> Чтобы питон не ругался...
> когда делаешь проект, сразу к нему подключаешь...
Звучит убедительно
> Звучит убедительно
Справедливости ради, линтеры надо использовать вообще с любым языком и проектом.
эт, если чё, без иронии было
Но часть про шарп на беке актуальна
Я знаю человека, который будучи вообще далеким от ИТ, успешно пилит свое приложение (которое в топе АппСтора). Причем ни строчки кода она не написала - от нее были классная идея и маркетинг. И все пошло Настолько успешно, что уже хватает на зарплату команде. Но вот незадача - 99% таких проектов тихо дохун, попутно высосав все деньги.
И кстати
> Но вот, допустим, я выучил react native какой-нибудь, тайпскрипт, nodejs, postgresql, линукс, гит, английский хорошо знаю, почему я должен куда-то идти устраиваться джуном, чтобы там за копейки пахать?
Потому что нихуя ты не выучил. Никакие курсы или самообучение не заменят реальный опыт.
Реальный опыт - это когда у твоего проекта есть пользователи. Когда появляются фичи, которые они хотят но ты не очень хзнаешь как реализовать. Просто пока ты делаешь "для себя" - ты подсознательно будешь избегать вещей которые ты не умеешь. А без челленжа не будет развития
> Хуй, никому не интересно
Сам спросил - сам ответил
Не хватает знаний во многих сферах. В том числе в маркетинге, разработке, тестировании. Ну а самое главное, в предпринимательстве. Если ты будешь знать, что производить, то остальное приложится: и работники, и инвесторы.
В большинстве своем любая стажировка - это хорошая строчка в резюме.
но если у тебя куча строчек где ты сделал то, се но на себя, а не на компанию - у тебя должен быть очень крутой собственный проект, который должен быть признан остальными.
либо же у тебя должен быть какой-то раскрученный проект, на котором висят не полтора полумертвых юзера - это покажет твои скиллы + ты на собесе сможешь их подтвердить реальным написанием кода или хотя бы досконально рассказать про то как твой код работает.
если я правильно тебя понял то мой ответ таков - то все домашние заготовки, которые ты просто писал для наполнения гитхаба - это полная херня потому что всем на них плевать, это не реальный опыт.
но это охренеть какое исключение из правил.
Но ты получишь знания создания своих приложений. Это бизнес.
И как любой бизнес, он потребует вложений. То есть, ты не будешь ишачить за малые деньги, но вложишь свои. Тебе потребуется хостинг или заход в магазин мобильных приложений. Также реклама. Так что тебя ждут сложные времена и финансовые потери.
А ещё, чтобы что то нормальное написать и ещё и работать при этом, ты потратишь года 3-4. Пока разберёшься с фронтом, бэком, базами данных, безопасностью и т.д. без отрыва от электрода, так сказать.
Основная проблема которая у меня была - не рубил в маркетинг и прочее. Просто по сарафану приходили.
когда устраивался на тестировщика-автоматизатора, то брали меня отнюдь не джуном.
знаю народ, который сам учился и что-то свое делал - и у них получалось.
Что уж говорить о рядовых исполнителях, которых сегодня попросили эту фичу реализовать, а через полгода скажут ее удалить) ну и при этом доступа к финансовым и аналитическим данным у них нет.
Чтобы метрики вели и штат аналитиков был, я видел только в крупных и сильных продуктовых компаниях - на моей памяти таких 2: топы в своем сегменте и со штатом больше 1000 человек
У клиента велась статистика температуры нескольких котельных, и база за неделю собирала порядка 50 Гб данных, после чего перезаписывалась циклично. Увеличивать размер бд они отказывались, а архив требовался хотя бы на месяц. Я исследовал хранимые процедуры записи данных и обнаружил, что настройка точности после запятой работала только на выдачу результатов хранимых данных, а писались они в базу типом vchar с точностью до 20 знаков после запятой. Переделал процедуру на требуемую точность (1 знак после запятой), отдали клиенту, он был доволен.
Из того что я знаю, как этот кейс нам помог - удержание клиента и перевод ещё части автоматики на наше железо - суммы и всего остального не знаю, какой тут результат?
Специфическая часть оборудования, отвечающая за работу с сетью периодически выходит из строя (самая уязвимая для наводок и скачков напряжения часть). По факту, у нее лишь слетает прошивка, но мак в неё зашивается на производстве, и для ремонта нужно отправлять ее на завод. Я поискал в исходниках программы для прошивки, нашел схему формирования (привязанную к с/н) мака и адрес его хранения. Выяснил у одного из разработчиков железа распиновку и необходимый программатор. Снял дамп прошивки с работающего устройства, и подправляя ручками мак в дампе, восстановил несколько устройств. Написал инструкцию, и восстанавливал их на выезде, вместо отправки на завод.
Тут вообще идей нет, какой результат? По факту только экономия времени на транспортировке, получается что хуйней занимался?))
Кейс 1:
Крупный и важный клиент хотел уйти из-за ограничений в вашей инфраструктуре. Насколько крупный? Трафик данных и тот факт, что срочно понадобилось менять инфраструктуру, и был ощутим рост давления и нервняка,, значит клиент был важный и крупный.
Задачу ты описал.
Что ты сделал, ты описал. Добавь, что ты предложил решение, или участвовал в этом, это было непросто, но ты разработал план/помог разработать план/понял срочность и важность проблемы и взял лидерство на себя т.к. ты лучше понимаешь систему (а.к.а. кто если не ты). Это выставит тебя в выгодном свете, как умеющего общаться.
Результат: Ваш софт стал в 4 раза экономнее (ты сам сказал про раз в неделю и раз в месяц), а так же этот клиент остался довольным, что успокоило сотрудников других команд/департаментов в твоей компании, убрало давление с тебя и твоей команды. Ты точно не знаешь, как финансово это отражается, но все эти косвенные данные (перечисленно в начале) говорят о том, что финансовый интерес был серьёзный
Судя по всему, ты работаешь в инфраструктурной части, здесь моя слабый.
Ты уже описал задачу и решение (добавь часть про коммуникации, как с предыдущим примером). И даже немного ситуации, с периодическим выходом из строя.
Ситуацию можно развернуть. Какие были последствия у каждого такого выкрутаса? К примеру, не работало ваше приложение (внутреннего или внешнего потребления? Кто ей пользуется?), или вообще вся сеть выходила из компании и она вставала. Как часто это происходило?
Результат: «прошло n лет и с тех пор я о выходах не слышал». Что очень сильно повлияло на производительность (как? примеры?), внешний вид как стабильной компании, внутреннюю культуру (все стали спокойнее с надёжностью нашего софта).
На самом деле, насколько я могу понять, у тебя очень сильные кейсы. Как по мне, тебе стоит их чуть доработать. Как? Задавай себе такие открытые вопросы, и пробуй на них отвечать как получится, по наитию. Можешь уточнить что с коллегой или менеджером.
1. хранимые процедуры были написаны клиентом или это было в составе вашего софта? Если второе, то это пипец и репутационные риски, что архивный тренд сжирает столько места, что хватает только на неделю, а на настройки точности не реагирует . Тут помимо удержания существующего клиента еще спасение от потери потенциальных клиентов. Если первое, то ты сам написал - клиент доволен, остался и докупил еще. Кстати, по поводу цифр можно попытаться спросить руководство или коммерческий отдел, сколько это принесло прибыли.
2. Тут экономия времени не на транспортировке, а на времени простоя системы у клиента. Ведь без сети как минимум не работает диспетчерский уровень, а как максимум - недоступна часть оборудования или вся система. Так понимаю, что вы быстренько меняли вышедшую из строя железяку на рабочую, а эту отправляли на завод? А что если запасной нет? А сколько их надо было иметь в запасе, если вдруг выйдет из строя в нескольких местах? То есть, тут либо надо было иметь запасные части, которые стоили денег и без дела лежали на складе, либо рисковать, что у клиента встала система, а части еще не вернулись с завода. Получается, ты убрал риск стопора системы у клиента (а это возможные штрафы и репутационые потери) + сэкономил стоимость дежурных запчастей, так как можно железку восстанавливать сразу.
ЗЫ: ностальгия: когда-то сам сидел в котельной с пусконаладкой, а пензенский "Круг" подарил мне диплом и хорошую клаво-мышь за то, что частенько придирался к их системе и указал на критичный баг)
Пожил в Питере, там смешная реакция: "Ты где учился? В политехе. Оооо! Не, не здесь, в своем местном. Ааааа..."
Короче, как я понял, навык регулярно отмечать не только действие, но и его результат/влияние - отличный навык ) может быть, для начала без финансовых показателей, но хотя бы уже просто прицел внимания на результат - уже хорошо.
в основном только отказы, до собесов н едохит
додики по базам вопросы даже не задают
зато каждый спросит про солид...
Для остальных: в шарпе ничего плохого нет, кроме того, что это цугундер windows-only, в то время как сейчас все среднестатистические бекенды работают на линуксах. И так уж сложилась, что на шарпе под линуксы почти не пишут, за исключением какого-нибудь легаси.
С подключением, шарп кросплатформенный с 2016 года. 80-90% вакансий на шарпе нынче подразумевают что большая часть кода крутится под линуксом.
- Python: 5762 вакансии;
- C#: 1254 вакансии;
- C# Linux: 195 вакансий.
Так что нет, на линуксах шарп почти никому не нужен, потому что есть более нативные и удобные средства разработки. Повторюсь, пишут на нем только всякую банковскую и околобанковскую поебень. Если повезет - игры всякие.
Ну я и так-то на подключении, да. Архитектор ПО + эмбеддер/ядерщик/бекендер.
Очень даже значит. В вакансии, как правило, пихают все скиллы, и даже больше, которые потребуются для работы. И девопсу (не люблю это слово) рано или поздно потребуется влезть в условный терминал, если у него проект на линуксе. Даже если умножить результаты поиска на два или на три, они все равно неутешительны.
> уже на начальном этапе предлагает встроить приложение в докер
Хорошо. Мы начинаем новый проект на шарпе под линукс - чтобы что? Какие плюсы он дает по сравнению, например, с голангом?
Я за всю свою карьеру не встречал новых проектов, которые целенаправленно пишут на шарпе под линукс, потому что, повторюсь, под линукс есть средства и получше. Это, на самом деле, довольно важный аргумент, потому что с учетом малой распространенности этой хуйни под линуксом, при возникновении нетривиальных проблем ты останешься с ними один на один, ибо коллективный разом на стековерфлоу тебя уже не спасет.
то что ты не знаешь как развивается шарп последние 5 лет, показывает что ты нихуя не знаешь
продолжай дальше писать на питоне, потом главное не удивляться что все работает со скрипом
И ещё раз по поводу шарпа - практически все приложения пишутся как минимум на .net core 3.1, а всё что младше (типа .net framework) - это ебучее легаси, которому в лучше случае 10 лет и который скорее всего является каким-нибудь десктопным приложением типа wpf или winforms. Всё более менее современное в пару кликов собирается под linux.
Liksys, я не посягаю на твой опыт, но твои взгляды на шарп сильно устарели и являются пережитком прошлого, стереотипами и прочими ограниченностями кругозора.
я заебался дебажить проект в котором я хуй знает что приходит, и может быть пойму что уходит из метода
потому что что? правильно у нас типизация в одном месте
как реализован гет и сет в питоне? а никак костыли да и только, классы кстате так же, как и весь ооп который прикрутили гвоздями
питон популярен только лиш на нем написали кучу всякой хуйни и это основной язык нейронок
плохой язык? нет, но ну сука подгорает от мамкиных пограмистов которые приходят в тему с шарпом и делятся своими нинужными мыслями что язык говно, патамушта он его не знает значит говно
Предъявляй претензии или к проекту, или к своим компетенциям.
> питон популярен только лиш на нем написали кучу всякой хуйни и это основной язык нейронок
Питон почти ровестник перла, если что. И популярен он из-за того, что на нем легко писать крупную логику, благодаря богатым встроенным типам и легкости отладки.
Тебе вопрос был задан про шарп не из-за того, что он говно, а потому что быть программистом-на-языке - это самый небезопасный способ работать. Чем больше у тебя теоретических знаний и опыьа с любыми языками - тем лучше, потому что ты можешь выбирать язык под задачу и адаптироваться к новому проекту, если захочешь его сменить.
А ты сидишь с шарпом и, судя по твоим высказываниям, околонулевым знанием теории, кроешь хуями всех, чьи высказывания тебе не нравятся, и не можешь найти работу. Ничего в башке не щелкает?
а виноват я?
дядь все нормально?
> Тебе вопрос был задан про шарп не из-за того, что он говно, а потому что быть программистом-на-языке - это самый небезопасный способ работать. Чем больше у тебя теоретических знаний и опыьа с любыми языками - тем лучше, потому что ты можешь выбирать язык под задачу и адаптироваться к новому проекту, если захочешь его сменить.
На самом деле я нихуя не удивлен, что у тебя нет работы, ты же деревянный блядь.
такое общение потеряли
- java: 6139 вакансий
- java linux: 1385 вакансий
о боже, что же это за java, у которой не указан linux - неужели на windows?! )))
ну и по аналогии: нафиг питон, возьми нормальный язык для бэка типа java )))
Чувак, я уважаю твой опыт, что ты уже архитектор, но, как видим, ты глубоко погряз в эмбеде и ядрах, что не замечаешь вокруг, что происходит на бэке на других платформах.
Да, C# менее популярен, чем JavaScript, Java и Python, но он все еще в первой 5ке или хотя бы 10ке, так что, почему бы нет? Кстати, знаю 2 случая, когда в острой нехватке кадров, брали шарписта разрабатывать java-бэкенд )
> почему бы нет?
Как я писал раньше - потому что при возникновении специфических проблем ты останешься с ними один на один, и никто тебе не поможет. Доступность разработчиков - очень важный аргумент. Ну и опять же: если у тебя io-bound, то можно использовать плюс-минус любой распространенный язык, включая питон, а если cpu-bound - то уже придется компилять и экономить на спичках. Шарп нужен для чего-то среднего, но как-то не складывается, обычно задачи сваливаются либо в первый тип, либо во второй.
А про io/cpu хорошо, что хотя бы здесь пояснил) могу согласиться, обычно выбор либо C++, либо java/python.
Но есть же еще и менее популярные Ruby, Scala, Rust и иже с ними - и ничего, живут же люди, что-то кодят, сообщества развиваются) Так что вопрос больше про уменьшение хлопот и толщину колбасы в бутерброде.
А вот Rust - вообще отдельная песня. Чисто синтаксически он мне очень не нравится, но его преимущества очевидны. Самое интересное то, что иногда в хайлоаде случается ситуация, что GC создает слишком много проблем. Тогда лучше взять что-то с ручным управлением памяти и более понятным профилем нагрузки. На плюсах писать - это боль и страдания, на сях - требует очень высокой квалификации и дорого. Остается разумный выбор в виде раста. Вот пример: https://habr.com/ru/articles/487116/
и ниодна буква не будет работать
а можно потратить месяц на архитектуру и сделать хуйню которую на следующий день придеться переделывать
так и тут вопрос, работает первая буква или нет? или она работает иногда?
все эти принципы не более чем свод правил, к которому надо стремиться, но не следовать
Так не трать месяц на архитектуру того, что можно описать простым образом. Солид не про преждевременный овердизайн.
Солид нужен для того, чтобы ты знал о типовых проблемах проектирования, как их решать (хоть заранее, хоть по факту возникновения).
А там ты уже сам с высоты своего опыта решаешь, насколько вероятна та или иная проблема, а не бездумно следовать всем буквам.
В нормальных источниках помимо самих принципов ещё пишут что будет если с этими принципами переборщить (гугли Теплякова, там хорошо написано).
Когда я видел классы в 1000+ строк, делающие дофига чего, мне хотелось тыкать лицом народ в распечатку солида. А человек, доказывающий мне, что этот солид нафиг не нужен, продолжал дописывать в эти классы, да так, что у них уже кольцевая зависимость образовывалась.
Для первой, тебе куда важнее построить резюме, перечислить что ты делал. Помимо тех стака (ну на чем писал), я бы порекомендовал описать своё приложение как решение проблемы (как - см. примеры в посте). Если этого ещё не сделал, то закончи и выстави в обозрение свой проект (пусть хоть это онлайн калькулятор будет), чтобы с ним поиграться можно было.
Остальное (star, алгоритмы и т.д.) на этом этапе откладывай в долгий ящик. А «настоящее программирование» вообще шли нахуй вместе с теми, кто так говорит, Термин не несёт ценности, только токсичен и всё
Для первой я пришёл прямо с института. Не подходил ни по одному пункту из вакансии, вплоть до требований к ЯП. Но они искали лоха на место, а я лоха, который будет мне платить. Сошлись, так сказать.
>>А «настоящее программирование» вообще шли нахуй вместе с теми, кто так говорит
Это так кажется только когда ты не щупал дно. Мои 3 года опыта почти бесполезны. И я бы не хотел возвращаться туда, где они могли бы пригодиться. Помимо всех этих FAANG, компаний поменьше, и мелких контор, есть всякие гос структуры, есть заводы, где программисты варятся, можно сказать, в иной среде. Они застряли где-то на рубеже 2000 года. Буквально. Я работал на C++ Builder 5.0.
Я вылез из этой задницы, и сейчас открываю для себя новый мир. Вроде опыт и есть, но всё познаёшь с нуля. Два разных мира. Взять тот же Git. Я только пару месяцев назад впервые им воспользовался.
>>закончи и выстави в обозрение свой проект (пусть хоть это онлайн калькулятор будет)
Сейчас играюсь с Golang, пишу бота для телеги. ChatGPT и всё такое, ну и пара других фич. Но не думаю, что сгодиться для портфолио. Да и написано оно не так красиво.
Уже давно есть куча идей для нового проекта. Большого. Где полноценно вылизывать структуру, приводить код в порядок и т.п. Но сперва бы бота закончить, а время идёт.
Открою тебе страшный секрет. Даже те кто в индустрии четверть века, иногда пишут говнокод. Особенно если это старт проекта и пока делается прототип.
Реализуй функционал. Посмотри на код. Отрефактори в красоту. Пойми что рефакторинг - неотьемлемая часть процесса написания кода. Никто не пишет красиво стразу.
Если стоит задача рубить бабосы, то лучше выучить IBM i и попытаться залететь в какой-нибудь американский банк, специалистов по этому говну крайне мало, а платят дохрена.
IBM предлагает множество различных продуктов и решений, которые используются в банковской отрасли в США и по всему миру. Некоторые из этих продуктов и решений включают:
1. IBM Cloud: Многие банки и финансовые институты используют IBM Cloud для создания и поддержки облачных приложений и сервисов.
2. IBM Watson: Платформа искусственного интеллекта Watson используется для автоматизации и оптимизации различных банковских процессов, включая обслуживание клиентов и анализ данных.
3. IBM Financial Transaction Manager (FTM): FTM - это программное обеспечение, которое обеспечивает централизованное управление всеми финансовыми транзакциями, которые проходят через организацию.
4. IBM Security: Помогает защитить ценные данные банка, включая личную информацию клиентов и финансовые транзакции, от угроз и атак.
5. IBM Z: Мощные мейнфреймы IBM Z используются для обработки больших объемов транзакций и данных.
6. IBM Cognos Analytics: Программное обеспечение для бизнес-аналитики, которое помогает банкам анализировать и интерпретировать финансовые данные.
Это лишь некоторые из продуктов и решений IBM, которые могут быть внедрены в банках. Реальное использование зависит от конкретных потребностей и целей каждого отдельного банка.
ты так говоришь, как будто большие компании - это что-то хорошее
Я чем больше работаю, тем больше ебал идти в какую-либо контору на 1000+ сотрудников.
Хотя иногда там зарплаты больше, но это если сравнивать с совсем маленькими компаниями (или если у тебя в подчинении людей по размеру штата небольшой компании)
Сам пользуюсь этим подходом, что бы понять, что за кандидат передо мной.
Не все понимают, к сожалению что мало сделать что-то крутое. Надо еще про это уметь рассказать.
мне дали задание сделать ускоритель нейронки, я сделал за год, быстрее в N раз и влазит в плис дешевле M раз чем обычно, но надо в K раз больше времени потратить. Вопрос как подсчитать трейдоф если например K не понятен?
т.к. до практики не дошло и в релиз не выкатили а тупо забили?
И вот таких вот дропнутых либо в конце либо вообще на стадии RnD решений у соискателей НАВАЛОМ. И в этом часто и смысл работы - попробовать вариант и вовремя от него отказаться (пока с этим вариантом занят один сотрудник) чтоб не нарваться уже целой командой или фирмой на нерабочее.
А STAR это подход для проверки соискателя именно на них. Я курсы по применению STAR проходил - знаю о чем говорю.
Вот пример реальных вопроса по системе:
"Приведи пример ситуации из своего опыта, когда твоя команда не успевала в срок. Как ты действовал?" И ответ - больше и усерднее работал будет жирным минусом, говорящим что софтскил работы в команде у тебя нулевой. Правильным же ответом будет что-то вроде: поговорил с коллегами, прикинули как лучше распределить задачи. Сам взялся помочь с товарищу, у которого случился ступор. Подбадривал команду. Договорился с заказчиком о сдвиге сроков.
Или “Приведи пример из своего опыта, когда ТЗ от заказчика было не полным или противоречивым. Как ты действовал". И акцент всегда на реальную ситуацию из твоего опыта. Начнешь плавать и говорить общим описанием алгоритма действий - сразу минус. Лучше честно сказать что с таким не сталкивался.
есть мир с радужными пони, где бывает иначе? )
ты обязан врать ибо если раскажешь правду или расскажешь как правильно действовать в той или иной ситуации то тебя точно не возьмут. особенно красный флаг: "была проблема, я понял её и профиксил задокументировав", а как же митинги, обсуждения, софтскилы?
а не "замешкался - сразу минус" (см выше), а если у человека икота? Или просто не привык болтать вперёд мыслей?
А то потом нанимают отличных спецов по прохождению собеседования и ноют что они в прочим спецы похуже чем первая и основная (порой и единственнаях) их специальность.
Встречался я с такими переговорщиками... Один раз даже тех специалист был неплохой, остальные два раза мне досталось в наследство от них тонна очень дурно пахнущего кода (аля литкод высер с переменными типа имён map, dp).
По этому зачем брать хорошего тех спеца, который закроется от всех и будет что-то там сам себе делать, если можно взять хорошего тех спеца, который органично вольется команду и будет вместе с ней тащить?
1. Это было до глобального фриза в IT? или уже после?
2. Предположим у вас есть кандидат который чуть ли не угадывает вопрос до того как вы его задали, и не набрал ни одного минуса / заметно меньше всех остальных. Ваши действия? брать?
3. Ошибки в вашем коде убъют много человек? Исправить в принципе можно или на исправление потратить надо не 2 года написания а четыре? принесут миллирдные убытки?
4. Даёте реальный кодинг? не только задачки с нуля написать, а например вот тебе кусок кода чужой, найди баг, поправь доку (самые страшные ошибки здесь, убивают тысячами), добавь функционал? Как много кодеров в этом участвует? больше одного?
Почему спрашиваю?
Все мы разные и хочу понять где такие условия и почему такие требования (и часто они обоснованы реальными обстоятельствами против которых не помудишь на реакторе)
1. Кардинально ни чего не поменялось, но то в Европе
2. Тут не понял. Я всегда четко разделяю хард скилы и софт скилы. Конкретно в мой отдел нужны люди у которых хорошо и то и то, так как работа заключается не только в том, что бы самим хуячить, но и помогать и кординировать другие отделы. Если это вакансия какого-то узкоспециализированного системного прогера, то там уже 80% веса хард скилов и 20% софт. И там вполне могут закрыть глаза на пробелы по софт скилам.
3. Не убьют, но по серьезный косяк, скажем в серверной части, может не хреново ударить по прибыли.
4. Так не упарываемя. Чаще всего даже нет тестового задания. Где-то час общения за техническую часть достаточно что бы понять что за специалист перед тобой. Иногда можно спросить что-то узкоспециализированное, если видно что человек хорош. Ну а далее уже проверка на софт скилы. Если подходит, то сравниваем с прочими кандидатами и далее оффер и испытательный срок. Мы не гугл что бы устраивать бессмысленные фильтры)
Да и ошибки в коммуникации частично покрываются тотальной проверкой кода, документации и кучей разнообразного регламента. Начиная с ТЗ заканчивая каждой строкой кода идёт доказательный подход - ты обязан доказать что это будет работать и порой не одной комиссии, но как минимум одной государственной точно. (без связи гос-во перестанет существовать, это на тяп ляп, потом профиксим, который часто бывает в IT не позволят)
Точно, систем дизайн тоже был раз, когда я шел в Амазон. Совсем забыл. Но я снизил чуть планку до мидла, мне важнее пройти, внутри компании карьеру делать проще, до мидла Гугл упразднил систем дизайн.
Тема интересная и очень полезная, как по мне. Учит архитектурному мышлению. Но это целая наука, о ней можно статей десяток напилить
первое по специальности, второе как минимум бакалавриат по прохождению собеседования, навыков продажи себя и решения формул уровня dp(bullshit) mod (10e9+7) = leetcode