Обновить
61

Architect | Lead | Senior Developer

0,7
Рейтинг
13
Подписчики
Отправить сообщение

Новые перлы подъехали от зуммера айтишника, который не смог в программирование и его перевели в qa

  1. Признался, что у него не хватает знаний, чтобы протестировать csv файл после нажатия кнопки export на экране списка

  2. Записал в багу красные звездочки у обязательных полей, объяснив это тем, что «неконсистентно, звездочки должны быть на всех полях»

И теперь старший QA миллениал сидит и отлавливает эту дичь.

По-моему читается немного надменно, хотя и наполнен юмором. Токсичный - это общее слово для таких случаев.

Если компания/соискатель не имеет проблем с поиском сотрудника/работы, то подобные "отзывы" никого не заденут, а только могут оставить осадочек.

Если же проблемы имеются - это со стороны тоже выглядит не вполне адекватным. Типа когда на сайтах знакомств пишут девкам, они не отвечают, а потом им вдогонку "ну и дура".

Чтобы сделать мир лучше конкретно в этом - я считаю, что надо заходить с другой стороны. Если некто участвует в найме - то улучшать процессы найма и свое поведение, начиная со своей компании. Если есть силы и время, то выводить это в публичную сферу - участвовать в конференциях и доносить свои мысли, идеи, эксперименты, достижения и факапы до общественности.

Нужно учитывать - рынок работодателя или работника.

В России пока еще рынок работника, но все движется в сторону рынка работодателя.

На западе - рынок работодателя и разослав 100 откликов можешь даже не получить никакого ответа - и некому будет писать свой «отказ».

А так в целом - году в 2019 искал работу, и мне приходилось им отказывать. Но делать это в токсичном виде - зачем?

Куча откликов - это же куча данных и потенциал для социальной чатгпт инженерии.

Помнится мне раньше попадались вакансии с текстом «начните свой отклик с кодовой фразы».

Дальше не буду подсказывать, но вы можете нанять соответствующих людей, в том числе и айтишников, для решения этой задачи. Больше вакансий - меньше откликов 🙂

Господи как вас только на Хабр пустили с рекламой этих человейников с комнатами по 11 метров за баснословные деньги.

Не могу согласится на 100%. Работа для разных ролей - разная.

Когда мы на работе обсуждаем фичи у доски с фломастером в руках - мы тоже работаем, но эффективней это делать в офисе, а не online.

Создаем ли мы новое? Я думаю да. Эти обсуждения потом лягут основу конкретного решения, которое будет реализовано в коде.

Вот это холивар, провокационная статья-мнение 😅

Работники хотят поменьше работать, работодатели побольше, на уровне закона определено 8 часов. Но в частных конкретных случаях все по разному.

Это выливается в то, что часть людей работает крайне неэффективно и работодатель пытается придумать способ заставить их работать. Одним из способов может является офис.

Другая часть людей - проактивных, заинтересованных - они в целом работают всегда плотно, что в офисе, что на удаленке. Могут быть особенности - типа в офисе ему легче включится в работу, с плохим самочувствием производительность снижается и т.п. Отсюда то негодование у некоторых комментаторов.

Ну и плюс к этому еще пара-тройка моментов:

  1. Вкатыши, которые пришли за деньгами, а тут оказывается работать надо

  2. Смена поколения? (немного терли тут https://habr.com/ru/companies/agima/articles/884270 )

  3. Кодить действительно лучше в тишине, а вот обсуждать и планировать - лично. Работа архитекта - это уже ближе к обсуждению и планированию

  4. Ну и собственно сам Сбер - куча историй о том, как новым сотрудникам по три месяца доступы настраивали

У меня на ладони лежит очень горячий сотовый телефон, который разогрелся из‑за того, что мессенджер отображает статичное сообщение с пузырем и текстом на экране при помощи браузерного движка и безумного количества сторонних библиотек

Да, это действительно боль - когда открываешь какой-нибудь сайт, где рекламы больше, чем полезного контента и смартфон начинает жрать батарейку как не в себя. Бесит. Надо их всех запретить в выдаче поисковиков для мобильных бразуеров, чтобы у владельцев этих говно-сайтов упала посещаемость и они озаботились оптимизациями.

Давайте не будем путать и поддаваться.

Тим-лид - это не лидер проекта, это лидер команды: найм, онбоардинг, развитие навыков, решение конфликтов, и тому подобное. Он не кодит и не делает таски из жиры и несет ответственность перед дедлайном опосредованно.

Я крайне редко встречал правильные вакансии тим-лидов. Обычно компании экономят и обзывают людей, кто решил бы все их проблемы - тим лидами, тех лидами, ведущими и прочее. И вешают на них всех собак.

И я согласен с тем, что не все такие.

Это те, кого этот мир сформировал

Этот мир сформировали предки зуммеров. И в руках последних сделать его лучше

что зумеры не хотят работать, строить карьеру, думать о будущем. Но позвольте спросить: а какое будущее им предлагается?

Но с таким подходом - думаю ничего не выйдет.

По моему опыту собеседований на стороне нанимающего - осознанные ответы и решения - от 10 лет.

Я бы еще добавил опыт долгосрочной поддержки продукта - одно дело написать софт, сдать в эксплуатацию и забыть. И другое - поддерживать и дорабатывать все это дело, не скатываясь в говнокод.

Тоже хотел вставить скрин из my sql - я несколько раз напарывался на это, когда случайно забывал добавлять колонки в group by - оно работало без ошибок, но выдавало дичь

Дичь. Было две статьи. см скрин.

Первую заминусили и там был первый комент от @FanatPHP, который при мне набрал 27 плюсов. Первая "статья" заслужено получила минусы. Но она была удалена и осталась только эта "статья" с плюсом и она продолжает их набирать.

Вот есть сила пикабу, а тут надо силу хабра.

Давным давно я работал тех лидом. В те времена тоже были джуны, мидлы и сениоры. Я раздавал задачи, делал код ревью, помогал, отвечал на вопросы. Я мог делегировать задачу, даже джуну, обозначив рамками место, куда он должен интегрировать свой код с прописанным контрактом.

Сейчас на мне формально нет лидерских обязанностей, но волей не волей приходится взаимодействовать с людьми. И современные реали и для меня стали совсем другими. Возможно это из-за смены поколения, возможно из-за вкатышей таксистов/курьеров/поваров. Но эти люди

  1. Пишут код и приходят с вопросом почему у них там эксепшен - они сами не собираются тратить свои силы и время раскапывать то, что они там сами понаписали

  2. Не способны к обучению - они раз за разом натыкаются на те же грабли, каждый раз приходят за помощью по одним и тем же вопросам - и даже я, кто не делает их задач, помню, что они уже напарывались на такое или уже решали эту задачу, а они этого не помнят!

  3. Не способны коммуницировать - только на третий возврат задачи из тестирования по поводу блокирующей баги этот человек говорит, что она у него не воспроизводится.

  4. Когда они говорят что сделали, но на самом деле ничего не сделали

  5. Отсутствие элементарного логического мышления у программиста! Абстрактное мышление для них вообще высший класс

  6. Они не могут за один раз пометить поля на форме обязательными с валидацией. Как будто они впервые видят интернет, формы логина и пароля и никогда этим не пользовались.

Все что описано в статье - у меня работало в те далекие времена. Сейчас же, в обозначенных выше кейсах - действительно лучше таких уволить и все сделать самому.

Слишком много моего времени уходит на такое «менторство», на микроменеджмент, чтобы не допустить всякой очевидной для меня дичи.

Джуны и мидлы в давние времена - были взрослыми людьми. Современные джуны, мидлы, и те, кто идентифицирует себя сениорами - мамкины детишки.

У вас на картинке в последних двух вариантах тестирование отвалилось

Я бы сказал, что на больших объемах думают в сторону гибридного формата - Pk, fk, поля индексов - как обычно, а остальные поля в json колонке. Добавление новой колонки в большую сжатую таблицу занимает несколько часов. А в json - бесплатно.

А что касается потоков - возможно у них была реальная задача, которая потребовала такого подхода, но для меня это больше как головоломка.

С 9 вопросом не понятно, наверное имелось ввиду работу напрямую с бд без репозитория? Ведь тогда контроллер все равно будет делать две вещи - обрабатывать http запрос и вызывать бизнес слой 😅

Автору спасибо - объемный труд.

Холиварная статья 😅 щас тут все разнесут.

Кстати они тоже спрашивают про хешмап и вопросы из справочника (контракт equals и hashcode), не любимым многими.

Лично я осуждаю (но детали я пока не читал) вопрос про преимущества монги перед mysql - если начать маньячить, то из mysql можно попробовать сделать монгу - json тип колонки есть, хеш индекс есть, а еще и классический ACID будет (не помню в монгу его уже завезли или еще нет).

PS: прочитал детали, ну половина там дичь написана. Допускаю разве только более широкую поддержку json и bson, и операции над ними плюс аналитика и геоданные. Кстати про транзакции в монге - ни слова.

А самый интересный для меня вопрос - про два потока и a b c 1 2 3

Информация

В рейтинге
2 293-й
Откуда
Россия
Зарегистрирован
Активность

Специализация

Бэкенд разработчик, Архитектор программного обеспечения
Старший
C#
.NET Core
SQL