What makes an applicant for a software engineering job an attractive candidate for hire? This is a perennial question that is likely to be uppermost in the minds of both employers and their prospective employees. Software engineering is highly competitive job market where, on the one hand, industry expectations run high, and on the other hand we have hundreds of “education providers” professing to deliver a sound education in computer science. It can get confusing to aspiring software development professionals as to what exactly is required of them to secure that first salaried position… and it can be frustrating to employers when newly hired staff are not performing up to modest expectations simply because they have not approached the trade with the right mindset.
Let us try to outline the measurable skills of an “ideal” software engineering candidate who presents herself for interview. First and foremost, she’d be very strong in her software engineering concepts. An in-depth knowledge of OOP concepts would be evident. She’d be thorough with the architecture of at least one development platform of choice, and be aware of how the various sub-systems and libraries of the platform work in cohesion. For example if we consider .NET as the development framework, a savvy software engineer would be aware of the high-level workings of the CLR and common language infrastructure. The candidate would have the essential background technical knowledge to develop Web applications such as an understanding of the lifecycle of a Web Request. She’d be familiar with Lifecycle Management concepts like Continuous Integration, Unit Test Driven Development and Configuration Management.
A “good” software engineering candidate would know about industry-recognized Design Patterns, and ideally have adopted a few patterns into their experimental project code. Conceptual knowledge of widely used Design Patterns like Singleton, Abstract Factory, Factory Method, Facade, Proxy etc is essential knowhow, since these concepts tune the programmer’s mindset to leveraging best of breed solutions to standard design problems, without reinventing the wheel (and reinventing it rather poorly perhaps). Whilst generally having a modern, agile, paperless, code-design based approach to programming, a budding developer must have enough sense to initially whiteboard any non-trivial implementation, and seek peer review from her teammates. At an interview, this skill could be displayed through one’s ability to represent a simple design problem as a UML class diagram.
In this day and age of vastly scalable non-relational databases and cloud computing, one might be tempted to frown upon knowledge of plain old-fashioned relational database concepts like ER diagramming, SQL, Normalization and Optimization. However, these concepts are still very much in use in most enterprise applications, and must be studied and understood. Woe to the interview candidate who cannot answer a question like “Why would one sometimes need to de-normalize a database? Can you think of an example?” or “What is the use of an Index?” .
Some conceptual knowledge of how people work together to deliver a project to a client is mandatory for beginners. Familiarity with a lightweight team-engagement paradigm like Scrum would be ideal to have.
Successfully facing a test for conceptual knowledge is of course not the only indicator of potential success at an interview. But the concept-savvy candidate is the quintessential software engineer. The era of concept-blind “code monkeys” working principally through trial and error (“copy-paste coding”) is to be frowned upon by any respectable software engineer or employer. Of course, we are speaking of engineering graduates who have had ample time and guidance to perfect their attitude to programming. The story might be different if one is a job applicant fresh out of high-school. In a sense, the evaluation that such trainees would have to face would be harsh, because employers would have to simply rely on the rather controversial concept of “a high IQ” . It has to be admitted that a good developer will almost certainly have strong innate logical reasoning capacity, usually expressed as a gift for providing algorithmic solutions to real-world problems. This is the sort of test that one who has had no formal training in computer science would face at an interview (e.g. “tell us the steps to sort a randomized list of numbers from 1 to 100” etc).
Having said this, possessing a high IQ, being knowledgeable about engineering concepts and being a great team-worker still does’t complete the picture of a “good” software engineer. At the heart of a successful developer lies an appreciation of the end user’s objectives for the system under development. No matter how “smart” a software developer is at codifying algorithms or grasping new frameworks, she only succeeds when she has met the end user’s expectations. So “well rounded” developers are also great end users – ” those who tryout new apps as hobby. Unless you use software freely in your own life, its unlikely you know what is a user-friendly, defect-free app. Along with an appreciation for usability comes an appreciation for testing one’s code.
So from the perspective of a job applicant, what does one do as prep for that first interview? Ask oneself the question, am I aware of the basic concepts? OOP-check. Design Patterns-check. Web Request Lifecycle-check. Logical reasoning and writing of algorithms-check. Configuration Management concepts-check. Relational Database design-check. And so the list goes on. Freshers preparing for an interview should master the ability to clearly demonstrate one’s knowledge of these concepts, by giving both textbook metaphors of their use and purpose, as well as recounting how one has used or encountered these concepts in past projects (at University or elsewhere, perhaps within common development frameworks itself).
Let us now look at the other side of the coin – how does a potential employer spot someone who has great potential as a software developer? At the heart of making a good hire lies the ability to gauge if a candidate can reason from first principle, literally thinking on her feet. After making a candidate comfortable, its an excellent idea to present a simple real-world problem on the board, and see how far she can get with providing a solution in design / pseudo-code. Give the candidate ample time, support and encouragement. Once the initial jitters are at bay, a good candidate will always make a genuine attempt to answer the problem. A weak candidate will always stall early with algorithms or design problems, because of a lack of critical reasoning capacity – an essential trait for becoming a good software engineer.
It might sound like a harsh reality, but software engineering is not for everyone, just like any other “trade” like art or music or management is not for everyone. However everyone must be given the opportunity to try their luck at this fascinating trade, and it is likely that those who succeed will be those who approach solving real-world problems logically from first principle, with great diligence. The sooner aspiring software engineers learn this, the better their career prospects. This is, and must be, a transparent truth between the industry and the thousands of prospective new entrants.