| |
Sign In
There are many styles of interviewing software developers. The best processes are those that allow you to see if the candidate is a good fit for your organization and for the candidate to see if your company is a good fit for them. Shortcomings on either side can lead to costly mistakes and wasted time on both sides.
When I worked on the GSM switch project at Motorola in the late 80s we spent considerable time recruiting software engineers. Our process was typically:
one engineer would escort candidate from HR to the office area giving a short tour on the way. manager would briefly talk with them and explain the project at a high level and the day’s schedule. depending on candidate’s level and on our availability 2-4 engineers would individually give technical interviews. one interview would include lunch out in a local restaurant. the manager would meet with them again for any follow-up questions and to inquire which part of the system they were interested in before they were escorted back to HR.
My interview technique was to first have them explain their previous projects and I asked questions where I needed clarification. Then I would draw a high level architecture diagram of my subsystem and explain how it fit into the product and its purpose. I would let them lead at this point; I was looking for them to show an interest and curiosity about the system by asking questions and an aptitude for talking about a system from both a high level and a detailed level. I was looking for inquisitive thinkers who seemed eager to learn and work on a team.
The candidates did not usually have nor did we expect them to have any telephony experience or knowledge of cellular (analog or digital) phone networks. Most did not know C or assembler nor had heard about the object oriented concepts we were designing with. These were important, but at the time software engineering was all about design and process and not at all about the underlying technology. In fact we did not know ourselves at the beginning if we would be using C++ or C. Our previous phone switches were coded with assembler. We ended up using C as the C++ cross-compilers were not proven for our processors at the time and would have been an unnecessary risk.
This process consumed much time but we ended up with an outstanding group of software engineers.
Two podcasts I’ve listened to this past week have had content on more recent interview practices. First was Episode 16: Interviewing Software Developers from Herding Code. From the show notes:
This week Kevin leads a discussion on interviewing software developers: