Когда устроился на мидла тупо выучив вопросы с собесов

У прогеров свой мир😂

Брат порекомендовал курсы по Go. Понравилось его описание, поэтому скину без изменений))
👇👇👇😁

Понюхать запах гошки
https://stepik.org/course/100208/syllabus

Посмотреть на гошку
https://stepik.org/course/54403/syllabus

Всмотреться в гошку
https://stepik.org/course/158385/syllabus

Получить травму от гошки
https://stepik.org/course/187490/syllabus

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

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

Сейчас, раз вы еще не прошли собеседование, то подготовлены вы плохо. Следовательно, вам на решение средней задачи требуется 1,2,5 часов. А иногда день, два и может и неделя.

Решить надо 300, лучше 400 задач.

Если у вас есть в ВЕРНОМ порядке задачи с идеально вам понятным объяснением, просто чтобы послушать решение требуется 25 минут.

(25 * 400) / 60 = 167 часов только на задачи и только их ПОСЛУШАТЬ.

Еще к этому надо добавить 120 часов теории, чтобы понимать решения задач.

40 часов system design

10 часов soft skills

И это без конспектов, программирования или переслушивания материала.

Получаем: 167 + 120 + 40 + 10 = 337 часов

В день, если вы ходите на работу, в среднем вы можете уделять 1.5 часа на учебу.

Получаем 337/1.5 = 225 дней

Чтобы не сойти с ума, после 6 дней надо 1 день отдыхать.

Получается 225/6 = 38 дней выходных

Итого:

225 + 38 = 263 дня просто чтобы все ПРОСЛУШАТЬ и даже не программировать.

А ведь все это надо запрограммировать и законспектировать чтобы была возможность повторить.

То есть 263 дня превращаться в 365 с ходу.

Итого минимум 1 год требуется , если вы машина, а не человек, которая не устает и двигается по плану.


Можно где-то схитрить и что-то пропустить, это ускорит процесс на 15-20%, но все равно это будет около 10 месяцев.

Некоторые мои выводы по стратегии работы с гитом (не знающим Git не стоит читать):
В master вливаем только то, что можно сразу залить на прод. Раньше планировал вливать все ветки в master, залить мастер на дев-сервер, протестировать, а затем - на прод. Но оказалось, что не всегда можно быстро протестить и влить на прод. Тем более, что делать, если появилась необходимость сделать хот-фикс? Вот сделали мы хот-фикс и влили в мастер, а там ещё куча непротестированных изменений. В таком состоянии уже на вольёшь мастер на прод. Поэтому лучше всего, на мой взгляд, все ветки влить в дев-ветку. И после того, как всё протестировали - влить дев в мастер и мастер запушить на прод

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

https://devtoolcafe.com/tools/regex#!flags=img&re=

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

Задания по SQL подходят как новичкам, так и опытным специалистам.

https://sqltest.online

Три важных софт-скилла при найме

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

👉Самонаводимость – кандидат может сам решать задачи с высокой степенью неопределенности, доуточняя все детали и подключая помощь, где необходимо. Как проверить на интервью:
- Спросить про задачи с самыми туманными требованиями
- Узнать, как часто взаимодействовал с людьми за пределами команды
- Попросить рассказать про самую продолжительную задачу и понять, как он контролировал ее

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

Шпаргалка, которой часто пользуюсь - порядок написания операторов в запросе SQL и порядок их выполнения:

Порядок написания операторов в запросе SQL следующий:

SELECT -- перечисление полей результирующей таблицы
FROM -- указание источника данных
-- а тут вроде JOIN'ы и операции со множествами (А.С.)
WHERE -- фильтрация данных
GROUP BY -- группировка данных
HAVING -- фильтрация данных после группировки
ORDER BY -- сортировка результирующей таблицы
LIMIT -- ограничение количества выводимых записей

Порядок выполнения операторов в СУБД несколько отличается от порядка их написания в запросе. В упрощённом виде порядок выполнения запроса в PostgreSQL такой:

FROM -- указание источника данных
WHERE -- фильтрация данных
GROUP BY -- группировка данных
HAVING -- фильтрация данных после группировки
SELECT -- перечисление полей результирующей таблицы
ORDER BY -- сортировка результирующей таблицы
LIMIT -- ограничение количества выводимых записей

Т.е. порядок выполнения такой же, как и порядок написания, за исключением того, что `SELECT` выполняется после `HAVING`

#sql

Увидел у одного чела на аве)

Тот единственный разработчик, который знает как правильно работает легаси код