DEV Community

Thiago Matos
Thiago Matos

Posted on

🎯 Guia de Conhecimentos em Golang por Nível

Este documento serve como referência para entrevistas técnicas de desenvolvedores Go, organizando os conhecimentos esperados por nível de senioridade.


👶 Desenvolvedor Júnior

Fundamentos da Linguagem

  • Sintaxe básica: Variáveis, constantes, tipos de dados primitivos
  • Estruturas de controle: if/else, switch, for loops
  • Funções: Declaração, parâmetros, retorno múltiplo
  • Arrays e Slices: Diferenças e uso básico
  • Maps: Criação, inserção, leitura e deleção
  • Structs: Definição e uso básico
  • Ponteiros: Conceito básico e quando usar & e *
  • Packages: Importação e uso de pacotes da stdlib
  • Error handling: Tratamento básico de erros com if err != nil

Conceitos Básicos

  • Exported vs Unexported: Entender maiúsculas/minúsculas em identificadores
  • Zero values: Valores padrão dos tipos
  • Type conversion: Conversão entre tipos
  • String manipulation: Operações básicas com strings
  • fmt package: Printf, Sprintf, Println

Ferramentas Essenciais

  • go run: Executar programas Go
  • go build: Compilar programas
  • go fmt: Formatar código automaticamente
  • go mod init: Inicializar módulo Go
  • go get: Baixar dependências

Bibliotecas Standard Library (Básicas)

  • fmt - Formatação de I/O
  • strings - Manipulação de strings
  • strconv - Conversões string/números
  • os - Interação com sistema operacional
  • io - Interfaces básicas de I/O

Perguntas Sugeridas para Júnior

1. Explique a diferença entre array e slice

Resposta esperada:

  • Array tem tamanho fixo definido em tempo de compilação [5]int
  • Slice é dinâmico, referência para um array subjacente []int
  • Slice pode crescer com append()
  • Arrays são valores, slices são referências

2. O que são zero values? Dê exemplos

Resposta esperada:

  • Valor padrão quando variável é declarada sem inicialização
  • int/float: 0
  • string: "" (vazia)
  • bool: false
  • pointer/slice/map/channel: nil

3. Como você declara uma variável em Go? Quais as diferentes formas?

Resposta esperada:

var x int = 10          // declaração completa
var x = 10              // tipo inferido
x := 10                 // declaração curta (apenas em funções)
var x int               // declarada com zero value
Enter fullscreen mode Exit fullscreen mode

4. O que acontece se você não tratar um erro retornado por uma função?

Resposta esperada:

  • O compilador não força tratamento de erro
  • Variável err fica ignorada (usar _ para explícito)
  • Pode causar bugs silenciosos em runtime
  • Boa prática: sempre verificar if err != nil

5. Qual a diferença entre make e new?

Resposta esperada:

  • new(T): aloca memória zerada, retorna *T (ponteiro)
  • make(T): inicializa slice/map/channel, retorna T (não ponteiro)
  • new para qualquer tipo, make apenas para slice, map, channel
  • make pode especificar capacidade: make([]int, 0, 10)

6. Como funciona o retorno múltiplo de funções?

Resposta esperada:

func divide(a, b int) (int, error) {
    if b == 0 {
        return 0, errors.New("divisão por zero")
    }
    return a / b, nil
}

result, err := divide(10, 2)
Enter fullscreen mode Exit fullscreen mode
  • Go permite retornar múltiplos valores
  • Comum retornar (resultado, error)
  • Pode usar retornos nomeados

🧑‍💻 Desenvolvedor Pleno

Conhecimentos Avançados da Linguagem

  • Interfaces: Definição, implementação implícita, type assertion
  • Goroutines: Criação e conceitos de concorrência
  • Channels: Comunicação entre goroutines, buffered vs unbuffered
  • Select statement: Multiplexing de channels
  • Defer: Uso e ordem de execução
  • Panic e Recover: Quando e como usar
  • Methods: Receivers (value vs pointer)
  • Embedding: Composição de structs
  • Type assertions e Type switches
  • Generics (Go 1.18+): Sintaxe básica e uso

Padrões e Boas Práticas

  • Error handling: Padrões idiomáticos, custom errors
  • Context package: Cancelamento e timeouts
  • Dependency injection: Injeção de dependências
  • Clean Architecture: Separação de camadas
  • SOLID principles aplicados em Go
  • Table-driven tests: Padrão de testes em Go
  • Naming conventions: Convenções de nomenclatura

Ferramentas e Ecosystem

  • go test: Testes unitários e de integração
  • go mod: Gerenciamento completo de dependências
  • go vet: Análise estática de código
  • golangci-lint: Linting avançado
  • go generate: Geração de código
  • Delve: Debugger para Go
  • pprof: Profiling de performance

Bibliotecas Standard Library (Intermediárias)

  • net/http - Servidor HTTP e cliente
  • encoding/json - Serialização JSON
  • database/sql - Interface de banco de dados
  • context - Controle de contexto e cancelamento
  • sync - Primitivas de sincronização (Mutex, WaitGroup, Once)
  • time - Manipulação de tempo
  • log - Logging básico
  • testing - Framework de testes

Frameworks e Bibliotecas Populares

  • Web Frameworks: Gin, Echo, Fiber, Chi
  • ORMs: GORM, sqlx, ent
  • Validation: go-playground/validator
  • Configuration: Viper, envconfig
  • Testing: testify, gomock

Banco de Dados

  • Uso de database/sql com drivers (postgres, mysql)
  • Preparação de statements
  • Transações
  • Connection pooling
  • Migrations (golang-migrate, goose)

Perguntas Sugeridas para Pleno

1. Explique como funcionam as goroutines e o scheduler do Go

Resposta esperada:

  • Goroutines são threads leves gerenciadas pela runtime do Go
  • Scheduler usa modelo M:N (M goroutines em N threads OS)
  • Componentes: G (goroutine), M (thread OS), P (processador lógico)
  • Work stealing: P rouba goroutines de outras filas quando ociosas
  • Preemptivo desde Go 1.14

2. Qual a diferença entre buffered e unbuffered channels?

Resposta esperada:

  • Unbuffered make(chan int): send bloqueia até receive
  • Buffered make(chan int, 10): send só bloqueia se buffer cheio
  • Unbuffered garante sincronização
  • Buffered permite assincronia limitada

3. Quando você usaria um pointer receiver vs value receiver?

Resposta esperada:

  • Pointer receiver: modificar estado, grandes structs, consistência
  • Value receiver: imutabilidade, pequenas structs, tipos primitivos
  • Regra: se algum método usa pointer, todos devem usar
func (p *Person) SetName(n string) { p.name = n } // pointer
func (p Person) GetName() string { return p.name } // value ok
Enter fullscreen mode Exit fullscreen mode

4. Como você implementaria um rate limiter usando channels?

Resposta esperada:

limiter := time.Tick(100 * time.Millisecond)
for req := range requests {
    <-limiter  // bloqueia até próximo tick
    go handle(req)
}
Enter fullscreen mode Exit fullscreen mode

Ou usar golang.org/x/time/rate com token bucket

5. Explique o padrão de erro idiomático em Go e como criar custom errors

Resposta esperada:

// Padrão idiomático
result, err := doSomething()
if err != nil {
    return fmt.Errorf("failed to do something: %w", err)
}

// Custom error
type ValidationError struct {
    Field string
    Message string
}
func (e *ValidationError) Error() string {
    return fmt.Sprintf("%s: %s", e.Field, e.Message)
}
Enter fullscreen mode Exit fullscreen mode
  • Usar %w para wrapping (Go 1.13+)
  • errors.Is() e errors.As() para verificação

6. Como funciona o Context e quando você deve usá-lo?

Resposta esperada:

  • Propaga cancelamento, timeouts e valores entre goroutines
  • Primeiro parâmetro de funções por convenção
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
defer cancel()
Enter fullscreen mode Exit fullscreen mode
  • Usar para: requests HTTP, queries DB, operações longas
  • Não usar para: passar dependências opcionais

7. Qual a diferença entre sync.Mutex e sync.RWMutex?

Resposta esperada:

  • Mutex: lock exclusivo (escrita ou leitura)
  • RWMutex: múltiplos readers ou um writer
  • RWMutex otimiza cenários read-heavy
mu.RLock()   // múltiplas goroutines podem ler
mu.RUnlock()
mu.Lock()    // exclusivo para escrita
mu.Unlock()
Enter fullscreen mode Exit fullscreen mode

8. Como você estruturaria uma aplicação web em Go?

Resposta esperada:

/cmd/api       - entry point
/internal
  /handlers    - HTTP handlers
  /services    - business logic
  /repository  - data access
  /models      - domain models
/pkg           - código reutilizável
/migrations    - DB migrations
Enter fullscreen mode Exit fullscreen mode
  • Dependency injection
  • Interface-based design
  • Separação de camadas

9. Explique o que é race condition e como detectar em Go

Resposta esperada:

  • Múltiplas goroutines acessando mesma memória, pelo menos uma escrevendo
  • Comportamento não-determinístico
  • Detectar: go run -race main.go ou go test -race
  • Prevenir: channels, sync.Mutex, sync/atomic

🎓 Desenvolvedor Sênior

Expertise Técnica Profunda

  • Runtime internals: Garbage collector, scheduler, memory model
  • Performance optimization: Benchmarking, profiling, otimizações
  • Concurrency patterns: Worker pools, pipeline, fan-out/fan-in
  • Memory management: Stack vs heap allocation, escape analysis
  • Reflection: Package reflect, quando usar e trade-offs
  • Unsafe package: Quando é apropriado e riscos
  • Assembly: Leitura básica de assembly output
  • Build tags e conditional compilation
  • CGo: Integração com C, trade-offs de performance

Arquitetura e Design

  • Microservices: Design, comunicação, patterns
  • Domain-Driven Design em Go
  • Hexagonal Architecture / Ports & Adapters
  • Event-driven architecture
  • CQRS e Event Sourcing
  • API Design: REST, gRPC, GraphQL
  • Distributed systems: CAP theorem, eventual consistency
  • Message queues: RabbitMQ, Kafka, NATS

Observabilidade e Reliability

  • Structured logging: zap, zerolog
  • Metrics: Prometheus, OpenTelemetry
  • Tracing: Jaeger, OpenTelemetry
  • Monitoring: Grafana, alerting
  • Circuit breakers e retry policies
  • Rate limiting e backpressure
  • Load balancing
  • Health checks e readiness probes

DevOps e Deployment

  • Docker: Criação de imagens otimizadas multi-stage
  • Kubernetes: Deployment, Services, ConfigMaps, Secrets
  • CI/CD: GitLab CI, GitHub Actions, Jenkins
  • Infrastructure as Code: Terraform, CloudFormation
  • Cloud platforms: AWS, GCP, Azure com Go SDKs
  • Service mesh: Istio, Linkerd

Segurança

  • Authentication/Authorization: JWT, OAuth2, OIDC
  • Cryptography: TLS, encryption at rest
  • Input validation e sanitization
  • SQL injection prevention
  • Secrets management: Vault, AWS Secrets Manager
  • Security best practices: OWASP Top 10

Testing Avançado

  • Test coverage: Estratégias para cobertura efetiva
  • Mocking: gomock, testify/mock
  • Integration tests: testcontainers-go
  • E2E tests: Estratégias de teste end-to-end
  • Contract testing: Pact
  • Load testing: k6, vegeta
  • Chaos engineering: Princípios e ferramentas

Performance

  • Profiling: CPU, memory, goroutine, mutex profiling
  • Benchmarking: Microbenchmarks, análise de resultados
  • Optimization: Hot path optimization, algoritmos eficientes
  • Memory leaks: Detecção e prevenção
  • Caching strategies: Redis, in-memory caching
  • Database optimization: Indexing, query optimization

Ferramentas Avançadas

  • go:generate: Templates, protobuf, mocks
  • Wire: Dependency injection automática
  • Buf: Gerenciamento de Protocol Buffers
  • Task/Make: Build automation
  • govulncheck: Verificação de vulnerabilidades
  • staticcheck: Análise estática avançada

Liderança Técnica

  • Code review: Habilidade de revisar código efetivamente
  • Mentoria: Capacidade de ensinar e guiar júniores/plenos
  • Architectural decisions: Trade-offs e decisões de arquitetura
  • Technical debt: Identificação e gerenciamento
  • RFC/ADR: Documentação de decisões técnicas
  • Performance budgets: Definição e monitoramento
  • Migration strategies: Estratégias de migração de sistemas legados

Comunidade e Ecosystem

  • Go Proverbs: Conhecimento dos princípios da linguagem
  • Go proposals: Acompanhamento de novas features
  • Open source: Contribuição em projetos Go
  • Tendências: Conhecimento das últimas tendências em Go
  • Go conferences: Acompanhamento de talks e keynotes

Bibliotecas e Frameworks Avançados

  • gRPC: Implementação completa de serviços
  • Protocol Buffers: Definição de schemas
  • GraphQL: go-graphql, gqlgen
  • Temporal/Cadence: Workflow orchestration
  • NATS: Messaging system
  • etcd: Service discovery e configuration
  • Consul: Service mesh e discovery

Perguntas Sugeridas para Sênior

1. Explique como funciona o garbage collector do Go e suas otimizações

Resposta esperada:

  • GC concurrent tri-color mark-and-sweep
  • STW (Stop-The-World) minimizado (<1ms em Go 1.5+)
  • Write barriers durante marking phase
  • Tuneable com GOGC (padrão 100 = 100% overhead)
  • Otimizações: escape analysis move alocações para stack

2. Como você identificaria e resolveria um memory leak em produção?

Resposta esperada:

  • pprof para heap profile: go tool pprof http://localhost:6060/debug/pprof/heap
  • Comparar snapshots: base vs current
  • Monitorar goroutine leaks: /debug/pprof/goroutine
  • Procurar: maps sem cleanup, goroutines sem término, channels não fechados
  • Solução: defer cleanup, context cancelation, timeouts

3. Descreva a implementação de um worker pool otimizado usando goroutines

Resposta esperada:

func workerPool(jobs <-chan Job, results chan<- Result, workers int) {
    var wg sync.WaitGroup
    for i := 0; i < workers; i++ {
        wg.Add(1)
        go func() {
            defer wg.Done()
            for job := range jobs {
                results <- process(job)
            }
        }()
    }
    wg.Wait()
    close(results)
}
Enter fullscreen mode Exit fullscreen mode
  • Número de workers = runtime.NumCPU() ou baseado em I/O
  • Buffered channels para evitar blocking

4. Quando você usaria reflection e quais são os trade-offs?

Resposta esperada:

  • Casos: serialização (JSON), ORMs, dependency injection, testes
  • Trade-offs: performance (-10x a -100x), type safety perdida, complexidade
  • Evitar em hot paths
  • Alternativas: code generation, generics (Go 1.18+)

5. Como funciona escape analysis e como isso afeta performance?

Resposta esperada:

  • Determina se variável vai para stack ou heap
  • Stack: rápido, sem GC overhead
  • Heap: escapa se: retornada, armazenada em estrutura global, muito grande
  • Ver decisões: go build -gcflags='-m'
  • Otimizar: retornar values em vez de pointers quando possível

6. Explique diferentes estratégias de graceful shutdown em serviços Go

Resposta esperada:

quit := make(chan os.Signal, 1)
signal.Notify(quit, syscall.SIGINT, syscall.SIGTERM)
<-quit

ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
defer cancel()
if err := srv.Shutdown(ctx); err != nil {
    log.Fatal(err)
}
Enter fullscreen mode Exit fullscreen mode
  • Drain connection pools, finalizar goroutines, flush buffers
  • Health check retorna unhealthy imediatamente

7. Como você implementaria um sistema distribuído de rate limiting?

Resposta esperada:

  • Sliding window com Redis: INCR key, EXPIRE key ttl
  • Token bucket distribuído: Redis sorted sets
  • Algoritmos: leaky bucket, sliding window counter
  • Considerar: latência rede, consistência eventual, fallback local

8. Descreva sua abordagem para migrar um monolito para microservices em Go

Resposta esperada:

  • Estratégia strangler fig pattern
  • Identificar bounded contexts (DDD)
  • Extrair serviços por domínio, não por camada
  • API Gateway para roteamento
  • Event-driven communication (NATS/Kafka)
  • Database per service gradualmente
  • Feature flags para rollback

9. Como você garantiria zero-downtime deployment?

Resposta esperada:

  • Blue-green deployment ou rolling update
  • Health checks (readiness/liveness probes)
  • Graceful shutdown
  • Database migrations backward compatible
  • Feature toggles
  • Load balancer draining
  • Monitoring e rollback automático

10. Explique o memory model do Go e como prevenir race conditions sutis

Resposta esperada:

  • Happens-before relationship
  • Channel operations garantem sincronização
  • sync/atomic para operações atômicas
  • Evitar: unsynchronized shared memory
  • Usar -race detector sempre
  • Patterns: channels, mutexes, sync.Once

11. Como você otimizaria uma aplicação Go que está com alto uso de CPU?

Resposta esperada:

  • CPU profiling: go tool pprof http://localhost:6060/debug/pprof/profile?seconds=30
  • Identificar hot paths (top functions)
  • Otimizações: algoritmos (O(n²) → O(n log n)), pools (sync.Pool), reduce allocations
  • Benchmarks antes/depois: go test -bench=. -benchmem
  • Considerar: caching, lazy evaluation, concurrency

12. Descreve como implementaria observabilidade completa em um sistema distribuído

Resposta esperada:

  • Logging: structured logs (zap/zerolog), correlation IDs
  • Metrics: Prometheus (RED/USE method), custom business metrics
  • Tracing: OpenTelemetry, propagação de trace context
  • Dashboards: Grafana com SLI/SLO
  • Alerting: baseado em SLOs, runbooks
  • Instrumentação automática vs manual

13. Quais são os trade-offs entre diferentes patterns de error handling em Go?

Resposta esperada:

  • if err != nil: verboso mas explícito
  • panic/recover: apenas para erros irrecuperáveis
  • Sentinel errors vs error types vs wrapped errors
  • errors.Is/As vs type assertion
  • Error wrapping: contexto vs stack trace
  • Considerações: performance, debugabilidade, API clarity

14. Como você faria profiling de uma aplicação em produção sem impactar performance?

Resposta esperada:

  • Ativar pprof endpoints com autenticação
  • Sample rate baixo (30s, não continuous)
  • Apenas em subset de instâncias
  • Off-peak hours se possível
  • Usar -seconds=30 para limitar duração
  • Continuous profiling tools: Google Cloud Profiler, Datadog
  • Overhead < 5% aceitável

15. Explique sua estratégia para testing em uma arquitetura de microservices

Resposta esperada:

  • Unit tests: lógica de negócio isolada, mocks
  • Integration tests: testcontainers-go para dependencies
  • Contract tests: Pact entre consumers/providers
  • E2E tests: cenários críticos, ambiente staging
  • Chaos testing: simular falhas (latency, network partition)
  • Test pyramid: muito unit, médio integration, pouco E2E
  • CI/CD com coverage mínimo (80%+)

🎯 Guia de Nivelamento Interativo

Esta seção ajuda você a identificar o nível do desenvolvedor quando você não tem certeza. Use o fluxograma abaixo para fazer perguntas progressivas e deduzir o nível baseado nas respostas.

Como Usar

  1. Comece com a Pergunta Inicial (P1)
  2. Avalie a resposta do candidato
  3. Siga o fluxo baseado na qualidade da resposta
  4. Faça perguntas de confirmação
  5. Chegue a uma conclusão sobre o nível

Fluxograma de Nivelamento

P1: Explique a diferença entre slice e array em Go

Nível Resposta Indicadores Dedução
❌ Inadequada Não sabe, confunde conceitos, diz que são iguais Abaixo de Júnior
✓ Básica "Array fixo, slice dinâmico", menciona append() Júnior potencial → P2
✓✓ Completa Implementação interna, slice como referência, capacity vs length, performance Pleno+ → P3

P2: Como você trataria erros em Go?

Nível Resposta Indicadores Dedução
❌ Inadequada Apenas if err != nil sem contexto adicional Júnior confirmado
✓ Intermediária Wrap errors com %w, contexto nas mensagens Pleno potencial → P4
✓✓ Avançada Custom errors, errors.Is/As, patterns idiomáticos Pleno+ → P5

P3: Explique como funcionam as goroutines e o scheduler do Go

Nível Resposta Indicadores Dedução
❌ Inadequada "São threads leves" sem mais detalhes Pleno potencial → P4
✓ Intermediária M:N threading, G-M-P model, conceitos corretos Pleno+ → P5
✓✓ Avançada Work stealing, preemption, detalhes de implementação Sênior potencial → P6

P4: Quando você usaria um pointer receiver vs value receiver?

Nível Resposta Indicadores Dedução
❌ Inadequada Não sabe quando usar Júnior confirmado
✓ Intermediária Mutação vs imutabilidade, performance básica Pleno potencial → P7
✓✓ Avançada Escape analysis, consistency rules, trade-offs Pleno+ → P8

P5: Como você implementaria um rate limiter usando channels?

Nível Resposta Indicadores Dedução
❌ Inadequada Não consegue ou implementação errada Pleno confirmado
✓ Intermediária time.Tick ou buffered channel básico Pleno+ → P8
✓✓ Avançada Token bucket, bibliotecas x/time/rate, distribuído Sênior potencial → P9

P6: Como você identificaria e resolveria um memory leak em produção?

Nível Resposta Indicadores Dedução
❌ Inadequada Não sabe ferramentas ou processo Pleno confirmado
✓ Intermediária Menciona pprof, processo básico de investigação Sênior potencial → P9
✓✓ Avançada pprof detalhado, goroutine leaks, continuous profiling Sênior potencial → P10

P7: O que é race condition e como detectar em Go?

Nível Resposta Indicadores Dedução
❌ Inadequada Conceito vago ou incorreto Júnior confirmado
✓ Boa Explica bem, menciona -race, sync primitives Pleno confirmado

P8: Como você estruturaria uma aplicação web em Go?

Nível Resposta Indicadores Dedução
❌ Inadequada Tudo em um arquivo ou sem separação clara Pleno confirmado
✓ Intermediária Handler/Service/Repository básico Pleno confirmado
✓✓ Avançada Hexagonal/Clean arch, DI, interfaces bem definidas Sênior potencial → P11

P9: Descreva sua abordagem para migrar um monolito para microservices em Go

Nível Resposta Indicadores Dedução
❌ Inadequada Sem experiência ou estratégia Pleno confirmado
✓ Intermediária Strangler pattern, bounded contexts Sênior potencial → P12
✓✓ Avançada DDD completo, event-driven, database per service Sênior potencial → P13

P10: Como você faria profiling de uma aplicação em produção sem impactar performance?

Nível Resposta Indicadores Dedução
❌ Inadequada Não considerou impacto Pleno confirmado
✓ Intermediária Sample rate, subset de instâncias Sênior confirmado
✓✓ Avançada Continuous profiling, overhead budget, ferramentas enterprise Sênior confirmado

P11: Quais são os trade-offs entre diferentes patterns de error handling em Go?

Nível Resposta Indicadores Dedução
❌ Inadequada Conhece apenas if err != nil Pleno confirmado
✓ Intermediária Sentinel vs wrapped, trade-offs básicos Sênior confirmado
✓✓ Avançada Performance, debugabilidade, API design Sênior confirmado

P12: Como você garantiria zero-downtime deployment?

Nível Resposta Indicadores Dedução
❌ Inadequada Não sabe estratégias Pleno confirmado
✓ Intermediária Blue-green ou rolling, health checks Sênior confirmado
✓✓ Avançada Graceful shutdown completo, migrations compatíveis Sênior confirmado

P13: Como você implementaria observabilidade completa em um sistema distribuído?

Nível Resposta Indicadores Dedução
❌ Inadequada Apenas logging isolado Pleno confirmado
✓ Intermediária Logs + Metrics + Tracing, ferramentas Sênior confirmado
✓✓ Avançada OpenTelemetry, correlation IDs, SLI/SLO, runbooks Sênior confirmado

💡 Dicas de Uso

  • Flexibilidade: Você não precisa seguir todas as perguntas se já tiver certeza do nível
  • Adaptação: Ajuste perguntas baseado no contexto da vaga
  • Observação: Preste atenção não só no que dizem, mas em COMO explicam
  • Profundidade: Faça follow-ups para confirmar entendimento real vs decorado
  • Prática: Candidatos podem saber teoria mas não ter prática (ou vice-versa)

⚠️ Sinais de Alerta

  • Red Flags para qualquer nível:

    • Respostas decoradas sem entendimento
    • Não admite quando não sabe
    • Defensivo ao receber perguntas mais difíceis
    • Não consegue explicar com exemplos práticos
  • Green Flags:

    • Admite quando não sabe algo específico
    • Relaciona conceitos entre si
    • Dá exemplos de experiências reais
    • Faz perguntas de volta para clarificar contexto

📊 Conhecimentos por Categoria

Categorização Visual

Júnior  ▓▓▓▓▓▓▓▓░░░░░░░░░░░░  Sintaxe e Fundamentos
Pleno   ▓▓▓▓▓▓▓▓▓▓▓▓▓▓░░░░░░  Padrões e Ferramentas
Sênior  ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓  Arquitetura e Liderança
Enter fullscreen mode Exit fullscreen mode

💡 Dicas para Entrevistas

Para Avaliar Júnior

  • Foque em fundamentos: sintaxe, tipos de dados, estruturas básicas
  • Peça para resolver problemas simples de algoritmos
  • Avalie a capacidade de ler e entender código
  • Teste conhecimento de error handling básico

Para Avaliar Pleno

  • Apresente cenários reais de desenvolvimento
  • Peça para desenhar arquitetura de uma API REST
  • Avalie conhecimento de testes e boas práticas
  • Discuta trade-offs de diferentes abordagens
  • Código review de um snippet com problemas

Para Avaliar Sênior

  • Discussões de arquitetura em alto nível
  • Resolução de problemas de produção (debugging, performance)
  • Decisões técnicas com justificativas baseadas em trade-offs
  • Capacidade de mentoria e liderança técnica
  • Conhecimento de design distribuído e escalabilidade

🔗 Recursos Recomendados

Livros

  • Júnior: "The Go Programming Language" (Donovan & Kernighan)
  • Pleno: "Concurrency in Go" (Katherine Cox-Buday)
  • Sênior: "Distributed Services with Go" (Travis Jeffery)

Websites

Practice

Top comments (0)