The responses I provided to an "anonymous" media outlet series of queries on October 8, 2019:
Media: Attributes to Look for in a Coder Beyond Coding Skills
Gfesser: Note: I use the term "developer" throughout my response, since "coder" brings certain connotations likely not intended by the questions, and "developer" is widely used (along with "programmer").
Media: When screening coder applicants, what is the most important skill to look for other than coding ability?
Media: Why is this non-coding skill particularly important?
Gfesser: I typically see questions around coding ability residing side by side with questions around developer use of particular programming languages. While skills in any given programming language are very important, it is also very important to be able to learn quickly because technology moves so fast. And with open source code having joined the mainstream in recent years, there exists a plethora of options with respect to the libraries and frameworks available in a given language, the understanding of which can be much more challenging than the language being used in itself. Because of all the framework options available in the community, many of which are competing for developer attention, developers should understand the benefits and drawbacks between options, and chose wisely with respect to those which they decide to spend their time learning (and depending on the firm, present to architects who should themselves also be hands-on developers). Side projects on which a given developer is working to do so can be very informative with respect to understanding their abilities. After all, they are spending their own time doing this work, so how they chose to spend their time demonstrates what they value.
Media: Do many of your current coders possess this skill?
Gfesser: I'm a consultant (working as principal architect with a consultancy) who has worked at many clients over the course of my career, and so the developers with whom I have worked have varied greatly. Generally speaking, most developers do not have these skills, and it becomes apparent after working in this industry a while that the work title of a given individual often does not reflect their abilities. Higher skilled individuals tend to work at consultancies and startups, but as I make this statement I also realize that it is also very much a generalization because this is not always true. As an architect who continues to be hands-on, which is important because I need to be able to build PoCs (proof of concepts), prototypes, and MVPs (minimum viable products), making wise decisions and being able to relate to the work when working alongside other developers, typically the easiest way to spot a developer not having this skill is seeing them make quick decisions, often by following the first advice or using the first framework they come across by performing web searches looking for guidance.
Media: What is the best way for a coder to acquire this skill?
Media: Is there anything else you would like to add?
Gfesser: Evaluating between developer candidates is an important topic. Firms which spend time understanding how to evaluate, not just by sorting through resumes based on chosen keywords of candidates or recruiters, will find their investments doing so paying off in the long run. And firms often need to be patient finding the right candidates. I've worked for firms which are very selective, extending offers to less than 10% of candidates. As with the selection process conducted by universities, however, the manner in which the candidate pool is winnowed is challenging, and just because it is possible to narrow down the candidate pool does not mean that the result is optimal. One philosophy that I have seen in the workplace is to use a "sink or swim" approach to developers who end up being hired. Essentially, throwing hired developers into the deep end to see what happens, abstaining from all guidance from those already on the ground for a given work effort. While there is definitely something to be said for seeing what a given developer can do with limited guidance, treating developers poorly (for example by criticizing without first talking to the developer in question) is bad practice.
See all of my responses to media queries here.