Reading Specs |
Takes specs at face value, writes code that solves the immediate problem. Code may overlook edge cases |
Asks questions to figure out a solution given the problem, addresses the issue at hand with a reasonable solution that considers some possible edge cases. Likely overlooks some potential solutions that are less closely tied to specific use cases |
Asks questions to asses what the best solution would be, produces code that not only addresses the issue at hand and handles all edge cases, but improves the flow overall. |
Code Style |
Code contains long functions, confusing names, lacks clean structure, has unexpected side effects, hasn't been refactored. |
Contains reasonably sized functions that can be reused elsewhere in code, code structure is clear and sensible, includes some comments about the code, has awareness of code testability, may try to use language features and 3rd-party tools. |
Shows high awareness of testability, functions are small and do one thing, shows clear understanding of scope of each issue, leaves functions and surrounding code in better state than it was before, shows strong understanding of features of language and excellent use of 3rd-party tools |
Scoping tasks |
Has trouble breaking problems down into component parts; and identifying what is outside the scope of the problem. |
Breaks problems down into some smaller sections, but sections may not be granular, or sections may be not ultimately the most useful. Has thoughts about what is within/without scope for a project, but doesn't clearly express this. |
Understands the granular tasks necessary to create the project whole and how those pieces fit together. Understands and clearly expresses scope of the project, and handles managing expectations accordingly. |
Technical Knowledge |
May not ask many questions for fear of sounding ignorant. May ask questions that solve their immediate problem, but don't address larger comprehension gaps. |
Asks questions regularly, though often the complexities/details will not stick, and will need to be reviewed again later |
Asks smart questions often, can connect concepts between an explanation they're receiving now with a similar application elsewhere in the code. |
Source Control |
Has basic understanding of source control (i.e. git) and can execute basic tasks: Pull, commit, push, etc. Likely needs help when anything more advanced is necessary |
Has an intermediate understanding of source control; for example, can create/move to a branch and cherry-pick, but has a more mechanical process than thorough understanding of these tasks. |
Has good command of the source control tools for the company, and good understanding of the infrastructure behind it. |
Testing |
Occasionally runs tests, seldom writes them without prompting. Can write a test to confirm that, with standard use-case, the expected output results. Likely overlooks writing tests for edge cases |
Runs tests most of the time when finishing up a project, writes basic tests to confirm expected behavior and spends some time thinking of edge cases. Tests are likely verbose and may test for multiple things, and likely don't give the most useful information when they fail. |
Consistently runs tests while developing, and writes appropriate tests concurrently. Tests are plentiful, small, and test only one thing at a time, and give useful feedback when they fail. Writes tests for expected use cases and thoroughly addresses possible edge cases. |
IDE/Tool Knowledge |
Uses most basic features of the tool. Will need to look most things up in documentation. Uses GUI whenever possible. |
Uses some of the shortcuts of their tools, but still needs to look things up a lot. Will not be terribly efficient, but can get around to what's needed when necessary. |
Can efficiently navigate tools through shortcuts, seldom needs mouse, customizes tools for their needs confidently. |
Frameworks |
Hasn't used the frameworks for the company before, but will walk through tutorials for them. Will understand the most basic application shown in the tutorial, but not how to integrate that with a more complex system. |
Understands, high-level, what the framework is good for, what the basic component parts are. WOuld need guidance in putting them together from scratch, but is comfortable navigating/revising existing systems. Asks questions about implementation. |
Has a good understanding of the framework, and can put component parts together themselves with minimal assistance. Asks good questions about value of the framework vs other tools they've explored. |
Codebase Knowledge |
Gets lost navigating code and identifying code causing a problem. |
Has tools to identify what code needs to be revised/where code needs to be written, can navigate the system and understand the basic code layout and how the different parts of the code base work together. |
Understands, before looking at the code, what changes are likely necessary for the problem at hand, and where to start. Is able to dive in to a project and quickly understand the related parts. |