Essential Competencies of a Fullstack Software Developer Matrix

Source

Post

Technologies around JS

	Coder	Programmer	Engineer	Guru
HTML	Owns the modern layout and most common APIs	In the course of the reflow / repaint cycle. Uses HTML5 tags for the most semantic layout. Pre-use HTML5 APIs including for graceful degradation / progressive enhancement. Owns microformats / micro-labeled	Following new trends in the world of HTML ( example – web components ). Applies them or does not apply on the project depending on the business value of the solutions	The gurus of the ( layout will understand if you have met such ). He knows the features of the functioning of HTML5 APIs in different browsers under different conditions.
Css	Standard CSS3	Knows non-standard ( non-obvious ) CSS shirts	Monitors the development of CSS and can-i-use. It is meticulously devoting time to supporting CSS in supported projects (long live tautology!). Has an opinion about CSS-in-JS and why it (not) should be used in specific projects	thoroughly knows the nuances of rendering entities in different browsers. Writes the perfect CSS, which is understandable to the team and covers all the needs of the project
JavaScript	Owns the main language constructions, basic concepts (a la closing, etc.)	He knows how to write clear and flexible code. Avoid the use of “hacks” and “specialties” of the language without necessity.	Understands the features of JavaScript on different engines and on different devices. Monitors TC39 and the development of the language, has his opinion on future improvements and their feasibility	He takes an active part in the development of one of the main JavaScript engines
Typization	No idea about typing code	Able to write code with types ( typing system is not important). Understands the points of the code where runtime-typization is needed	Thinks of types as an effective tool for describing a domain area. It puts the types at the core of the design process, even if it does not use static typing systems	It uses all the expressive capabilities of the typing system, knows its weaknesses, uses code generation to bypass poorly digitized places, redesigns the code so that the maximum amount of code is covered by the minimum capabilities of the typing system. Types form an integral part of the system contract
System Programming Basics	Not interested in system programming	Differs the compiler from the linker, and the interpreter from the compiler. Able to find out the cause of the compilation error of the next node_modules and eliminate it	Able code can be read (including those generated v8)	Able to write (or wrote) your own kernel modules or low-level utilities for solving complex problems
Framvorky	Able to solve typical problems within the framework of a ‘favorite’ framework. He understands well where and how to write	It is able to implement complex solutions that go beyond typical tasks and choose the components of the stack depending on the task. It makes maximum use of the features provided by frameworkers so as not to reinvent the bike. Realizes the weaknesses of the framework and writes code to minimize their negative impact.	Understands the internal organization of the framework. Able to write code that maximally uses the features of internal implementation. He knows the poorly documented or unobvious possibilities of the framework, is able to predict errors by looking at the code before starting 🙂	It is able to expand the framework at the ‘core’ level for non-standard tasks (for example, changing the reconciliation algorithm in React to optimize the output of ‘video blocks’ in the ‘video cloud’).
Enemy technology	Considers the selected stack “the best”. Negatively refers to “prites” in another language	Able to objectively state the strengths of “enemy technologies”	Actively borrows effective solutions from wherever possible	He has commercial experience in every technology that is aggressively criticized. He regularly experiments with “enemy” technologies in order to be “in the subject” and to realize his work as efficiently as possible

Computer science and related things

	Coder	Programmer	Engineer	Guru
Algorithms and data structures	He knows about the existence of recursion, bubble sorting and quick sorting.	He knows about the existence of O-big, knows the complexity estimates of most ‘classical’ algorithms for ‘classic’ data structures (list, array, etc. down to AWL trees), is able to implement these algorithms, having a description from the sheet	Able to prove complexity estimates by time and memory for unfamiliar algorithms. It is able to optimally select the data structure to solve the problem. He knows how to optimize algorithms within the specified conditions (including the search for approximate solutions)	Understands weighted matroids and other horrors for a rigorous mathematical assessment of not only maximum and average time-memory estimates, but also for estimating metrics ‘95% should fit in X ms’
Design patterns	Owns basic design patterns: Observer, Singleton, Event bus, Factory, etc.	Consciously or unconsciously owns most of the current design patterns from the ‘Band of Four’	It is able to select implicit design templates as part of a review of an existing code or crop code, make them explicit and convey the light of design patterns to the code author	Sees ‘Matrix’ – almost any task is able to effectively decompose to subtasks within the framework of well-known design patterns
OOP	Knows the ‘three whales’ of the OOP and is able to see them in the code	Knows SOLID principles and practices them	Respects Domain Driven Design and designs systems for the real world. He knows the weaknesses of the PLO and goes around them	Combines the OOP and functional style so that it leads to the most understandable and supported code
Functional programming	He knows what ‘clean functions’ are’. Used map / filter / reduce. Secretly does not respect those who bypass the arrays for	Understands Observable’s and other flows and uses them effectively	He knows what ‘monades’ are’. Can write in the functional style of places that are effectively expressed in the functional style	Combines the OOP and functional style so that it leads to the most understandable and supported code
Architecture	Thoughts on the architecture of the application at the current file / module level	Plans the architecture of the application based on best practices accepted in programming. Able to lay the competent architecture of the project	It develops the architecture of the application based on business needs, available resources, scaling potential and (for what they forget) the technical skills, capabilities and expertise of the team that will develop the project	He has practical experience in solving problems in certain architectures. Designs as simple as possible, but not easier than business needs.

IT skills

	It is able to expand existing tools (own webpack and ball-plugins, for example). Develops tools for solving problems within the existing project and for business needs	Programmer	Engineer	Guru
Continuous integration	Is a ‘consumer’ of Continuous Integration. Able to write code that not only ‘is everything working for me’, but also passes tests on CI	Understands the principles of CI, able to understand the problems with the CI bill	Able to raise complex CI from scratch on an existing project. He knows the weaknesses of CI processes and how to get around them.	Develops new tools for continuous integration aimed at solving specific pain of the company and project
Deployment	Able to wrap an existing project in a Docker container and run it	Owns the principles of building 12-factor applications. Able to implement a structure of several containers (docker-compose) and effectively support several working environments	Owns configuration management systems at a minimum (Chef, Ansible). Understands and has management experience with Kubernetes or similar systems, is able to solve the problems of zero-time deployment and write code taking into account such needs	Able to perform all DevOps functions, including deploying, supporting, and scaling complex clusters
Version control	Knows standard git flow	Skills to use git to maximize the expressiveness of history: interactive rebase, partial commits, etc.	Owns advanced features: git rerere, worktree, etc. Applies them in everyday activities for the benefit of the project	Understands how storage of objects in git is organized, including git-lfs. Able to restore an almost hopelessly damaged tree, sometimes with self-painted scripts
OS	He knows the OS at the level of a confident user. Able to reinstall its working system and solve typical problems in it	He understands how the process of loading the OS, initializing the services is arranged. He understands the principles of loading system libraries into memory, is able to make changes to the working system and, in which case, restore the system after failures without reinstalling.	Understands the architecture of the ( OS for example for linux: understands how systemd works at all levels ). Uses the capabilities of the OS to implement tasks that go beyond the core functionality of the ( application, for example, environmental insulating, data transfer speed control, etc. )	Owns a deep understanding of the OS. He understands the features of the kernel and specific system calls on a particular iron. Able to deeply debug problems, up to the use of tools for profiling system calls in the core and debugging the kernel itself
Network protocols	Able to tell ‘What happens when you type www.google.com’ in a browser’. Understands how TCP / IP, UDP, WebSockets work, but nothing more	Understands the entire OSI model. Skills to use tools (wireshark), is capable (for example) of intercepting and debugging an encrypted HTTPS connection	He knows the weaknesses of existing protocols and encountered them. It understands the nature of delays in data transfer at all levels (from downloading data to a network map to the features of package routing delays). Able, for example, to write your parser protocol for wireshark or use other, more perverted methods of debugging	Understands the specifics of package processing at all levels, including hardware. Is able to optimize the configuration of the + OS environment + product to achieve optimal network stack performance at all three levels
Databases	Distinguishes MySQL from MongoDB. Able to write a request with jaws or nested selects. He knows what 3 normal forms of database are not only during an interview	Owns a request profiler. It understands when it is worth using relational, when document-oriented databases. He knows when to retreat from normal forms	He has experience with exotic databases – exotic configurations or exotic engines. At least once he stumbled into the limitations of the engine and heroically raked them. Able to write effective queries and quickly identify ineffective ones. Able to indicate the most problematic places in future scaling	Has practical experience in all ‘direction’ databases. He has practical experience of horizontal and vertical scaling, data recovery, knows the specifics of storage engines, features of the work of query profilers, etc.
Tools	Knows and uses the most popular tools (webpack, label, etc.). Able to make minor configuration changes	It is able to fully configure related tools (example – webpack config for dev + prod + ssr + hmr). He knows about alternative tools. Able to select a tool for a specific task	It is able to expand existing tools (own webpack and balel-nlagins, for example). Develops tools for solving problems within the existing project and for business needs	It develops tools that are used not only in the internal processes of the team, but also significantly – beyond its borders.
Platform	Engaged in the development of application only	Understands which ‘platform’ the application is running (starting from nginx / lighttpd front for node.js application and ending with using Cloudflare for the front). Knows about the features of the platform	Able to analyze the existing platform, make suggestions for its improvement and implement these improvements	Deep immersed in the nuances of a particular platform. Promises improvements to it (both aimed at a specific project and in a public domain)

Fullstack Developer Tattoos

	Coder	Programmer	Engineer	Guru
Logging	Writes logs using console.log or file	He understands why centralized logic tools are needed. He writes systems taking into account the possibility of a dynamic change in the level of logs in order to study the problem of ‘live’ in the production.	Refers to logic as a fundamental tool for retrospective analysis. Accurately affixes logic levels, clearly structures logs, marks logs so that it is possible to trace the history of, say, a specific query through a series of microservices	He writes tools for isolating patterns from logs (sometimes using machine learning and other fashionable words). Builds on top of ‘raw’ logs higher-level monitoring and early warning systems
Caching	Do not think about caching. If necessary, uses naive cache in memory / redis	He understands that a joke about two problems in programming is not a joke at all. Thinking about strategies for disabled cache, understands the principles of eventual consistency	Able to implement a caching strategy in a project from scratch. It is able to implement caching in complex scalable systems (including geographically scaled, including fault-tolerant). He knows the features of the functioning of those caching technologies that are used in the production of a particular project.	He understands the cache of all levels (starting from L1 and ending with external cache in the services). Skills to identify problems associated with caching and optimize the structure to achieve maximum productivity
Failover	Do not think about fault tolerance of applications	Uses pm2 and / or docker or something else to implement ‘reference stability’. He knows about transactions and that all operations with money must be performed in them.	He understands the failures in which elements of the system lead to maximum risks for the business and develops a fault tolerance strategy based on this understanding.	In the course of modern fault tolerance trends. He knows the existing scenarios of failure of the systems used (example of MongoDB) in real projects and owns strategies to protect against such failures. Takes fault tolerance as a property of the entire system, not a specific software product
Scaling	No idea about scaling applications	He knows what horizontal scaling is. Able to write code, taking into account such scenarios	In the course of vertical and horizontal scaling. Has practical experience in building complex scalable systems.	It is able to implement scaling into an existing complex project (starting from changes in code and ending with DevOps tasks, while it is not necessary to carry out everything independently). Understands the limitations of scaling, the risks involved and the metrics that need to be tracked.
Productivity	He knows exactly what is faster – for or .forEach. Writes code based on this (and similar) knowledge	Understands Knut’s first rule. It is able to refuse microoptimizations towards the readability of the code, however, it is conceived about performance in the context of functions and modules	It makes decisions about optimizing performance only based on code profiling. It is able to assess the benefits of optimization before its implementation, and refuse in case of a non-optimal ratio of ‘benefit – costs’	It is able to identify performance problems before they get into production and become really problems. Owns advanced tools for analyzing productivity, and in the case of complex scenarios (some of the clients are slowing down and it is not clear why) – able to put forward theories and develop tools to test these theories
SSR	Did not implement SSR	Able to implement SSR on standard platforms, understands the nuances of programming such systems	Able to implement SSR from scratch to achieve optimal performance. Understands technology weaknesses	Able to solve near-SSR problems with non-standard approaches specific and applicable only for a particular project
Authentication / Authorization	Able to implement standard authorization login password-reduction-registration	Understands how OAuth2 and JWT work. Able to implement them safely	Owns the nuances of 2FA and existing attacks on them. Able to build complex role systems	Fully owns the theme of AAA ( Authorization, Authentication, Accounting ). Able to find potential security threats, data leakage problems, etc.
Information Security	Not thinking about information security	Familiar with top10 OWASP and presents how to defend against them	Knows about exotic attack vectors, tracks relevant 0-day vulnerabilities. Understands sections of the system with increased risk ( for example DDOS )	Writes tools for conducting attacks and identifying problem areas (for example, for Metasploit)
UX / DX	Not interested in UX / DX issues	Interested in UX, heard something about DX, but never did it	Collects metrics to improve UX. Actively collects feedback on the use of module-libraries-components of DX improvement modules	Has his vision of UX / DX. It is able to contrast its opinion with the opinion of the majority, if this contributes to the solution of goals

Soft skills

	Coder	Programmer	Engineer	Guru
Self-reliance	Able to provide a report on a task when asked	Proactively warns of potential problems, requests help and so on	He is able to independently set himself tasks for a long time, only by coordinating vision with ‘architectors’ and ‘product owners’	Has a clear understanding of the priorities of tasks in terms of development. He listens to priorities from the point of view of business, is able to provide ‘heroic’ efforts (deliveries in a limited time) not by overpower of the team, but by jointly simplifying tasks, etc.
Teamwork	Takes the team as a ‘tool’ for advice, feedback, training materials and so on	Actively shares with the team the knowledge and important ‘gotcha’ in the process of working on the project. Takes the team as a source of resources for continuous improvement	Able to fulfill (temporarily or on an ongoing basis) the role of leader in a team. Owns the concepts of emotional intelligence and takes it into account to unite the team	Takes command as a whole. It makes efforts to achieve a synergistic effect. Knows the strengths and weaknesses of each team member.
Mentoring	Not interested in mentoring issues	Able to answer questions about the project / technology. Able to share his knowledge, in the format ‘here you need to do wrong’	Able to effectively train a small group of employees	Able to convey knowledge to an indefinite wide range of people. Owns the skills of psychology-pedagogy-group dynamics for the most effective mentoring
Interviewing Skill	Interview perceives as a ‘almost exam’	He is able to discuss existing projects and his role in them at an interview. Able to critically evaluate previous experience	It perceives questions at interviews not as tasks that have the only right solution. In solving complex issues, it is proactive, not afraid to recognize ‘I don’t know’, but at the same time reasoning “Let’s think together”’	Interviews do not pass, and if they pass, they take the form of conversations for life or retrospectives of their activities
Out-of-the-box thinking	Thinking ‘intuitive’ based on your own experience and freshly read materials	Familiar with typical approaches and uses them. Able to find an alternative solution in case of serious problems	It is able to make decisions that at first glance contradict generally accepted approaches, however, allowing to effectively solve the task within the framework of current restrictions	Formalizes the principles of its solutions and sets them out ( publicly, inside the team – it doesn’t matter ). Promotes the transition of new ‘unique’ solutions to the category of well-known and generally accepted
English	Able to read technical documentation	Correct written English and tolerable conversational	Free conversational English ( technical contexts )	Free conversational English
Communications	Rarely initiates communications. Most communications are either related to solving ‘excellent’ problems, or within the framework of the current regulations ( shandapas, retrospectives, etc. )	It distinguishes communications as problems arise in current tasks. It is able to oppose other developers, including higher ones, if I am confident in my arguments. Monitors communication results in the context of specific actions	It uses an engineering approach in communication – communications are used as an effective tool for achieving goals. In work processes, there are completely no communications that do not contribute to the achievement of specific goals.	He possesses the concepts of emotional intelligence, the basic principles of NLP and everything that can help in building communication with ‘complex’ people. Communication is built on the basis of not only business goals, but also the psychological characteristics of the other side in communication
Vision ( vision )	He is interested only in the tasks set. Does what is ordered	He is interested in the tasks of the team, asks questions “why is it necessary from the point of view of business”, is able to offer alternative solutions to the problem if the current setting of the problem leads to significant difficulties or risks	He is interested in the business specificity of projects and their development directions. Based on personal experience, it is able to predict tasks, team requests and needs	It is able to formalize vision in process documents so that a priori knowledge becomes formalized. He understands the problems of business and does everything possible to ensure that the development of ( as service personnel ) is as consistent as possible with business needs
Reading skills of someone else’s code	Reading someone else’s code is associated with shouting ‘Who writes like that?’, ‘Why so?’, ‘what the $ # $ R@!’	Able to accept the ‘point of view’ of another programmer and, if necessary, ask questions about problem places	Evaluates someone else’s code exclusively purely in terms of criteria, important for the project in the current context (for example, as part of an urgent release, it is permissible to freeze the code written not gracefully from the point of view of architecture and having problems with productivity). Not trying to impose their approaches on everyone	It perceives someone else’s code primarily as an opportunity to study the approaches of other people. Able to critically perceive your own code and ‘bend down’ to team decisions (given team level)

General IT Competencies

	Coder	Programmer	Engineer	Guru
Debugging	Able to debug code using console.log and debugger	Uses all the features provided by the environment (conditional breakpoints, xhr breakpoints and so on)	It is able to efficiently and quickly debug complex interactions ( asynchronous operations, the interaction between processes and so on ). For Node.JS, it can debug native modules	Able to effectively debug the core of the system ( JavaScript )
Refactoring	A spontaneous approach to code improvements based on personal sensations	Refactoring is based on “generally accepted” best practices and is carried out as necessary.	Evaluates refactoring as a business activity, makes decisions on refactoring based primarily on the potential benefit of the project in the context of current business goals	The refactoring practically does not distinguish in a separate activity, however, the refactoring process itself occurs continuously – on the one hand there are many changes, on the other hand they arise in the system gradually, so the team does not lose the ‘nit’ happening in the system
Testing	Able to write unit tests to your code	Skillful (although not necessarily practicing) TDD. Unit tests are written as “honest” as possible, understands where and when higher-level tests are needed	It is able not only to write effective tests of all levels, but also to develop and maintain all the necessary infrastructure for testing (starting from downloading a fistur ending with managing animations in a browser)	It is able to identify non-obvious places of the project not covered by tests. It is able to optimize the testing infrastructure within the framework of business goals (speed of execution, etc.). Able to quickly evaluate test plans, including manual testing. Owns the problems of testing productivity, safety and so on
Business analysis	Requires a verified TK. Negatively refers to edits arising in the process of work. Considers a valid ‘presumption of innocence’ – everything that is not specified in TK can be done at the discretion of the developer	It is able to detect insufficiently clearly formalized aspects of the terms of reference before the start of development.	It is able to identify places in which the ratio of “efforts – obtained business value” is not in favor of business value and to develop optimal solutions together with Product Owner	Able to complete a full cycle of business analysis, including adequate management of requirements
Error handling	Don’t think about handling mistakes, believes in the best	Knows for potentially dangerous places in the code, uses try / catch and implements error processing	Understands the difference between error recovery and failing fast approaches. He understands that they do not contradict each other and use the storehouse of the desired parts of the system. Separates error flow / exception flow in the system	Monitors the boundaries of error propagation and the areas of responsibility of handlers. It is able to identify places where errors are incorrectly “eaten” and where continuation after an error carries risks to the system
Code Documentation	Writes comments in code	He writes a code that practically does not need comments. Uses jsdoc or similar approaches	Likes autogenated documentation (starting from swagger ending with type generation based on graphql endpoint)	Documented by high-level architectural solutions to facilitate the introduction of new people in the project
Code Extendability	Not thinking about code extensibility	Writes “maximum” extensible code, which sometimes leads to overdoses	Based on personal experience, he sees the optimal balance between system extensibility, development speed and readability of the code. Prevents (based on ownership of the subject area and past experience) potential areas of code development in the future and lays them in the existing code base	In addition to the optimal compromise on the extensibility and maintenance of the code, it monitors important metrics (for example, communication with other people’s libraries)