Why I Hire from Lighthouse Labs By: Josh Borts April 23, 2014 Updated November 20, 2020 Estimated reading time: 3 minutes. As co-owner of Lighthouse Labs and Functional Imperative, a digital innovation agency, I am in the unique position to understand the realities of hiring students from developer bootcamps like ours. Therefore, one of the questions I get asked most often is what we look for when hiring. To us, hiring a good developer comes down to culture and certain, critical characteristics that we value at FI. In the paragraphs below, I’ll take you through Functional Imperative’s decision to invest in talent emanating from bootcamps. Over the past year, Functional Imperative has grown from a small team of senior developers to a larger more diverse group, with different backgrounds, skills levels and interests. This growth, fueled by our investment in the bootcamp model, has had a drastic impact on our company’s culture and processes, mostly for the better. In fact, some of Functional Imperative’s best talent has come from bootcamps. Though I would deem the changes successful, it has not always been easy. One of the hardest problems we have faced has been the balance between speed, code quality and the freedom to learn; things that are often at odds in the fast paced consulting world, where deadlines are often tight and clients fickle. While my responsibility used to sit solely with the client, it has now become split between the short-term requirements of my projects and the longer-term development of my employees. A classic management problem; but one that has particular ramifications for a small company, where cash flow is always an important consideration. I have also remained cognizant that Functional Imperative is considered a top quality agency specifically because of the innovative thinking my team possesses, something that can easily be bogged down in too much process. So how have we balanced these competing interests? We: Introduced code reviews. When our team was small, it was easy to get away without (bad practice, I know). But with more junior developers onboard, this became a must have and allows me to control what gets released to the client. Promoted a senior dev to act as a roving problem solver / teacher / mentor / ass kicker. Basically a team lead, his responsibility is to make sure all projects are moving forward technically Instituted the “20-MINUTE RULE”. All devs have had it beaten into them that they (slash google) are to spend 20 minutes trying to solve their own problem. At that point, they must reach out to our roving problem solver Each Friday afternoon, each developer gives a short talk on something they learnt that week Once a month, we have “InnoFri”, a day for everyone to play with whatever technology they want. Followed by a group activity, dinner and drinks These changes have provided us a framework where our developers have the freedom to learn and innovate while at the same time providing levels of guarantees around code quality and deliverables. Not just any developer, however, will work well within our company. Some of Functional Imperative’s best assets, flexibility and individual responsibility, may not be right for those that seek a structured environment, with more, for lack of a better word, hand holding. This of course is not the only model. For many students, the best course of action is to find a position where they can grow slowly, with layers of resources set up for them to succeed. For those students, larger teams inside of bigger organizations may be the best bet. For teams like mine (read startups), however, I require self-starters who want to thrive in fast-paced environments. I give every person on my team a lot of responsibility and the expectations is that they will figure out a way to deliver, come hell or high water. In fact, it is not uncommon for a junior developer on my team to own an entire client project; from the decision of what technology, to the architecture, testing and deployment. We are of course there to guide them, but they are the ones who will be answering client calls at 3AM if something in production breaks. This is one of the advantages of hiring from Lighthouse Labs. Having taken the leap and decided to own the direction of their career by enrolling in a program like ours, I already know that these candidates have the thirst for knowledge, the motivation and the initiative to succeed in any workplace. With these traits in place, I know I am investing in a junior developer, but I am confident they will quickly gain the knowledge needed to make me look great! I have been so enamoured by the quality of individuals in these programs that it was a no-brainer to help found Lighthouse Labs and I couldn’t be happier so far with the results. While these soft skills are essential, the final skill I look for when hiring is easily the most important. To be a great developer, you need to be an amazing debugger. I can’t stress enough how important good debugging skills are. Often, the main difference between a junior and advanced developer is simply their comfort level with Chrome dev tools or Pry. Code does break, whether it’s your own or someone else’s, it’s really just a matter of when. Being able to quickly determine what parts of the code are responsible will save you hours upon hours of trouble. This is why when we started Lighthouse Labs, we made a concerted effort to put the focus on debugging. Throughout the course students spend time reading each other’s code and becoming familiar with the tools available to track down bugs. There is even an entire week spent fixing issues within open source projects. My motto, if you can fix it you can build it. -- Want to work at Functional Imperative but don’t know how to code? Apply to Lighthouse Labs and you will already be showing the initiative we look for. We can take it from there.