This repository includes a list of "evergreen skills" that should serve as a fair assessment of skilled software engineers / developers.
The purpose of this work is to serve as an alternative resource for conducting technical interviews of software developers / engineers, when hiring. This document focuses on software development best practices, cross-framework principles and other portable skills; as opposed to the detrimental fixation on language trends and framework-specific knowledge that we often see in the industry.
Programming languages evolve constantly, companies change their tech stacks, frameworks quickly become outdated, and syntax-related questions can easily be looked up by skilled engineers in search engines in minutes, whenever they need it. So, does it make sense to focus on those aspects when interviewing candidates?
On the other hand, there are software development best practices, cross-framework technical principles and critical non-technical skills that cannot be easily googled, take time to learn, are "evergreen" and have a huge impact on engineer's performance. These are significantly better at reflecting the real value a software developer / engineer brings to an organization or team.
This repository is a derivative work of the following article: "What Makes a Great Software Engineer".
This is a work in progress. Important knowledge might be missing, existing bullets can probably be improved and better grouping strategies could be found. For those reasons, any contributions (i.e. PRs or issues) are welcome. Please feel free to propose changes following the contributing guideline.
- Non-technical skills
- Technical skills
The following non-technical skills are probably the most critical for an engineer to have. Being successful as a software engineer in a company becomes very hard without good communication, teamwork attitude, development-process knowledge, problem-solving skills and a learning mindset; despite the technical skills one may have.
- Follow e-mail best practices (e.g. some e-mail etiquette rules)
- Follow chat best practices (e.g. use threads to organize discussions and other best-practices from Slack)
- Minimize interruptions
- Be polite
- Practice empathy
- Keep low egos
- Be an active listener
- Be a good mentor
- Share knowledge
- Be constructive
- Know about Agile Software Development principles
- Be comfortable with iterative and incremental development
- Have self-organizing capabilities
- Avoid creating false expectations (e.g. with time estimates)
- Focus on priorities and business value
- Applying the Scientific Method
- Researching skills
- Lateral Thinking
- Abstraction
- Creativity
- 5 Whys
- Risk management
- Don't fear change
- Dare to fail
- Be a life-long learner
- Critical Thinking (be rational, question decisions, "let the facts do the talking")
There is evergreen technical knowledge that is relevant for any software engineer, despite the specific area in which they are going to be working on. To get a good understanding of their seniority and learn how solid their engineering practices are, you can keep a conversation with them on programming principles, data structures, clean code, source code management, technical collaboration and/or DevOps practices. If these foundations are solid, they will probably be able to learn the specifics needed for your particular case without problems.
- Basic control structures and boolean algebra
- OOP (Object Oriented Programming)
- SOLID, GRASP
- Functional programming (pure functions, immutability, recursion,...)
- Declarative vs Imperative programming
- Basic structures (basic types, array, matrix, object...)
- Caching / memoization
- Hash codes, tokens, encodings (e.g. Base64)
- Stack vs heap memory
- Acknowledge that naming is key to code readability (files, classes, variables / attributes, functions / methods...)
- Avoid long functions and classes, making sure to split responsibilities properly into methods/functions and/or classes/files
- Follow conventions to organize project structure
- Extract complex boolean conditions into well-named functions
- Try to write code that is as self-explanatory as possible (i.e. "what" the code does is easy to understand by reading it)
- Favor good naming and lightweight documentation over inline comments
- Code comments often lie and are usually shortcuts written to explain what a messy code block does, instead of investing the time in refactoring it to improve its readability
- Write documentation as code, ideally alongside code, for easier maintenance (e.g. markdown files in a "docs" folder in your repository)
- Use docs to describe "whys" and "hows" (e.g. goals, use cases, components, high-level architecture overview,...)
- In OOP, favor composition over inheritance
- Follow semantic versioning
- Know about TDD and its practices (e.g. "red, green, refactor")
- CVS (Control Version Systems) / SCM (Source Code Management) basics: branches, tags, centralized vs de-centralized,...
- SCM vs repository management / hosting (i. e. difference between Git and GitHub)
- Understand why versioning is important
- Commit best practices
- Micro commits / atomic commits, good descriptions...)
- Conventional commits
- Feature branches (short-lived)
- Trunk-based development
- Dependency management (the importance of package managers, the risks of dependency hell,...)
- Peer Code Review best practices
- TL;DR: Focus on the relevant pieces when performing code-reviews. The purpose is learning, not blaming.
- Pair Programming best practices
- Build automation
- Artifact repositories and image registries
- Write automated tests
- Differences between unit, integration and end-to-end (e2e) tests
- Test pyramid
- Continuous Integration
- Continuous Delivery vs Deployment
- Feature Flags / Feature Toggles
- Regular expressions (regex)
- Compiled vs interpreted languages
- Dynamic vs static & weak vs strong language typing
- Lazy loading
- Profiling
- Race condition
- Deadlock
- Mutual exclusion
In some cases, you may want an engineer to know about certain fields or areas already, such as front-end, back-end, architecture, infrastructure or security. In those cases, there are also cross-framework concepts and principles that can be used to drive conversations on technical knowledge that is specific to each one of those fields.
- API communication (different architecture standards, how data is transmitted...)
- DOM (definition, understanding, virtual DOM...)
- Browser events
- Responsive design (purpose, advantages, progressive enhancement...)
- Client-side rendering (CSR) vs server-side rendering (SSR)
- Pagination
- State management (associated problems, stateless approach...)
- MVC and derivatives
- WebSockets
- API design (different architecture standards, how data is transmitted...)
- Message brokers
- Relational databases (how they work, basic concepts...)
- Non-relational databases
- Database design
- ORM
- Batch processes / Cron jobs
- Session handling
- Error Handling, Auditing and Logging
- API
- Standards: REST / SOAP
- Security (e.g. blocking bots, controlling account take-over attacks, etc.)
- Resiliency on 3rd-party service failures (e.g. Circuit Breakers)
- Externalized Configuration
- Everything as code (i.e. Configuration as code, Infrastructure as code, Docs as code,...)
- Monolith vs Microservices
- Domain-Driven Design (DDD)
- Hexagonal Architecture
- Service Mesh
- Relevant internet protocols and their usage (i.e. HTTP, HTTPS, TCP, UDP, LDAP, SSH, SMTP,...)
- Data modeling
- Virtual machines vs Containers
- Processes vs threads
- Controller-agent / Primary-replica pattern
- Client-server pattern
- IAAS, PAAS, SASS
- Web servers
- Reverse proxies
- Load balancing
- Redundancy
- Latency
- Monitoring
- Observability
- Identity and Access Management (IAM)
- Authentication (JWT, SSO)
- Authorization (RBAC, ABAC)
- Public-key cryptosystems (e.g. RSA)
- Cryptographic protocols (TLS, SSL)
- Principle of least privilege
- DoS / DDoS
- SQL injection
- Man-in-the-middle attack
- XSS and CSRF
This work, by Romén Rodríguez-Gil, is released under the terms specified in this license file (MIT License).