Performance Reviews

Format and frequency

When you work with us, sometimes you'll get a message with something like this:

Hi! I'm collecting feedback for @username. Please let me know what they're doing well and where they could do better. Examples are always helpful. Everything said will remain strictly confidential between us, I'll deliver the feedback in a paraphrased and impersonal manner. If it'd be more convenient for you to discuss this over a call, just let me know.

That's what a typical feedback request looks like. We collect and provide feedback for all our employees, and send this request to anyone who talks to that person about work-related issues. This happens twice a year, in February and August, and often (but not necessarily) coincides with a salary review.

Feedback for developers is collected and provided by the team leads; for the leads themselves and for management, by Denis Stebunov. If for any reason you'd like to get your feedback early, without waiting for the next scheduled date, just tell your lead or Denis about it.

Key Aspects

In our experience, most of the feedback we end up giving falls into the following categories:

1. Communication and teamwork. The ability to express your thoughts in an accurate and timely way is unfortunately not an innate quality of many engineers, but it is one of the most valuable skills in our work. So it needs to be developed;
2. A product approach to problem analysis. Do not ask "how" to do something, ask "why" and look for solutions yourself. It requires creativity, discussion, and the ability to work with uncertainty and make quality decisions independently;
3. Ability to build good and relevant abstractions, A.K.A. software architecture. The most significant parts are the quality of the code and the quality of the whole system;
4. Usability. This is not about beautiful pictures or a cute display. It's about any interface that the user interacts with, and about user convenience in the widest sense. An API is also an interface, as is the command line. Even function signatures are interfaces. And, of course, the UI is also an interface;
5. Testing code and pushing it to the production without any downtime or other trouble for users. This includes an understanding of manual testing, automated testing, data migration, and so on;
6. Speed is the multiplier by which all of the above is considered.