Senior Backend Golang Developer (SQL, Database)

Must-HavesDeep knowledge of Go and always updating your understanding of best practicesProduction experience with Go — you've seen real systems under real loadLeadership experience — you can guide a team and make tough technical decisionsDatabase skills — comfortable with SQL, database design, and performance optimizationLearning mindset — this is what you do every day, naturallyTesting philosophy — you write tests that actually test business logic, not just coverageHappy and positive attitude — because building great software should be funUnderstand life — challenges and victories are both part of the journeyNice-to-HavesExperience with PostgreSQL, CockroachDB, Redis, ClickHouseKnowledge of Google Cloud Platform or similarUnderstanding of microservices and distributed systemsDocker/Kubernetes experiencePerformance optimization and profiling skillsKey Principles & Our "Real Go" PhilosophyWhat Makes Us DifferentNo Repository/Service layers unless necessary — we prefer simple functions over complex abstractionsFeature-based organization — code is organized by what it does, not by architectural layersContext for dependency injection — we use Go's context package instead of DI frameworksReal database testing — we test against actual databases, not mocksHTTP 200 for business errors — clear separation between technical and business failuresInternal packages for shared code — proper encapsulation within modulesIdiomatic Go Practices We FollowError handling the Go way — explicit error returns, no exceptions or try-catchInterfaces are discovered, not declared — small, focused interfaces defined by consumersComposition over inheritance — embed structs and interfaces, avoid deep hierarchiesZero values are useful — design types so their zero value is ready to useAccept interfaces, return structs — flexible input, concrete outputDon't panic in libraries — return errors instead, let callers decideUse Go modules properly — semantic versioning, minimal dependenciesFollow Go naming conventions — MixedCaps for exported, camelCase for unexportedPrefer clarity over cleverness — readable code beats "smart" code every timeUse gofmt and go vet — consistent formatting and static analysis"Real Go" Testing ApproachUse Real Database instead of Mocks — create separate test databases for each test caseComplete Isolation — each test case has its own database, no interference between testsAutomatic Setup/Teardown — databases are created and cleaned up automaticallyReal Test Data Preparation — create actual test data instead of mockingTest Real Business Logic — test validation, business rules, and database interactions togetherDon't mock HTTP requests to make tests look fancyDon't use httptest for testing business logicDon't test routing — test business logic directlyWrite focused tests — test actual working functions, not wrappersNo Complex Mock Objects — reduce time and errors from writing mock objectsUnderstand that good architecture = testable code without mocksUnderstanding of Example Project RequiredRead and understand "This is real Go"Deep dive into every file in the example project, understand the structure and rationale behind each package/moduleUnderstand the separation of business logic from transport layerUnderstand using context for dependency injectionUnderstand database migration with embedded SQL filesAnti-patterns We RejectJava-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 fxDeep inheritance hierarchies — Go doesn't have classes for a reasonGetters/Setters for everything — Use public fields when appropriateFactory patterns everywhere — Don't create factories of factoriesManager/Controller/Service naming — If you need a "Manager", rethink your designInterface for every struct — Interfaces should be discovered, not declared upfrontMocking everything — Test with real databases, not mock objects🎯 Key Principles We FollowFunctions over methods — Use functions unless you need stateComposition over inheritance — Embed structs, don't create hierarchiesExplicit over implicit — Clear dependencies, no magicSimple over clever — Readable code beats "smart" codeDirect over abstracted — Don't abstract until you need toReal 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