Senior Golang Developer

Must-Haves Deep knowledge of Go and always updating your understanding of best practices Production experience with Go — you've seen real systems under real load Leadership experience — you can guide a team and make tough technical decisions Database skills — comfortable with SQL, database design, and performance optimization Learning mindset — this is what you do every day, naturally Testing philosophy — you write tests that actually test business logic, not just coverage Happy and positive attitude — because building great software should be fun Understand life — challenges and victories are both part of the journey Nice-to-Haves Experience with PostgreSQL, CockroachDB, Redis, ClickHouse Knowledge of Google Cloud Platform or similar Understanding of microservices and distributed systems Docker/Kubernetes experience Performance optimization and profiling skills Key Principles & Our "Real Go" PhilosophyWhat Makes Us Different No Repository/Service layers unless necessary — we prefer simple functions over complex abstractions Feature-based organization — code is organized by what it does, not by architectural layers Context for dependency injection — we use Go's context package instead of DI frameworks Real database testing — we test against actual databases, not mocks HTTP 200 for business errors — clear separation between technical and business failures Internal packages for shared code — proper encapsulation within modules Idiomatic Go Practices We Follow Error handling the Go way — explicit error returns, no exceptions or try-catch Interfaces are discovered, not declared — small, focused interfaces defined by consumers Composition over inheritance — embed structs and interfaces, avoid deep hierarchies Zero values are useful — design types so their zero value is ready to use Accept interfaces, return structs — flexible input, concrete output Don't panic in libraries — return errors instead, let callers decide Use Go modules properly — semantic versioning, minimal dependencies Follow Go naming conventions — MixedCaps for exported, camelCase for unexported Prefer clarity over cleverness — readable code beats "smart" code every time Use gofmt and go vet — consistent formatting and static analysis "Real Go" Testing Approach Use Real Database instead of Mocks — create separate test databases for each test case Complete Isolation — each test case has its own database, no interference between tests Automatic Setup/Teardown — databases are created and cleaned up automatically Real Test Data Preparation — create actual test data instead of mocking Test Real Business Logic — test validation, business rules, and database interactions together Don't mock HTTP requests to make tests look fancy Don't use httptest for testing business logic Don't test routing — test business logic directly Write focused tests — test actual working functions, not wrappers No Complex Mock Objects — reduce time and errors from writing mock objects Understand that good architecture = testable code without mocks Understanding of Example Project Required Read and understand "This is real Go" Deep dive into every file in the example project, understand the structure and rationale behind each package/module Understand the separation of business logic from transport layer Understand using context for dependency injection Understand database migration with embedded SQL files Anti-patterns We Reject Java-style OOP in Go (We Don't Want This) Repository/Service layers everywhere — Don't create interfaces just because "it's good practice" Dependency Injection frameworks — Use context instead of wire, dig, or fx Deep inheritance hierarchies — Go doesn't have classes for a reason Getters/Setters for everything — Use public fields when appropriate Factory patterns everywhere — Don't create factories of factories Manager/Controller/Service naming — If you need a "Manager", rethink your design Interface for every struct — Interfaces should be discovered, not declared upfront Mocking everything — Test with real databases, not mock objects 🎯 Key Principles We Follow Functions over methods — Use functions unless you need state Composition over inheritance — Embed structs, don't create hierarchies Explicit over implicit — Clear dependencies, no magic Simple over clever — Readable code beats "smart" code Direct over abstracted — Don't abstract until you need to Real over mocked — Test against real systems when possible 🔍 Red Flags in Code ReviewsIf we see these patterns, we'll ask you to refactor:-Multiple layers of abstraction for simple operations-Interfaces created "just in case"-Complex dependency injection setup-Testing HTTP handlers instead of business logic-Mocking databases for unit tests-Manager/Service/Controller naming everywhere-Deep struct embedding hierarchiesTech Stack We Actually Use (No Bloat)Core:-Go (standard library focused)-PostgreSQL / CockroachDB / Redis / ClickHouse-Docker / KubernetesInfrastructure & DevOps:-Google Cloud Platform-GitHub Actions-NATS / Google Cloud Pub/Sub-Docker / Kubernetes