I’ve been interviewing for new positions in the private sector and I wanted to give my take on the changes I’ve noticed over the past 5 years in hiring for programmers. In my opionion, I think the bar is set quite high.
Here are a few quick notes on how Andrew Lee at Firebase interviews engineers.
Note: I did not apply or interview at Firebase, I’m simply using their process as an example after seeing similarities in my experiences.
Strong Communication Skills
- A well written introductory, email and resume along with good communication in their online content
- A passion for your company or your problem space
- A history of working on challenging projects with real deliverables
- A broad set of experiences
Strong Communications Skills
- This is a given, you have to be able to read and write well as a developer. Much of software development communication is done through concise writing on ticketing systems and documentation but what they’re looking for is content, blog posts. In Martin Fowler’s 1st edition of ‘Refactoring’, in the foreward he writes on how much of writing in software is done by new developers, teaching new developers. Its a case of the blind leading the blind. I didn’t start this blog until this year, mostly because I had nothing to say. I was too busy working on projects and learning from more senior developers. Thats close 7 years as professional and 4 years as computer science student. This is not to say, that I’m correct and Andrew or Martin is wrong. Its an underlying problem that we’re devaluing software development as a trade and as a craft by focusing on the wrong attributes that make great developers. I have hired and worked with seemingly average developers that written great code and improved drastically within the time we have worked together. Whether had good blog posts didn’t matter, it just shows you can write. This can be determined in initial communication between the employee and the company.
A history of working on challenging projects with real deliverables
- No toy projects here allowed, you have to have been paid to write software in the problem space or create an open-source project that has commnunity of users. Thats an exaggeration of course but This is a large barrier of entry for most developers. This type of thinking creates an unwanted silo for developers that want to move into different industries. For example, my background is finance so I like to work on Fintech projects. Does this mean I can’t write software for the healthtech industry? Do none of my skills transfer over? I’m not sure if having a background in finance makes me a better developer in that particular industry. At a base level, I understand floating point issues, regulatory bodies, industry practices and lingo but if I were to develop for healthtech, there would be some overlap on the technical side.
A broad set of experiences
- Now that you have spent all your time working in one division of tech, you would have to have experience wearing many hats. To me this reads two ways, not only do you have to have fullstack experience, you should be able to handle some developer operations and write tickets like a product manager or you can have a multitute of experience in different industries which is contradictory to the latter request.
After meeting the initial criteria, you would move to a standard procedure of:
- Phone Screen
- Technical Test
- Onsite Interview & Reference Checks
Phone screens are standard for the first interactions with the potential employer. This is crucial for what is known in the industry as ‘culture fits’. When I was first getting into the industry, I remember that these were mostly done in person but as distributed and teams become more common, a phone screen via skype or video chat is more approriate.
What Firebase and other companies look for are:
- excitiment about the company
- good verbal communication
- preparedness to leave current employer
- willing to relocate or commute to the office
- match culturally
Cultural fit within the tech industry sometimes get a bad rep. There have been several posts from Hacker News members where the guise of cultural fit have been used as a bias to unfairly exclude candidates from employment. Personally, I have never experienced it. When I’m hiring for my teams, I ask myself and the senior developers one trump question: “If you had to work on a Sunday or your day off, could you spend all day with this person?” Its always worked well for me and I don’t see why another team wouldn’t want to validate a candidate based off this type of social criteria.
The infamous technical test. This is the part that makes all the difference when interviewing with a company. In my experience, I’ve seen tests be too easy or too difficult and time consuming. Firebase’s test is great but the design of a 6-hour take home test is too long in my opinion. I would like it to be 2-3 hours at max, since you can do it in the comfort of your own home, development environment and access to the internet.
An overview of Firebase’s technical test:
The test, aptly named ‘goldmine’ involves optimizing the route of a miner through a maze to maximize the amount of gold collected. I think this is great test, since there would be no optimal solution. Every possible answer would have it tradeoffs in terms of Big O time and data structures used.
What I admire most about this process is the follow up and code review of that the Firebase team gives to the candidates. I’ve interviewed for organizations where there was simply a pass or fail answer given based on the results of my code. This seems unfair. Going through a code review with the candidate, giving them a chance to explain their choices and asking quetions would leave them with a feeling of sastisfaction, even if the employer were to pass. This also gives the company a chance to ask the developer what their process was going through the test. I’ve found that when some developers who have the right idea but made a sub-optimal choice in their code extrapolate on their process, you find that their are glimpses of brilliance.
In my opinion, this is the most important part of a technical test. The chance for both sides to run through a piece of code together so that both parties come away with something. Either the developer learns or the company gets to see what is the potential of that particular developer.
What I see often, is a technical test thats too shallow in the form LeetCode questions and the other half being too long filled with irrelevant CRUD operations. Finding the sum of N, when N is nested in multiple arrays and N is either a string or negative integer is too vague of a question to discover what both sides have to offer and frankly, I think its waste of time.
This part I enjoy the most. Its where I get to examine the office environment and meet the team. Here you can see if there are any potential ‘startup traps’ like fooseball and ping pong tables being used to liberally or constant interruptions in an open office floor plan. More importantly, you get interact with the other engineers on a personal level. Like my ‘Sunday Test’ I get to see for myself it these are people I can spend 40 hours a week with. Are they libeal with memes on slack? Are engineers browsing the web outside of personal or lunch hours? These are important to examine when you are onsite as this could be your potential home for the next couple of years.
All in all, I don’t think that hiring is broken as much as the Hacker News tells me it is. Software Engineers are big liability for the company and eat most of the payroll. An underperforming engineer is one of the most bittersweet things to witness but its also the most costly. The time spent fixing errors in code or not having code produced at all burns thousands of dollars in company budget and missed deliverable dates.
What I would like to see is shorter, more personal technical hiring with less rounds. In 2019, software engineering is extremely competitive. Not only are we expected to produce clean code and write good documentation, we have to blog, give talks, learn new technologies and contribute to open source. The list itself takes time away from actual time spent building personal projects or spending time with family and friends.