Я работал QA-инженером с 2019 года и в феврале 2025 года принял решение целенаправленно идти в backend. Прошло ровно восемь месяцев практики, кодинга и интервью — и в октябре 2025 я получил оффер на должность junior/mid backend-разработчика.
Начальная точка и цель
На момент старта у меня был опыт ручного и автоматизированного тестирования: Selenium, тест-планы, баг-репорты, базовые скрипты на Python для парсинга логов. Я не имел продвинутого опыта разработки серверной логики, но понимал жизненный цикл релиза, CI/CD и как устроены HTTP-запросы. Моя конкретная цель — через 8 месяцев получить первый оффер на backend-роль с реальными обязанностями над кодом (не только поддержка тестов), работать с Go и реляционными БД.
Я поставил чёткий план: учиться 20–25 часов в неделю, реализовать полноценный pet-проект с API, подготовиться к собеседованиям и подать 40–60 резюме. Начало: 1 февраля 2025, крайний срок — 1 октября 2025.
Шаг 1: Go и SQL
Когда я выбирал стек, учитывал рынковую востребованность и свой опыт: Go — популярный язык в backend, понятный синтаксис, статическая типизация. SQL — обязательный навык для большинства backend-вакансий. Первые два месяца (февраль — март 2025) были посвящены именно этим базам.
Учебный план и таймлайн
- Февраль 2025: синтаксис Go, основы типов, горутины, каналы — 120 часов (примерно 20–25 часов/неделю).
- Март 2025: SQL, нормализация, индексы, JOIN-ы, транзакции — 80 часов.
- Апрель 2025: практика с базами, подключение Go к PostgreSQL, ORM vs sqlx — 100 часов.
Конкретные ресурсы
- Книга «The Go Programming Language» и официальный сайт go.dev для справки по стандартной библиотеке.
- Курс по SQL на платформе с интерактивными задачами (проходил 120 задач по запросам за март).
- Документация PostgreSQL, статьи по EXPLAIN и оптимизации запросов.
Примеры кода
Минимальный пример HTTP-сервера на Go, который я писал первые недели:
package main
import (
"database/sql"
"fmt"
"log"
"net/http"
_ "github.com/lib/pq"
)
func main() {
http.HandleFunc("/health", func(w http.ResponseWriter, r *http.Request) {
fmt.Fprintln(w, "ok")
})
db, err := sql.Open("postgres", "host=localhost port=5432 user=dev dbname=test sslmode=disable")
if err != nil {
log.Fatal(err)
}
defer db.Close()
http.HandleFunc("/users", func(w http.ResponseWriter, r *http.Request) {
rows, err := db.Query("SELECT id, name FROM users LIMIT 10")
if err != nil {
http.Error(w, err.Error(), 500)
return
}
defer rows.Close()
for rows.Next() {
var id int
var name string
rows.Scan(&id, &name)
fmt.Fprintf(w, "%d: %s
", id, name)
}
})
log.Println("listening :8080")
http.ListenAndServe(":8080", nil)
}
Простой SQL для создания таблицы и запроса, который я использовал при тестировании производительности:
CREATE TABLE users (
id SERIAL PRIMARY KEY,
name TEXT NOT NULL,
email TEXT UNIQUE NOT NULL,
created_at TIMESTAMP DEFAULT now()
);
-- запрос с индексом
CREATE INDEX idx_users_email ON users(email);
-- выборка с фильтрацией и сортировкой
SELECT id, name FROM users WHERE email LIKE '%@example.com' ORDER BY created_at DESC LIMIT 50;
Оценка прогресса
Через три месяца у меня уже был рабочий сервис на Go, подключённый к PostgreSQL. Я мог объяснить кандидатам по работе приложения жизненный цикл запроса, транзакции и отладку гонок (race conditions). Это дало мне уверенность для создания pet-проекта на следующем шаге.
Шаг 2: pet-проект
Pet-проект стал ключевым доказательством моих навыков на собеседованиях. Я потратил апрель — июнь 2025 на реализацию полнофункционального сервиса: небольшой таск-трекер с REST API, авторизацией, миграциями и CI.
Требования к проекту
- API для CRUD задач (Tasks): создание, чтение, обновление, удаление.
- Аутентификация по JWT, регистрация и логин.
- Миграции схемы (использовал golang-migrate).
- Dockerfile и docker-compose для локального развертывания.
- CI: GitHub Actions с линтингом и unit-тестами.
Архитектура и стек
- Ядро: Go 1.20, стандартный net/http + chi router для удобства.
- БД: PostgreSQL 14, sqlx для упрощённой работы с SQL.
- Миграции: golang-migrate.
- Контейнеризация: Docker, docker-compose.
- CI: GitHub Actions — запуск тестов и сборки образа.
Ключевые файлы и примеры
Пример handler'a для создания задачи:
func CreateTaskHandler(db *sql.DB) http.HandlerFunc {
return func(w http.ResponseWriter, r *http.Request) {
var req struct{ Title string `json:"title"` }
if err := json.NewDecoder(r.Body).Decode(&req); err != nil {
http.Error(w, "bad request", http.StatusBadRequest)
return
}
var id int
err := db.QueryRow("INSERT INTO tasks (title) VALUES ($1) RETURNING id", req.Title).Scan(&id)
if err != nil {
http.Error(w, err.Error(), http.StatusInternalServerError)
return
}
w.WriteHeader(http.StatusCreated)
json.NewEncoder(w).Encode(map[string]int{"id": id})
}
}
docker-compose.yml (фрагмент):
version: '3.8'
services:
db:
image: postgres:14
environment:
POSTGRES_USER: dev
POSTGRES_PASSWORD: dev
POSTGRES_DB: tasks
ports:
- "5432:5432"
app:
build: .
depends_on:
- db
ports:
- "8080:8080"
Что тестировал в проекте
- Unit-тесты обработки запросов и бизнес-логики (покрытие ~60%).
- Интеграция с базой: тесты с тестовой БД (в CI запускал контейнер Postgres).
- Нагрузочные прогоны: ab и locust для проверки простейших bottleneck-ов.
Проект занял меня примерно 10 часов/неделю в течение трёх месяцев. К моменту активного поиска работы репозиторий имел README с инструкцией развертывания, описание API и ссылки на CI-пайплайн. Это значительно увеличило отклик от работодателей по сравнению с шаблонным резюме.
Шаг 3: собеседования
С мая 2025 я начал активно рассылать резюме и проходить собеседования. За период май — сентябрь 2025 я подал 58 резюме, прошёл 18 телефонных скринов и 9 технических интервью. Ключевое — регулярная подготовка и учёт типичных задач для backend.
Подготовка к техзаданиям
- Алгоритмы: базовые структуры данных и алгоритмы (списки, хеш-таблицы, BFS/DFS) — 2–3 задачи в неделю.
- SQL: оптимизация запросов, объяснение планов выполнения (EXPLAIN) — решал 5 задач в неделю.
- Системный дизайн: простые сервисы (авторизация, очередь задач, rate limiting) — делал макеты архитектуры на бумаге и в Draw.io.
Типичные задания и ответы
Пример задания на собеседовании: «Напишите SQL-запрос, который для каждой задачи возвращает количество комментариев за последние 30 дней и сортирует по убыванию». Мой ответ:
SELECT t.id, t.title, COUNT(c.id) AS comments_count
FROM tasks t
LEFT JOIN comments c ON c.task_id = t.id AND c.created_at >= now() - interval '30 days'
GROUP BY t.id, t.title
ORDER BY comments_count DESC;
Если спрашивали про гонки в Go — показывал пример использования mutex и channels, объяснял difference между buffered и unbuffered channels и как отлавливать race с помощью go test -race.
Ошибки на интервью и их исправление
- Ошибка: пытался дать слишком общий ответ на дизайн-схемы. Исправление: стал сразу рисовать компонентную диаграмму и обсуждать trade-offs.
- Ошибка: при первом тестовом задании допустил SQL-инъекцию. Исправление: перешёл на подготовленные выражения и продемонстрировал это в коде.
- Ошибка: плохо объяснял асинхронность в Go. Исправление: подготовил короткий пример с goroutine, waitgroup и channel, чтобы показать практическую пользу.
Первый оффер
В октябре 2025 одну из компаний заинтересовал мой pet-проект и мой подход к решению задач: стартап в сфере B2B SaaS предложил позицию «Backend Engineer (Go)» с официальным оффером 180 000 ₽ в месяц на руки (gross 220 000 ₽) и опционами. Условия: гибридный режим, обучение внутри команды, участие в ревью кода. Оффер пришёл после финального интервью 28 сентября 2025; переговоры о зарплате завершились 3 октября 2025.
Как устроился процесс найма
- Первичный скрининг HR — 15 минут (культура, ожидания по зарплате).
- Техническое интервью — 60 минут: алгоритмы + SQL.
- Практическое задание: до 48 часов на реализацию простого API (CRUD + аутентификация).
- Код-ревью и финальная беседа с техлидом — обсуждение архитектуры проекта и планов роста.
Почему мне дали оффер
- Наличие законченного pet-проекта с CI и докеризацией.
- Понимание жизненного цикла запросов и базовых практик backend.
- Опыт работы в QA дал преимущество в тестированности кода: я писал тесты и понимал, как воспроизводить баги и фиксить их.
Переход из QA в backend не требует магии — нужна системность: фундаментальные знания, работающий проект и регулярная практика в интервью.
Что бы сделал иначе
Оглядываясь назад, я вижу несколько конкретных вещей, которые можно было бы улучшить и ускорить переход.
1. Больше внимания системному дизайну
Я недооценил важность понимания распределённых систем на более высоком уровне. Если бы я начал заниматься дизайн-уровнем в марте 2025 (а не в июле), то на собеседованиях я чувствовал бы себя увереннее при обсуждении очередей, k8s и схем репликации БД.
2. Раннее участие в open-source
Если бы в апреле 2025 я начал вносить вклад в небольшие open-source проекты на Go, это бы добавило доверия к моему профилю. Даже 3–5 PR в популярных репозиториях демонстрируют умение работать с чужим кодом и проходить code review.
3. Больше интеграционных тестов и нагрузочного тестирования
Я потратил много времени на unit-тесты, но интеграционные и нагрузочные тесты появились позже, когда уже были первые собеседования. Рекомендую писать их параллельно с функционалом, чтобы иметь готовые отчёты при показе проекта работодателю.
4. Непрерывная подготовка к собеседованиям
Я занимался подготовкой волнообразно: интенсивно перед собеседованием, затем спад. Лучше держать темп — 3–4 задачи по алгоритмам и 2 SQL задачи в неделю стабильно. Это помогает не терять скорость мышления при интервью.
- Планируйте цели с конкретными датами: мой план 1 февраля — 1 октября 2025 с ежемесячными контрольными точками сработал.
- Пет-проект и его README = ключ к первому отклику.
- Покажите тесты и CI — это сразу отличает кандидата от «писателя кода» без контроля качества.
- Используйте опыт QA как преимущество: умение мыслить с точки зрения тестов — большая ценность для команды.
Переход занял ровно восемь месяцев и потребовал дисциплины, но дал не только оффер: это новый набор навыков и понимание, как строятся серверные приложения. Если вы стремитесь к аналогичной цели, делайте ставку на реальный код, тесты и простую, но закончную архитектуру — это то, что работодатели видят в первую очередь.
Если хотите, могу выложить чек-лист из моих заметок по подготовке (шаблоны резюме, вопросы на интервью и список задач для pet-проекта) — напишите, какую часть хотите в первую очередь.
Комментарии (0)
Войдите или зарегистрируйтесь, чтобы оставить комментарий
Загрузка комментариев…