Патрик и Джон Коллинсон, основатели Stripe (в 22 года и в 21 год), с капитализацией $35 млрд.

Y Combinator — лучший в мире акселератор для стартапов по количеству единорогов (21), по объему привлеченных инвестиций ($27 млрд) и по капитализации выпускников ($155 млрд). Важно отметить еще то, что среди выпускников YC было несколько основателей моложе 18 лет (и один 20-летний из России).

А ещё Y Combinator выкладывает все свои учебные материалы бесплатно, уже более 10 лет.

Основатели и техдиры миллиардных стартапов Amazon ($1.55 трлн), Facebook ($720 млрд), PayPal ($127 млрд), AirBnb ($40 млрд), Pinterest ($38 млрд), Stripe ($35 млрд), LinkedIn ($26.2 млрд), Slack ($23 млрд), WatsApp ($19 млрд), Doordash ($16 млрд), Twitch ($15 млрд), Netscape ($10 млрд), Sun Microsystems ($7.4 млрд), Zenefits ($4 млрд), Segment ($4 млрд), Box ($2.76 млрд), Quora ($2 млрд), Asana ($1.5 млрд), Zappos ($1.2 млрд), Docker ($1.2 млрд), Pebble, Jawbone, Opsware, Weebly, Yahoo!Mail, Gmail, Mixpanel, Scribd и пр, а так же основатели венчурных фондов Andreessen Horowitz, Cowboy Ventures делятся своим опытом со всем миром. Это контент невероятного качества для тех, кто хочет играть в «высшей лиге», на международном уровне.

Сейчас у Y Combinator 172 видео-лекции в плейлистах: 2012, 2013, 2014 NY, 2014 Europe, 2014 SV, How to Start a Startup (2014 Lectures), 2016, 2017, 2018, Startup Investor School 2018, 2019, 2020. Ниже приведены переводы, субтитры и транскрипты 75 из них.

Проходить интервью — отдельный навык. И это навык продаж.

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

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

• Меняет карьеру
• Первые разы проходит интервью
• Переходит из академии в индустрию
• Из своего бизнеса на наемную работу
• Кому пока плохо удается проходить не технические этапы интервью (все эти софт-скиллы, cultural fit, etc.)

Мои блог-посты описывают процессы интервью в область ИИ и машинного обучения, но первые части подойдут почти к любой сфере. В части 1 я расскажу про интервью глазами продавца, в части 2 глазами покупателя. Про технические этапы и как к ним готовиться напишу в части 3. Как создавать себе работу по душе самой, не рассчитывая «на дядю» и не проходя классическую схему интервью, в части 4. Погнали.

*Scope: переход: два декрета подряд — МедТех — индустрия. Сфера: машинное обучение/компьютерное зрение. Вводные данные: художник, PhD по физике. Место событий: планета Земля (пандемия расширила границы)

Часть 1. Интервью как продавец

Компания покупает Ваше время и труд. Вы продаете свой опыт и навыки. Вы — продавец. Они — покупатель.

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

Недавно я написал о «Пять книг, которые изменили мой стиль программирования». В комментариях несколько читателей рекомендовали «Чистый код» Роберта С. Мартина. В результате я прочитал книгу и нашел ее достойной углубленного обзора.

В нашем блоге мы много пишем о построении карьеры в ИТ в разных странах, поиске работы, отличиях в процессе собеседований крупных компаний. В сегодняшней статье мы пойдем дальше и раскроем тему так называемых интервью по system design – это один из этапов собеседований известных технологических компаний, на котором отсеиваются многие кандидаты.

Итак, что такое system design и как пройти интервью такого типа?

Прим. перев.: недавняя статья от Uber Engineering рассказывает о путешествии этой крупной компании к своей улучшенной версии микросервисной архитектуры. Несмотря на то, что некоторые интернет-пользователи не без причин увидели в новом подходе «всего лишь применение принципов DDD к микросервисам», статья снискала огромный интерес у сообщества разработчиков и других инженеров. А посему — рады представить её русскоязычную версию, подготовленную специально для хабра.

Введение

В последнее время активно обсуждаются недостатки сервис-ориентированных архитектур и, в частности, микросервисных архитектур (МА). Всего несколько лет назад многие с готовностью переходили на МА из-за их многочисленных преимуществ: гибкости в виде независимых развертываний, прозрачной принадлежности, повышения стабильности систем и лучшего разделения ответственности. Однако не так давно ситуация изменилась: микросервисный подход стали критиковать за склонность серьезно увеличивать сложность, из-за которой иногда бывает тяжело реализовать даже тривиальные функции. (Мы рассказывали об этом в докладе «Микросервисы: размер имеет значение, даже если у вас Kubernetes» — прим. перев.)

В настоящее время в Uber насчитывается около 2200 критических микросервисов, и мы испытали все достоинства и недостатки этого подхода на себе. В течение последних двух лет Uber пыталась сократить запутанность микросервисного ландшафта, попутно сохранив преимущества данной архитектуры. С помощью этой публикации мы планируем представить наш обобщенный подход к микросервисным архитектурам, получивший название «Domain-Oriented Microservice Architecture» (DOMA).

По статистике Stack Overflow, активно ищут работу немногим более 17% разработчиков. При этом, помимо зарплаты, в пятерку важных факторов при смене места входит и запрос на улучшения work/life balance. Традиционно многие люди видят в удаленной работе возможность улучшить этот баланс, больше времени проводить с родными и контролировать график.



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

Я изучил текущую статистику по рынку труда для разработчиков, материалы, которые публикуют рекрутеры и инженеры, которые сами проводят собеседования, а также поговорил с Александром Жилиным, Go/Python разработчиком из Питера, который недавно сумел найти работу с помощью специализированного чат-бота. В итоге я составил материал с актуальными советами по поиску удаленной работы в 2020 году.

Статью подготовил Брюханов Константин, руководитель курса «CI/CD». В ней Константин раскрыл ряд проблемных моментов, связанных доставкой развертыванием кода программного продукта в IT-компаниях, и собрал рекомендации из числа лучших международных практик.

---

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

Технологический прорыв и свободно-распространяемое ПО привели к тому, что подход к организации процессов CI/CD значительно изменился. Переход на новые принципы сильно повлиял на корпоративную культуру, востребованные навыки сотрудников и сами принципы работы в организациях, что привело к масштабным переменам в мире разработки ПО.

Предлагаю вашему вниманию перевод статьи, в которой высказывается интересная точка зрения на размер релизов/задач при разработке информационных систем. По мнению Аллана Келли, при разработке ПО отсутствует экономия на масштабе, а при увеличении объема задач/релизов экономика только ухудшается. Статья содержит примеры и доводы, иллюстрирующие это, и автор рекомендует стараться ставить небольшие и конкретные задачи, работать более мелкими релизами. Пытливый читатель сразу задаст вопросы: «Можно ли из этого сделать вывод, что необходимо максимально уменьшать размер задач/релизов? Где же тогда этот предел? Нужно ли выводить в продуктив по одной строчке кода?» Эти вопросы, к сожалению, не раскрыты в статье. По моему личному опыту, в имеющихся условиях у команды существует некоторый оптимальный размер задач/релизов, который определяется зрелостью процессов, спецификой культуры команды и уровнем развития инженерных практик. Для кого-то это три месяца, для кого-то это одна неделя, кто-то способен работать в режиме  непрерывной поставки… Однако если инвестировать в то, чтобы команда научилась бы работать меньшими задачами/релизами, то это впоследствии принесет долгосрочную отдачу.

Жизнеспособна ли ваша команда? Должен ли руководитель кодить? Всегда ли инженеры ненавидят процессы? Какими должны быть регламенты? Как оценивать производительность инженеров? Почему так важны тет-а-теты? Как побыстрее «свалить» с совещания? Почему в Кремниевой долине так любят плоские организационные структуры? Если эти вопросы для вас актуальны, то вам стоит почитать книгу «Как управлять интеллектуалами. Я, нерды и гики» Майкла Лоппа. Книга будет полезна тем, кто хочет более осознанно заниматься управлением инженерными командами. Предлагаю подборку важных идей книги.

amazon litres

Docker Swarm, Kubernetes и Mesos являются наиболее популярными фреймворками для оркестровки контейнеров. В своем выступлении Арун Гупта сравнивает следующие аспекты работы Docker, Swarm, и Kubernetes:

• Локальный девелопмент.
• Функции развертывания.
• Мультиконтейнерные приложения.
• Обнаружение служб service discovery.
• Масштабирование сервиса.
• Run-once задания.
• Интеграция с Maven.
• «Скользящее» обновление.
• Создание кластера БД Couchbase.

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

Арун Гупта — главный технолог open-source продуктов Amazon Web Services, который уже более 10 лет развивает сообщества разработчиков Sun, Oracle, Red Hat и Couchbase. Имеет большой опыт работы в ведущих кросс-функциональных командах, занимающихся разработкой и реализацией стратегии маркетинговых кампаний и программ. Руководил группами инженеров Sun, является одним из основателей команды Java EE и создателем американского отделения Devoxx4Kids. Арун Гупта является автором более 2 тысяч постов в IT-блогах и выступил с докладами более чем в 40 странах.

В течение всей истории разработки ПО мы искали надежные способы оценки времени на реализацию задач и проектов. Но и спустя более чем 60 лет существования отрасли наши прогнозы все еще оставляют желать лучшего. Может быть, дело не в том, как именно мы пытаемся оценивать, а в том, что мы вообще опираемся на оценки?

К примеру, возьмите методологию Scrum, по которой сегодня работают многие компании. Центральная идея Scrum — брать в спринт не больше задач, чем ваша команда способна за это время выполнить. На первый взгляд, звучит разумно. К сожалению, слишком часто на практике этот подход приводит к замедлению работы команды в обмен на иллюзию планирования. Позвольте объяснить, почему.

Субъективная попытка оценить мир open source, с позиции рядового контрибьютора, спустя два года ежедневного участия. Не претендую на истину, не напрягаю советами, только структурированные наблюдения. Возможно, эта статья поможет лично вам понять — быть или не быть open source contributor'ом.

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

Хорошие идеи часто терпят неудачу на практике, и в мире тестирования хорошим примером этого может служить стратегия тестирования, построенная на автоматизации end-to-end тестов.

Тестировщики могут инвестировать свое время на написание многих типов автоматических тестов, включая модульные тесты, интеграционные тесты и end-2-end тесты, но эта стратегия в основном направлена на end-2-end тесты, которые проверяют продукт или услугу в целом. Как правило, эти тесты имитируют реальные пользовательские сценарии.

Источник

Всем привет. На связи Владислав Родин. В настоящее время я являюсь руководителем курса «Архитектор высоких нагрузок» в OTUS, а также преподаю на курсах, посвященных архитектуре ПО.

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

---

Введение

В прошлый раз мы с вами поговорили про то, что транзакции в базах данных служат для решения двух задач: обеспечения отказоустойчивости и доступа к данным в конкурентной среде. Для полноценного выполнения этих задач транзакция должна обладать свойствами ACID. Сегодня мы подробно поговорим про букву I (isolation) в данной аббревиатуре.

Кажется, тема «зачем нужен Kubernetes», уже раздражает. Хочется сказать: «все кому надо — давно уже поняли», однако я разделил бы технических (и околотехнических) работников на тех, кто «понял и знает как использовать», и тех, кто «понял, но хочет знать, как сделать знания актуальными».

Возможно, вы менеджер, который последние 10 лет работал на одном и том же стеке; возможно, вы разработчик, который поддерживает старое решение или пишет на привычном языке в привычной среде. Возможно, вы просто перешли из технического в организационный менеджмент и вдруг выяснили, что все, что вы знали, больше не актуально, и хочется понять — есть ли какой-то относительно простой сценарий, как это можно догнать. Я постараюсь дать советы, основываясь на собственном опыте, — от человека, который осознал, что, находясь на организационном управлении, скоро будет выражаться словами «Kubernetes — это эффективная технология, мы должны стремиться к ее применению», не вполне понимая, что лежит за этими словами и за всей технической культурой, развившейся в последнее время.

Почему я считаю важным уметь менять парадигму технологического мышления?

В ЛАНИТ больше 40 подразделений и компаний. У некоторых из них есть офисы в Канаде, Польше, США, Казахстане и других странах. За последний месяц каждый из нас прочитал или, как минимум, увидел множество больших и маленьких текстов о том, как в России работается на удалёнке. Сегодня мы расскажем про home office опыт наших коллег в Италии («ЛАНИТ-Терком») и Беларуси (Artezio).

Источник

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

Если ответы на эти вопросы вас интересуют, то вам стоит почитать книгу Маркуса Бакингема и Курта Коффмана «Сначала нарушьте все правила: Что лучшие в мире менеджеры делают по-другому». Эта книга могла бы стать для меня настольной, но перечитывать нет времени, поэтому я сделал выжимку, которой и хочу с вами поделиться.

Не кажется ли вам странным то, что когда вы собираетесь поменять место работы и возникает необходимость пройти интервью, то в первую очередь вы думаете «надо подготовиться к интервью». Прорешать задачи на HackerRank, почитать Crack the coding interview, зазубрить как устроен ArrayList и чем она отличается от LinkedList. Ах да, еще сортировки спросить могут, и явно будет непрофессионально сказать, что quick sort скорее всего будет лучшим выбором.
Но постойте, вы ведь программируете 8 часов в день, решаете интересные и нетривиальные задачи, и на новом месте работы будете делать плюс-минус тоже самое. Но тем не менее, чтобы пройти интервью необходимо как-то дополнительно готовиться, даже не оттачивать ежедневные навыки, а выучить то, что вам не понадобилось ни на текущем месте работы, ни вряд ли понадобиться на следующем. На ваши возражения о том, computer science у нас в крови, и разбуди нас посреди ночи мы обязаны написать с закрытыми глазами на наволочке обход дерева в ширину даже не приходя в сознание, я отвечу, что если я буду устраиваться в цирк, и моим главным трюком будет именно это — то пожалуй да, я согласен. Нужно этот навык проверить.

Привет, Хабр! Меня зовут Алексей Рыбак, я – глава разработки в Badoo. В феврале в нашем московском офисе Badoo проходил Techleads-митап, где я рассказывал про наш процесс Performance Review. Эта статья написана по мотивам моего выступления.