Why we decided to take the lead on hiring new developers
Last year when the pandemic broke out, everyone assumed companies would downsize or close, that there would be an abundance of unemployed developers, and that recruiting would be easy.
Boy, were we wrong.
With an all-time high in funding rounds and new Israeli unicorns, the competition for top talent has never been greater. How much greater? Some estimate developers in Israel get up to eight job offers a day(!), which means you gotta move fast. Really fast.
So, how do companies quickly evaluate someone’s ability to code before they decide to hire them?
They use technical interviews.
Technical interviews have many different formats. Some popular ones are code reviews, algorithmic questions, at-home programming challenges, and even “guestimations” like “how many weddings are held each day in Melbourne?”.
The problem with many of these tests is that interviewers and interviewees turn to Google or popular resources like Gayle Laakmann McDowell’s “CRACKING the CODING INTERVIEW” for both the questions and the answers, turning technical interviews into nothing more than a pre-rehearsed formality.
Where do great developers come from?
Talented developers come from many educational backgrounds. Most have computer science degrees, some are incredibly curious autodidacts, and others went to coding bootcamps.
Coding bootcamps promise to turn students into developers in a very short time, and one thing they teach their students very well is how to build a strong online presence, the kind that leads recruiters to view them as more experienced than they actually are.
Since great developers really can come from anywhere, you don’t want to rule someone out just for being a bootcamp graduate. This leaves it to the technical interview to discern between the developers who look great and the ones who are great.
What makes a truly great developer?
Being a great developer is about so much more than writing code.
We write code to serve a specific need or solve a problem. Developers tend to find solutions that match their skillset and enforce the problem at hand to fit into the framework or language they’re familiar with. However, great developers know that no technology is perfect and that there are always tradeoffs. Any technology or programming language has its advantages and disadvantages, which is why excellent developers must first and foremost understand the need they’re trying to answer and the logic behind different choices. The more you know, the more options you have to deal with a problem.
While developers must be able to break down a problem and understand how systems work to see the bigger picture, they also have to be exceptionally good at communicating these things to other people. A lone coder might be an excellent problem-solver, but they can’t work within a team without good communication skills.
What developers are we looking for?
We work in diverse, multidisciplinary teams that approach problems from a broader perspective. In our eyes, it doesn’t make sense to take talented individuals and box them in job descriptions. Gifted developers can have any engineering background, like real-time, frontend, backend, or data. Being great is not about writing in a particular programming language. If you’ve got a theoretical understanding and strong analytical and problem-solving skills, picking up a new language will not pose a hurdle. Besides, tech stacks change and evolve all the time, so continuous learning is crucial for developers anyway. We’re looking for talented people regardless of their specific technological history. We’ll always find them incredible things to do.
Our technical interviews
Because we use such a different organizational model for the eko dev team, our technical interviews also tend to take a different course.
In one format, we ask developers to walk us through a project they’ve already completed at work, school, or on their own, and before we even get to the code — we want to know what goals they were trying to accomplish and for what purpose.
We ask our candidates why they made technical choices and how they handled problems, not because we’re trying to judge their decisions but rather to understand their way of thought. We also ask follow-up questions like “what would you change if X would be different?” or “how would you approach this project differently if you had to do it over again today?” Since the conversation is about something candidates have already accomplished — they feel comfortable and free to go as deep as they want into a topic they know.
In another type of technical interview, we ask candidates to solve a software problem outside their area of expertise. Then, we discuss it together to explore how they defined the problem, if they understood the need behind it, why they chose the technologies they did, how they planned their architecture, design, and APIs, and finally — we examine their coding skills.
These kinds of open discussions provide a pretty accurate simulation of what it’s like to work on a feature at eko while helping us identify great developers.
What we actually mean by “great developers”
Great developers understand the many layers of abstractions that make their software run and the deeper layers of other software (and hardware!) their code relies on to function. For example, a good frontend developer might be proficient at crafting CSS animations, but a great one will also understand the browser rendering process, how and why does the GPU come into play, and even how it all fits within the context of the OS and device the browser runs in.
The approach a developer takes to the practice of programming also talks a great deal about their proficiency. Other than addressing the task at hand, do they handle the less optimistic paths (errors and failures)? How do they test and using which testing methodology and why? What do they log, and how do they make sure to separate the wheat from the chaff? After all — it’s not all about writing code “that just works”. It’s about looking at the entire picture of programming in an organization: making that code solid and trustable, debuggable, maintainable, and readable to other humans (and themselves, in the future).
How does all of this help us move fast?
Well, since we are, in fact, developers ourselves, we can figure out who’ll make an excellent professional match to our team a lot quicker than “someone from HR”.
Plus, because we’re the ones doing the interviews, candidates get to meet the people they’ll be working with right from the very start. And thanks to our flat organizational structure, we don’t need approvals from five layers of management when we meet someone we like.
…
Want to see for yourself what an eko technical interview looks like? Send us your resume here!
