Skip to content

List of evergreen skills, based on software development best practices & cross-framework principles, that should serve as a fair assessment of skilled software engineers / developers

License

Notifications You must be signed in to change notification settings

romenrg/evergreen-skills-developers

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Evergreen Skills for Software Developers

Codeship Status for romenrg/evergreen-skills-developers

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.

Table of contents

Non-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.

Core Skills (aka "soft" skills)

Communication

Teamwork

  • Practice empathy
  • Keep low egos
  • Be an active listener
  • Be a good mentor
  • Share knowledge
  • Be constructive

Innovation & (self-)management skills

Development process

Problem solving skills

Mindset

  • Don't fear change
  • Dare to fail
  • Be a life-long learner
  • Critical Thinking (be rational, question decisions, "let the facts do the talking")

Technical skills

General technical knowledge

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.

Programming principles

Data structures

  • Basic structures (basic types, array, matrix, object...)
  • Caching / memoization
  • Hash codes, tokens, encodings (e.g. Base64)
  • Stack vs heap memory

Clean code

  • 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")

Source code management

  • 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
  • Feature branches (short-lived)
  • Trunk-based development
  • Dependency management (the importance of package managers, the risks of dependency hell,...)

Technical collaboration

DevOps 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

Other general technical knowledge

Language-theory knowledge
Optimization
Concurrency
  • Race condition
  • Deadlock
  • Mutual exclusion

Field-specific technical knowledge

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.

Front-end development

  • 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

Back-end development

  • 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

Architecture

Infrastructure

  • 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

Security

  • 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).