Менеджмент

Дисклеймер: Эта публикация скорее крик души... я не буду говорить, что являюсь выдающимся экспертом в базах данных, а тема данного поста не для того, чтобы мериться размером дампа. Мне просто больно раз за разом слушать на комитетах о русскоязычных кандидатах, что он нам не подходит потому что...

Очень много ресурсов можно найти на просторах интернетов на тему собеседования Software Engineer'ов в FAANG, куча теоретического материала, список готовых задач с интервью, как готовится к System Design вопросам и т.п., но лично для меня было огромной болью искать что-то, чтобы быть готовым к интервью на роль Database Engineer. Проблема в основном в том, что разброс вопросов по этой теме невероятно огромный. Отмечу, что это касается именно FAANG компаний, потому что на собеседовании туда Вас, как SWE / SRE, не будут просить "написать синглтон" или спрашивать в чем проблема многопоточности в питоне, всё довольно прозаично в подготовке на эти роли.

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

Согласитесь, что название статьи звучит немного странно. Зачем же избавляться от этих милых, слегка занудных, но в основном весьма безобидных людей?

Как их только не называют: техписы, техрайтеры, документаторы... Хорошо, хоть не архивариусы!

Если мы избавимся от технических писателей, кто же будет разрабатывать пользовательскую документацию на наши системы и приложения? Да и зачем лишать работы профессионалов, которые могут грамотно и понятно описывать всё, что было спроектировано и запрограммировано, каким бы сложным оно не было?

— Кто за сутки до отправки заказчику во всей инструкции заменил manual на manul?!

Автор сообщества Фанерозой, биотехнолог, Людмила Хигерович.

В 1912 году Георгий Седов организовал экспедицию по покорению Северного полюса. По плану должны были летом на корабле дойти до Земли Франца-Иосифа, перезимовать там, а весной двинуться к полюсу на собачьих упряжках.

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

В реальности зимовать на корабле пришлось целых два раза. А попытка идти к полюсу закончилась почти сразу же — Седов в пути умер от цинги и был похоронен на одном из островов архипелага. То есть они даже не успели отойти от берега. Двое его попутчиков повернули обратно. А летом 1914 года корабль наконец-то вернулся в Россию.

В преддверии старта курса "Enterprise Architect" подготовили для вас текстовую версию демоурока, который провел эксперт OTUS - Петр Подымов.

В рамках урока поговорили:

- об обоснованных структурных изменениях в компании в быстро меняющихся условиях;

- о применении архитектурного подхода в вопросах трансформации;

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

Привет, Хабр!

Так уж сложилось, что и вторая книга, о которой мне захотелось рассказать, посвящена вселенной DOOM. Что ж, раз издательство "Бомбора" переводит для нас такие материалы - так тому и быть. 

Хабр место демотивирующее и угнетающее, если ты начинающий разработчик - бесконечное число статей с непонятными названиями и аббревиатурами, истории про найм в “компанию с большой ЗП”  и эмиграцию. Хотя хабр позиционируется, вероятно, как сообщество профессионалов, есть гипотеза, что он один из первых ресурсов, на который подписывается человек, который решил, что хочет “войти в айти”. Моя история будет интересна в первую очередь им. Эта история не про “кровь и пот”, и не про курсы “Стань программистом за N дней”, а про честность.

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

Привет! Я Максим Карпов, лид Мастерской — части программы трудоустройства Яндекс.Практикума. Многие выпускники сталкиваются с одной и той же проблемой. При трудоустройстве компании изучают портфолио кандидата: если в нём есть не только учебные, но и реальные проекты, шанс получить работу увеличивается. Но где выпускнику курса найти реальный проект, чтобы отточить свои навыки и пополнить портфолио? 

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

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

Последний раз, когда добрались до моей старенькой мамы, у меня подгорело. Провел небольшое расследование. Во всех случаях звонили с пула оператора связи ООО «Кордис Телеком». Как и полагается, ни на письма, ни на звонки никто не откликается - тишина на Докукинской улице.

Что делать? Решил написать в Роскомнадзор, благо мошенники неплохо осведомлены о персональных данных, которые ни я, ни мои родные им не передавали.

Подозревая, что я не один такой, подготовил обращение, любезно собрав необходимую информацию на рассмотрение уважаемому органу. Обращение можно отправить по адресу https://rkn.gov.ru/treatments/ask-question/ , ведь лучше стучать, чем перестукиваться, как говорил один поэт.

Пользуйтесь на здоровье.

С телефонного пула оператора ООО «Кордис Телеком», находящегося по адресу 129222, г. Москва, ул. Докукина, д. 8, стр. 2, оф. № 1, ОГРН 1067759890406, ИНН 7713602071, что следует с сайта компании http://kordistele.com/ поступают мошеннические звонки мне и моим родственникам. При этом звонящие четко осведомлены о личных персональных данных, включая место проживания, имя, фимилию, личные телефоны. Ни я, ни мои родственники эти персональные данные не передавали ни ООО «Кордис Телеком», ни аффилированными с ней третьим лицам. Телефонные номера, с которых производились звонки:+7(495) 040-08-68, +7(495) 040-09-69.

В этом году звезды сошлись и я поняла, что гайд по контенту поможет решить кучу вопросов, с которыми я начала всё чаще сталкиваться.

Ключевые идеи книги «Искусственный интеллект: перезагрузка» Гэри Маркуса и Эрнеста Дэвиса, ученых, которые специализируются на искусственном интеллекте.

Прочитав обзор, вы узнаете о том, почему, несмотря на прогнозы технооптимистов и шумиху в СМИ, мы еще очень далеки от создания искусственного интеллекта, подобного человеческому.

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

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

В этой статье я расскажу о том, как вы можете придумать подходящие для себя метрики, исходя из уникальной ситуации в вашей команде, и какие шаги нужно предпринять, чтобы не только измерить, но и улучшить производительность вашей команды инженеров. Потому что метрики нужны для того, чтобы их улучшить. Как говорится, нельзя улучшить то, что не измеряешь.

Часть 1: CRM для ERP

Часть 2: Роботизация бизнес-процессов

Часть 3: Волшебные интерфейсы и оживление железа

Часть 4: Автоматические личные кабинеты и чат-боты

Часть 5: Автоматизация на производстве

Часть 6: Траблшутинг на предприятии (в этой публикации)