Все потоки

Как проходят собеседования аналитиков в международной продуктовой IT-компании Garage Eight

Недавно наш Head of Product Analytics Олег Игнатов в прямом эфире провел публичное интервью с продуктовым аналитиком Юрой. 

Процесс собеседования можно посмотреть на YouTube или VK Видео, а концовку готовы проспойлерить прямо здесь — Юра прошел все этапы интервью, принял наш оффер и уже скоро начнет онбординг в Garage Eight. 

А если интересно узнать, как сам Олег 6 лет назад зашел в аналитику без опыта, то рекомендуем почитать его интервью для блога Хабр Карьера. В нем он рассказал, как из авиационного инженера за несколько месяцев переучился на продуктового аналитика, поработал в S7 и Литрес, а потом пришел в Garage Eight. 

Читай и узнаешь: 
> что помогло Олегу найти первую работу в IT, и какие советы он дает тем, у кого опыта еще нет;
> какой была его первая зарплата;
> чему его научили провальные собеседования;
> как устроена аналитика у нас в компании.

Карьерный трек продуктового аналитика с разбивкой по скилам на каждый грейд ждет в конце статьи. А открытые вакансии к нам в аналитику — на карьерном сайте и в нашем telegram-канале ;-)

А вы помните, как всё начиналось? Как ровно 6 лет назад — вот в эти же осенние дни — был представлен самый первый полноразмерный прототип 2-й ступени Starship? Как Илон Маск толкал речь — стоя перед этой громадой — о неизбежной колонизации Марса и резервной копии Человечества...

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

В апреле 2023 мы стали свидетелями первого полёта ракеты в полном сборе. И хотя, тогда удалось успешно лишь оторваться от стартового стола, а всё остальное — нет, следующие полёты демонстрировали поступательное развитие.

В середине октября 2025 ожидается уже 11-й интегрированный полёт.

Разработка системы Starship продолжается уже 7-й год.

Долго ли это?

Всегда ли наследование должно идти от родителя к потомкам?

Возможно, этот вопрос уже давно обсосан кучей способов, но я дошел до него только сейчас: всегда ли наследование должно идти от родителя к потомкам?

Стандартно во всяких учебниках для начинающих рассказывают, что наследование является аналогом связи «Является». Например, яблоко является фруктом, поэтому в коде класс Яблока должен наследоваться от класса Фрукт.

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

1. Наследник может изменять методы родителя

2. Наследник может хранить больше полей, чем родитель

3. Наследник не может удалять поля родителя

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

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

Другим видом параллелограмма является ромб (), в котором мы снова бесполезно храним размерность второй стороны.

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

Рассматривая наследование как метод расширения функционала, здесь гораздо «правильнее» в качестве родителя выбрать квадрат. Он хранит всего лишь одну сторону.

Далее от него потомки идут в две стороны.

Сторона первая: квадрат ->  ромб (добавляем угол) -> параллелограмм (добавляем вторую сторону)
Сторона вторая: квадрат -> прямоугольник (добавляем вторую сторону) -> выпуклый четырехугольник (добавляем еще две стороны)

Как будто, это выглядит более логично? Или я где-то ошибся? Очень жду профессионального мнения в комментариях

Представлен репозиторий Free Certifications с бесплатными сертификациями по IT-технологиям от Google, Oracle Microsoft и других компаний. Все сертификаты строго разделены по категориям: фронтенд, бэкенд, SQL, Data Science, информбезопасность, аналитика и ещё множество тем.

Небольшой анонс: издательство БХВ теперь ведет собственный корпоративный блог на Хабре

Рады вам сообщить, что теперь вы сможете чаще читать рецензии на книги по ИТ от БХВ, Alist, Фолиант и наверняка что-то выберите себе для роста личных хард-скилов и компетенций.

Мы, в свою очередь — контент-команда SSP SOFT — уже около двух лет публикуем в нашем блоге рецензии на книги БХВ, но делаем это выборочно: только те издания, которые пересекаются с нашей основной деятельностью — заказным программированием, системным ПО, ИТ-аутсорсингом, внутренней архитектурой ПО и смежными темами.

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

И вот первый такой анонс.

📘 «Чистовики патриарха. О трёх последних книгах Олега Цилюрика»

В своей статье БХВ публикует обзор трех недавних работ известного Линукс-гуру и автора технической литературы Олега Цилюрика.

• Первая рекомендуемая книгиа — «Расширения ядра Linux. Драйверы и модули», книга объёмом ~688 страниц по версии ядра 5.15, детально раскрывающая внутренние API ядра, взаимодействие с периферией, USB, PCI и многое другое (ссылку на книгу).

• Также БХВ рассказывает о книге «Linux и Go» — экспериментальном проекте объединения низкоуровневого программирования и Go, где автор исследует переход некоторых подсистем ядра и функций на Go, и подробно рассматривает вопросы производительности, взаимодействия C и Go, многопроцессорности.

• Третья книга — а это перевод «Изучаем eBPF» — показывает, что авторские компетенции охватывали не только ядро, но и современные технологии мониторинга, безопасности и расширения функций ядра.

Статья в блоге БХВ лампово освещает рабочие моменты сотрудничества издательства и автора: как проходила верстка, как уточнялись детали кода, как велись обсуждения правок. Материал про творчество Олега Цилюрика важен для профессионального сообщества — чтобы вызвать готовность «заглянуть за обложку».

Продолжаю серию о винтажном веб-дизайне.

4/5 — в 2013 Windows 8 была на волне трендов у заказчиков. И каждый заказ получался, как очередная Nokia (в виде помады, например)

Вспомнил холивары на первой работе на тему: что такое Activity?

Тогда, среди Android-разработчиков, в моде была MVC и общение было примерно такое:

"Activity - это контроллер" - говорили одни.

"Activity - это вью" - говорили другие.

"Activity - это модель" - так к сожалению никто не говорил, иначе было бы еще интереснее 😁

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

Кто из них прав?

Никто.

Или и те и другие.

Правильный же ответ такой:

Я создатель приложения и какую роль я дам этому классу(Activity) такую он и будет выполнять.

Это если смотреть со стороны архитектуры приложения.

А если смотреть со стороны OS Android, то Activity - это интерфейс через который пользовательское приложение взаимодействует с операционной системой.

Вот и всё :)

P.S. А какие холивары вспоминаются вам?)

Привет, сообщество!

Я — Татьяна Демидова, предприниматель, экономист, юрист. Долго не решалась писать на Хабр, ну чему я могу вас научить, я не айтишник, не программист, это будет просто смешно если я возьмусь тут вам ликбезы писать.

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

Вижу, что очень мало тем в СМИ, сообществах, о том, как организованы процессы работающего бизнеса. Статьи о том какую CRM выбрать, написаны продавцами CRM. Статьи о том, как настроить телефонию или общение в мессенджерах, написаны продавцами телефоний и мессенджеров. Всяк кулик свое болото хвалит.

А я за 19 лет прошла очень многое. Я сменила несколько CRM, несколько телефоний, несколько таск-трекеров, несколько нейронок. Сейчас, например, мы в компании используем 6 нейронок для рабочих целей.

О чем я могу рассказать:

Технологии и инструменты

• Как мы пережили три смены CRM и какая прижилась.

• Зачем мы сделали ЭЦП всем сотрудникам, где делали и сколько это стоит.

• Как мы избавились от всех бумаг, в том числе актов, кадровых и прочей фигни.

• Как мы уходили с гугл диска: Яндекс, Мейл, Битрикс24 — что попробовали, что выбрали, почему.

• Какую 1С-ку мы выбрали и почему всему малому бизнесу рекомендуем это же решение.

• Как мы интегрировали все возможные мессенджеры, радовались, а недавно они все отвалились.

• Как мы настраивали айпи-телефонию и сначала "ничего не было слышно". Какое решение помогло.

• Где и когда нам помогла запись звонков. Почему мы храним архив звонков за 4 года.

• Какие мы попробовали платформы для базы знаний и на чем остановились.

• No-code инструменты, которые прижились и мы используем их в своей работе.

• Как мы автоматизировали финансовый дашборд и в итоге пришли к "сообщению в чатике".

Люди и команда

• Как мы учили бухгалтеров клиентоориентированности.

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

• Как мы организовали отдел продаж и продаем ли мы вхолодную.

• Как наше понимание "хорошего бухучета" диаметрально расходится с пониманием клиентов. И кто прав.

• Как мы три года оплачиваем образовательные платформы сотрудникам, а ими почти никто не пользуется. И что мы сделали сейчас.

Управление бизнесом и процессы

• Как мы организовали удаленную работу и работаем так уже 12 лет.

• Как мы контролируем задачи бухгалтерского производства.

• Как мы решали, выводить ли продакшен на прямую коммуникацию с клиентом или нет.

• Почему у нас нет тайм-трекеров и мы не контролируем часы специалистов, хотя начинали именно с этого.

Если этот пост наберет больше плюсов, чем минусов, тогда начну рассказывать. Нет — ну значит нет, продолжу читать и комментировать вас. 

Да, мне немного страшно писать сюда впервые, но это важный софт-скилл предпринимателя — перебороть свой страх и делать то, что должен.

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

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

🗓 Ждём вас 14 октября в 11:00!

Регистрация на вебинар

Обсудим 2 темы:

⁃ Финишные покрытия.

- Зачем нужны разные финишные покрытия и каково их назначение?

- Чем обусловлен выбор того или иного финишного покрытия?

- Как можно классифицировать финишные покрытия по технологии изготовления и применению.

⁃ Заполнение сквозных и глухих отверстий.

Обсудим основные типы заполнения сквозных и глухих отверстий. А также рассмотрим примеры плат с разными типами заполнения отверстий.

Семинары и вебинары ГРАН всегда бесплатные.

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

Так как дело обстоит сейчас - никуда не годится.

IT-специалистов за людей не считают, независимо от стажа и ранга, будь ты junior, middle, senior или teamlead, ты сталкиваешься с проблемами при трудоустройстве.

Понятное дело что мы уже попривыкли к такому обращению, но разве нас это устраивает?

Меня - нет.

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

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

Но мы то не заключенные, мы то слава богу свободные!

И у нас есть возможность общаться друг с другом и договариваться для получения обоюдовыгодных результатов.

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

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


P.S. если такое объединение уже есть - дайте ссылку, я впишусь
P.P.S не знаю что точно надо делать, но решил что буду что-то делать, залетайте сюда кто хочет присоединиться:телеграм группа