Some of you may have read in my last post, I started at CoderPad 3 weeks ago as a Developer Advocate. Since then, I've been connecting with former bosses, co-workers and other software engineers to gather thoughts and to better understand the realm of technical interviews. Most of the people I've been reaching out to in my network work at established technology companies in higher up roles. Think CTO's, Director of Engineering, Lead Engineers, VP's of Engineering and Senior Software Engineers.
I started reading back my notes on these calls and I've started to see a pattern in their technical interviewing process. Here are some key findings…
Side Note: Would you be interested in learning about the specific companies technical interviewing process OR do you want to highlight your companies technical interview process? If yes, shoot me a message email@example.com
I spoke with two former colleagues that now lead engineering teams at some companies you have definitely heard of, but aren't Google and Facebook. An interesting point that came up in my conversations with them is that they use their hiring process as a way to attract the big talent.
They both told me that they are highly involved in the recruiting process. Not so much vetting resumes and finding talent, but they were definitely leading the "Introductory First Calls". Not only was this a tactic to make the engineering talent feel special, but it also allowed them to figure out the motivations of the candidate and if it was worth even moving forward to the technical interview.
Almost every person I talked to in the past week told me they were doing take-home projects for their candidates, instead of live coding sessions. The main reason for them preferring Take-Home projects seemed to be the opportunity for candidates to work in a "real world" scenario and for the company to see "real world" output.
One specific Director of Engineering told me how they set up their Take-Home projects. They took a problem that the company had in the past, simplified it, and came up with an exercise that mimicked that problem. So not only are the candidates in a more relaxed environment, they are also working on problems the company may have faced in the past or are currently facing. It's a win-win for both sides in my opinion.
Another reason was the time saving that comes with the take home, and engineers not having to spend 30 minutes to 1 hour on a live coding interview.
Most engineering managers are looking for how you think, rather than specific language ins and outs. It was almost a consensus - that once you know one language, you can learn them all. They were more focused on the tangible outputs like how do they write actual code, and how are they solving a problem.
Specifically they were looking for maintainable code, are they breaking down code into individual functions, are they using object orientated design, is the code readable for others etc.
Most technical interviews are the same for Juniors & Seniors - but managers are looking for different things
Like the subtitle reads above, companies are looking for different traits out of junior versus a more senior engineer.
In a junior engineer, it seemed they were looking more in the direction of soft skills, team compatibility and the basic knowledge of the languages and frameworks that the companies use.
In senior engineers, they are looking for high quality, good grasp of software design knowledge and high end communication that will eventually allow them to lead projects.
Every company is different and finds success using different methods (live coding vs. take homes for example). But I thought this would be good to share to show potential candidates what to look out for in the world of technical interviews.
Technical interviewing is difficult. Both for companies and for candidates. At CoderPad, we are always trying to bridge that gap and make things easier for both sides. If you have any questions about CoderPad, or if you are a company looking to set up technical interviews, please reach out - happy to talk!