Comments 33
об эксперименте, в ходе которого детей заставляли решать задачи,
Это не про упорство и настойчивость. А о том что если результаты работы оцениваются адекватно, то работающие будут прилагать больше усилий чтобы достичь результата и в следующий раз.
Какой-то сборник ссылок и цитат, без какого-либо конструктива или связи с заговолвком.. Чат-гопоты писал статью или первод с его бредогенератора?
Со статьёй явно что-то странное.
Уже несколько лет я провожу собеседования с инженерами для различных компаний.
Благодаря этой подписке я сумел получить мою нынешнюю работу.
Я согласен.
Последние 25 лет я работал сениором, управлял командами, нанимал людей, и это заставило меня задуматься, кто этот человек, который говорит мне, что я не сениор, если я не понимаю Scrum и Rup. Этот человек с 2016 по 2021 год работал фрилансером в студии геймификации. С тех пор он пробыл на одном месте не более года. Да, есть несколько 2000 подписчиков, но это не делает тебя старшим. :(
Не могу согласиться со многими высказанными мыслями
Чтобы стать старшим, нужно быть очень хорошо технически подготовленным, иметь большой опыт и уметь быстро учиться. Умение справляться с негативными моментами в команде.
Извините, русский не мой родной язык
// ...
// xx.xx.2020 protopopov@narod.ru "KABAN"->"SCRUM"
var nameOfCurrentTechnology = "SCRUM";
У меня был случай, человек ответил про логарифмическую сложность алгоритма, но не знал что такое логарифм
Но на собесах, чаще всего, необходимы именно названия
Постоянно это слышу, но буквально ни разу не встречал, чтобы именно на названиях фокусировались. Обычно показывают сниппет или просят рассказать про суть какого-то паттерна.
Ну и названия своих инструментов знать полезно - это показатель профессионализма. Кодить-то можно хоть как, а вот коммуницировать с коллегами нужно уже грамотно. Я не смог бы воспринимать серьезно человека, который не может выучить слово "прокси" - и вместо этого объясняется в стиле "ну короче когда вот это вызывает вот то, то на самом деле оно вызывает другое" и т.д.
Простой вопрос про "названия": Какие паттерны проектирования вы знаете, какие наиболее часто используете в работе и почему?
И нужно рассказать, например, в контексте GoF (хорошо бы еще и пояснить, что это такое), что есть порождающие, поведенческие и структурные. Рассказать про каждый из трех и привести 2-3 примера паттерна из каждой группы. То есть назвать, описать и привести короткий пример, в каком случае его можно использовать.
Тут, сниппетами не отделаться. Человек или обладает этим знанием или нет.
Я могу сказать, как работодатель, чего я ожидаю от сеньора: для меня это middle, который научился видеть не локальную задачу, а цель. Middle, который может считать не на ход вперёд, а на 2-3 шага. С кем можно обсудить архитектуру на высоком уровне и не объяснять почему в этом месте должен быть Rabbit, а в этом Redis.
и не объяснять почему в этом месте должен быть Rabbit, а в этом Redis
Если это действительно сеньор, объяснить придется. А то ведь может оказаться, что кролик там вовсе и не нужен.
Я когда выращивал себе сеньора, сознательно на промежутке 3 месяцев разрешил допустить ошибку, решили реализовать очередь на базе данных. Ну поработало решение 3 месяца, а потом под нагрузкой начались коллизии.
В итоге переписал сеньор используя nats, но теперь он этот момент запомнит на всю жизнь и будет просчитывать свои решения на несколько шагов вперёд.
Почему в Python принято использовать len(array), а в других языках – array.length()? Есть ли в этом какая-то логика
Так почему же? Самое интересное осталось без ответа.
Мне понравился ответ JetBrains, когда их спросили, почему у них в котлине Deferred, а не Future или Promise. Future или Promise уже были заняты - ответили они. Некоторое языки и фреймворки целиком проектируются по принципу "ну такая конструкция уже есть у ХХХ - давайте извращение какое-нибудь придумаем".
Всё очень просто. Это для того, чтобы длину можно было легко вычислять при программировании в функциональном стиле.
Я слышал другую версию. Чтобы вычисление длины можно было сделать одним способом, и для стандартных коллекций, и для кастомных классов, которые по функционалу напоминают коллекции
Вот, например
https://lucumr.pocoo.org/2011/7/9/python-and-pola/
Почему len — не метод
Я задавал этот вопрос разработчику ядра Раймонду Хэттингеру в 2013 году, смысл его ответа содержится в цитате из «Дзен Python»: «практичность важнее чистоты» (https://www.python.org/doc/humor/#thezen‑of‑python). В разделе «Как используются специальные методы» выше я писал, что функция
len(x)работает очень быстро, еслиx— объект встроенного типа. Для встроенных объектов интерпретатор CPython вообще не вызывает никаких методов: длина просто читается из поля C‑структуры. Получение количества элементов в коллекции — распространенная операция, которая должна работать эффективно для таких разных типов, какstr,list,memoryviewи т. п.Иначе говоря,
lenне вызывается как метод, потому что играет особую роль в модели данных Python, равно как иabs. Но благодаря специальному методу__len__можно заставить функциюlenработать и для пользовательских объектов. Это разумный компромисс между желанием обеспечить как эффективность встроен ных объектов, так и согласованность языка. Вот еще цитата из «Дзен Python»: «осбые случаи не настолько особые, чтобы из‑за них нарушать правила».Лучано Рамальо, «Python. К вершинам мастерства» 2 изд., с. 45
В последнее время, как никогда ранее, угрожающе выросло количество кандидатов, которым приходится отказывать в должности
Угрожающе для кого? Если в мире недостаточно людей, которые соответствуют вашим требованиям, то это не проблема этих людей, это проблема ваших требований – они оторвались от реальности. Другого глобуса у нас нет.
Что-то много недосказанности. А как же сторона DevOps и тулов?
ИМХО - мидл, должен хорошо знать техническую предментную область - язык программирования, паттерны, архитектуры - это всё легко учится из теории. А старшой - должен уже обладать более широкими софт скилами, знать разницу гибких и строгих методологий. И главное уметь плясать от продукта, а не от того что он умеет. Не совать везде - я так 20 лет он-лайн магазины писал и UI на приборку авто так же буду делать. А уметь выбрать оптимальную методику, архитектуру, паттерны. Уровень документации от самодокументируемого кода, до Detailed Design, Software&System Architecture документов. Объяснять мидлам и джунам, почему их супер-навыки в Vim в данной команде будут только во вред и что он не просто так потратил время на конфиг для IDE и настроили pre-commit git hooks. И сколько дрвгоценного времени это экономит. Ну и опять же это всё если проект для команды или нескольких команд. А если проект на 2 недели на коленке в одно лицо что-то состряпать. То тут не стоит убиваться и поднимать CI/CD на 4 энвайронментах. И писать конфиги, ревью чек-листы и архитектурные документы.
Статья как раз описывает типичную контору, куда не стоит пытаться пролезть. У них у всех типичная болезнь. Они думают, что они уже тоже почти Гугл или хотя бы Яндекс. И бесконечно ищут Нео, который спасет их маленький семейный бизнес. Причем, бывает, проходишь техническое интервью и все рады, но спотыкаешься на главном боссе, который начинает задвигать как раз про архитектуру. Причем, у него уже есть ключевое слово, которое ты должен произнести, например "Кафка" (Он недавно прочитал про нее что-то в интернете). Не произнес - все. На выход.
Много всякой фигни.
Всё эти скрамы и прочая должны быть к месту. Это ну очень редко встречается. Обычно скрам ради скрама.
Шаблоны тоже должны быть к месту.
Мого раз видел как всю эту теорию знают хорошо, а вот на практике фигня получается. В итоге приходится потом за этими спецами теоретиками доделывать и переделывать.
И да, не знаю этих скрамов и прочее. Теорию шаблонов тоже не особо. Мой ключевой навык это решение поставленной задачи. Для этого разберусь и изучу что требуется. Смогу организовать работу команды и наладить процессы. И мне не все равно. Т.е. к работе отношусь ответственно. И тут мне говорят что херня это все. Самое важное знать вот эту понтовую фигню.
Очень правильная цитата в одном из комментариев к этой статье "Много всякой фигни". Я скажу даже, что "Все одна фигня". Формализованные вопросы собеседования не позволят найти хорошего программиста.
Начнем с трех составляющих старшего инженера, которые автор выпытал у ChatGPT.
Методология разработки вообще никак не связана с СКРАМ. Скрам – это плохая практика управления для "небольшой команды", но ни как не методология проектирования. Автор мог бы спросить у ChatGPT или Википедии. Например, ChatGPT выдал такое определение: "Методология проектирования (или проектирования систем) - это набор принципов, подходов, практик и процессов, используемых для разработки и построения технических и информационных систем". Оно в целом коррелирует с определением в Вики. И скрама в определении нет.
Принципы проектирования программного обеспечения. Автор снова путается. Для него принципы проектирования сводятся к патернам. Вероятно, он сам не знает что такое принципы KISS, YAGNI, dry, SOLID и пр.
Языки программирования. Знание нескольких языков программирования (включая любимый автором статьи питон) не делает из человека программиста. В лучшем случае (в сочетании со знанием патернов) – кодера. Можно провести аналогию. Много людей умеют писать по русски (английски, французски, …), но большинство из них не может написать даже небольшой рассказ. Кстати, такие известные писатели и поэты как, Пушкин, Баратынский, Маяковский, Кэрролл, Хемингуэй, Кристи и много других были безграмотными и писали с ошибками.
Наверное, более правильно определять уровень программиста поговорив с ним о тех проектах, в разработке которых он принимал участие и какую роль выполнял в них. Таки образом можно будет определить уровень сложности проектов, которые кандидат сможет разрабатывать. А если посмотреть как изменялась его роль в проектах, то можно оценить его амбициозность.
И еще раз. Статья плохая.
Кандидатура — старший инженер-программист. В должности отказать…