#Работа
Немного вводной - сейчас у меня позиция Senior Software Engineer в аутсорс-компании, где я работаю как член продуктовой команды крупной международной компании, занимающейся медицинскими исследованиями. Мой текущий стек - это Python/JS и AWS Serverless. Я занимаюсь интеграциями различных сервисов для оптимизации работы ученых.

Последнее время участвую в собесах на разные позиции со стороны компании. Иногда собеседую с другими коллегами. Забавно, что меня зовут проверить экспертизу по AWS, сейчас вообще девопсов собеседую. Тут можно найти наши вакансии https://www.linkedin.com/company/software-country/posts/?feedView=all

Инсайды о собесах со стороны собеседующего

1. Джуновые вопросы на теорию бывают очень показательны. Я ненавижу теоретические вопросы, так как считаю, что ответы на эти вопросы учатся на собеседованиях. Чем больше человек прошел собеседований, тем лучше он на них отвечает. Но для меня открытием было, что опытные разработчики не могут ответить на какие-то совсем простые и банальные вещи. Вторым открытием было, что ответить кое-как, но показать безусловное понимание темы - это фактически ответить, потому что не ответить - это когда кандидат вообще двух слов связать по теме не может. Но все равно считаю, что надо спрашивать про опыт, а не про теорию и отталкиваться именно от опыта, если это не джун.
2. Собеседование, основанное на опыте, слишком сложно проводить. Чтобы провести собес, когда ты оцениваешь кандидата не по теоретическим вопросам, а по его опыту, нужно быть дофига гибким, подкованным, готовиться к каждому собесу почти индивидуально, хорошо продумывать вопросы, понимать то, о чем говорит кандидат. Именно поэтому мы имеем то, что имеем - все собесят на базе списка вопросов по теории.
3. 2-3 практических вопроса про опыт могут дать гораздо больше информации о кандидате, чем просто знание теории. И, кстати, будучи кандидатом, я думаю, будет плюсом, если говоришь не просто ответ на теоретический вопрос, но и подкрепляешь собственным опытом применения. Меня реально бесят вопросы аля - что такое генератор, реально кажется важнее спросить - применяли ли генераторы и если да, то как и зачем.


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

#Работа
Моя подборка вопросов на опыт:

• Какие были сложности на проектах, как их решали? - любимый вопрос, сразу выявляет приоритеты и интересы кандидата, потому что в первую очередь человек рассказывает о самом запомнившемся и важном для него челлендже. Плюс отлично отражает то, как кандидат справляется с проблемами.
• Есть ли опыт по оптимизации (чего угодно)? В чем состояла задача, кто инициировал и как, как решали? - хорошо отражает вовлеченность, понимание контекста, знания и бекграунд, так как кандидат объясняет что и зачем он использовал.
• Есть ли опыт в автоматизации, улучшении процессов (своей, чужой работы)? - Опять же на понимание, инициативу, видение возможностей и тут еще важно спрашивать зачем был использован тот или иной инструмент, оправдано ли, как это внедрялось, как описывалось и другие сопутствующие вопросы.
• Есть ли опыт работы с легаси, рефакторинга? С какими проблемами столкнулись, чему научились? - умение анализировать проблемы своего и чужого кода - отличный скилл. Понимание важности, но с другой стороны баланса рефакторинга и бизнес-задач - тоже показательно.
• Был ли опыт создания проектов с нуля, выстраивания архитектуры? Как подходили к этой задаче? Как бы решали сейчас, если пришлось бы? - на самом деле можно 100500 подобных вопросов придумать про существующий опыт кандидата, чтобы просто посмотреть как мыслит, на что опирается, как вообще решает задачи.
• Есть ли опыт взаимодействия с пользователями? С какими проблемами сталкивались? - Умение работать с пользователями и понимание контекста - отличный показатель вовлеченности.
• Что нравится в работе? Что вдохновляет? Самые крутые задачи, которые довелось решить. - Показывает мотивацию и вообще увлеченность кандидата.

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

#Жизнь
35
За последние 5 лет я посетила 30 разных городов, я пожила хотя бы месяц в 5 новых для себя странах, я поработала в 4 разных компаниях, прошла стопку курсов, получила сертификат AWS, выиграла с командой в хакатоне 1 млн рублей, закрыла 2 сессии в универе, свитчнулась из менеджера в программисты и дошла до лычки сеньора. А когда-то я считала, что после 30 жизни нет.

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

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

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

#Python
Открыла для себя тулу для работы со сложными структурами из json, когда нет нужды детально их описывать, но надо получить какие-то конкретные данные.

https://jmespath.org/

Эта штука встроена в powertools aws lambda https://docs.powertools.aws.dev/lambda/python/latest/utilities/jmespath_functions/, что в моем случае хорошо, так как не нужны никакие дополнительные либы.

Примеры моих текущих запросов, которые я делала для своей задачки:

f"data[*].attributes.tags.\"worksheet.{COLUMN_NAME}\" | [?starts_with(@, 'G')]"

чтобы работать с ключами, которые содержат пробелы или спецсимволы, их надо заключить в экранированные кавычки

| - это значок пайплайна, после него идет обработка результата предыдущей операции.

@ - текущий элемент

[?] - условие для фильтрации элементов

"included[?starts_with(id, 'ado-')].attributes.fields.\"Primary API\".value | [0]"

[0] - забирает первое найденное значение, иначе бы вернуло список всех значений

"data.attributes.fields[?name=='Compound API'].content.value | [0]"

[?name=='Compound API'] - Позволяет выбрать объекты с конкретными параметрами из списка

Короче, это такой аля упрощенный пандас для работы с json.

Боты для уведомлений в Microsoft Teams.

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

Шаг 1: Создание потока с HTTP триггером
1. Вход в Power Automate:
• Перейдите на сайт Power Automate и войдите в свой аккаунт.
2. Создание нового потока:
• Нажмите на "Create" (Создать) и выберите "Instant cloud flow" (Мгновенный поток в облаке).
• Дайте название вашему потоку и выберите триггер "When an HTTP request is received" (Когда получен HTTP запрос).
• Нажмите "Create" (Создать).

Шаг 2: Настройка схемы JSON
• Если ожидаемый запрос содержит JSON, определите JSON схему:
• В триггере "When an HTTP request is received", введите схему в поле "Request Body JSON Schema".
• Пример схемы для сообщения:

 {
  "type": "object",
  "properties": {
    "message": {
      "type": "string"
    }
  },
  "required": ["message"]
}

 
• Это позволит автоматически извлечь текст сообщения из поля message.

 
Шаг 3: Добавление действия отправки сообщения в Teams
• После триггера добавьте действие:
• Выберите "New step" (Новый шаг), затем "Microsoft Teams" -> "Post a message as a flow bot to a channel" (Отправить сообщение от имени бота потока в канал).
• Выберите команду и канал.
• В поле "Message" используйте динамическое содержание и выберите message, чтобы вставить текст полученного сообщения.

Шаг 4: Сохранение и тестирование потока
• Сохраните поток. Power Automate предоставит вам URL, который вы можете использовать для отправки HTTP запросов.
• Тестируйте поток, отправляя HTTP запросы на ваш URL с JSON телом, например, {"message": "Привет, команда!"}.
• Убедитесь, что сообщения корректно публикуются в Teams.
 

#Работа, #Tools

#Работа
У нас в бд даты для меня имели странный формат - вроде timestamp, но какой-то неправильный. Все никак не могла понять как его считать. Решила парсить отображаемое значение, которое также имелось в бд, но столкнулась с тем, что в нем месяца прописаны буквами и различаются в зависимости от языка, на котором эта запись была создана. Жизнь боль, вернулась к странному timestamp.

Оказалось, что это timestamp экселевский и считается от 1990 года в прошедших днях (не секундах). Как-то так Оо

#Учеба
В универе смотрю тему - регулярные выражения. Думаю, хе, ну изи, там уже все знакомо. Открываю, а там… Вообще не близко :)

#Учеба, #UOL
Пишу мидтерм по ООП на плюсах, ловлю всякие забавные моменты.

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

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

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

И вот я переписала его csv ридер с помощью копайлота, чатгпт и такой-то матери, и решила затестить. Ну я ж не в блокноте пишу, поэтому у меня как у взрослой настроен билдер в IDE с CMakeLists.txt, который собирает целую гору артефактов в отдельную папку. Сижу и тыкаю ран на main, где проверяю первые несколько строк из прочитанного csv, и получаю ошибку чтения файла! Проверяю код, смотрю исходный, думаю может там полный путь до файла надо указать, относительные не прокатят. Нет, смотрю, что все ок. Хм-хм… И только через какое-то время до меня доходит, что файл то лежит в корне, а ран запускается на собранный билд в отдельной папке. Мда.

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

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

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

И да, я прям рада, что нас заставили писать на плюсах. Не на питоне, не на JS, а именно на плюсах. Спасибо универу за это.

#Учеба, #UOL
Продолжение.
Да че там делов-то, вошли и вышли!

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

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

#Работа
Чуть больше 3 месяцев назад, когда я завершила очередную срочную и важную задачу со статусом блокер, на дейли митинге менеджер мне сказал, что у него СУПЕР срочная задача, в двух словах рассказал про нее и… не дал даже ссылки на тикет. В целом, хоть менеджер иногда и говорит про критичность и срочность, но чаще всего это означает, что задачу надо сделать быстрее, чем за год, как мне кажется. И нет, сами задачки не очень сложные или объемные, просто со всеми согласованиями и ожиданиями решений от других команд сроки решения очень сильно растягиваются.

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

⁃ Без ТЗ - результат ХЗ.
⁃ Это не ТЗ - это точка зрения заказчика!
⁃ Да вы вообще ТЗ писать не умеете.
⁃ Снова задача-тост!
(с) цитаты коллег-программистов

Я в прошлом менеджер, и даже не просто менеджер, который чисто за организацию, но и бизнес-аналитик, а иногда и аналитик данных. Вообще доводилось заниматься и маркетингом, статистикой, аналитикой, бизнес-процессами, прототипами, дизайном (интерфейсов и рекламных материалов, даже flash-баннеры приходилось клепать в Adobe Flash), даже с контент-менеджментом работала (как для поискового траффика, так и для контекстного).

Что нам стоит дом построить! Конечно, я не тащу на себя чужую шапку, не пытаюсь играть в роль менеджера, я просто стараюсь помочь менеджерам сделать их работу. За эту задачу я помимо кода наклепала 100500 разных выгрузок из данных для того, чтобы порешать какие-то проблемы. Обожаю джетовские IDE за то, что по SQL запросу можно сразу данные отправить в excel, это реально удобно.

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

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

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

На днях мы добрались до прода с этой задачей. А пост я решила написать потому что сегодня получила от одного из менеджеров: “Well done - congratulations!” по этой задаче чисто лично на email. При том, что он не участвовал в задаче, и вообще мы с ним почти не пересекались в работе. Это было неожиданно и приятно, хотя совсем непонятно почему он вдруг так обрадовался. Возможно, его задачка в беклоге ждет моего освобождения, чтобы я ее сделала 🙂

Ну и я рада, наконец минус несколько поздне-вечерних созвонов на неделе и минус постоянная работа на удаленной медленной тачке. Хехей!

#Работа
Менеджер назвал меня open-minded за то, что написала JS-скрипт, который в консоли браузера запускает запросы в UI, недоступные по API разработчика. То есть скрипт выполняет код, который по сути не должен был быть запущен на странице и использует куки и сессию пользователя для выполнения задач, как бы бот, который прикидывается пользователем для системы.

Проблема в том, что иногда в системе, с которой мы работаем, есть методы, используемые в их фронтенде, но эти же методы недоступны в интеграционных API для разработчиков. Хрен знает почему они их не добавили, просто времени не было или забыли. Обрабатывать все это вручную через UI долго: тебе надо открыть сотни страниц и нажать потом пару кнопок, когда скриптом можно это сделать буквально парой вызовов в цикле на количество элементов.

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

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

Парсинг и хакинг - расширяют наши возможности ХД
Однако, хочу сказать, что я искренне не люблю такие вещи, но делать это вручную - еще более отвратительно.

#UOL пришли результаты прошлой сессии. Не так чтобы прям супер, но сойдет. Я рада, что все в зачтено. По дискретке неожиданно даже много за экзамен. Хехей!