Thank you so much for the offer. I really enjoy working with you and I'm really happy you think so highly of my work. However, at this time, I'm just looking to focus on my business and remain a freelancer for the time being.
I've used that phrase three times in the past couple of months. It's the phrase I use when asked by a current or past client if I'm interested in continuing working with them full-time when my commitment to them is completed. I've had a lot of fun working on my own, despite its ups and downs (which I will write about at a later point), so I'm currently not looking to stay with any one company full-time.
I've felt really blessed that people have thought that I've worked well enough to extend an offer for work. But inevitably, in the back of my mind, I'm thinking, Where were you a few months ago, when I was looking for a full-time job?
Before I decided to jump head-first into freelancing full-time, I spent a lot of time talking with people at other tech companies and having interviews with them for a similar position I was leaving at my previous employer. There certainly was a lot of interest by other companies once I began looking. Skilled tech workers in the Bay Area are really lucky to have the opportunities that exist here.
However, weeks passed by. I spent many hours visiting offices and interviewing, and after a month of doing that, I failed to receive any decent offers from the companies that were interviewing me. It was baffling to me. There was so much interest and people immediately wanting me to interview with their company, yet I would be passed on or things didn't feel right for me. It was frustrating, and I was worried it was starting to take a toll on my self-esteem.
Nowadays, I'm getting direct offers from company CEOs when I'm not looking or spending any time on it.
I've been thinking quite a bit about this situation, and the more I think about it, the more I'm starting to believe that tech hiring is - for the most part - a broken process.
I do know why I failed to get hired in some of these instances, though. I would honestly not do very well when asked to implement some algorithm (hash table, linked lists, Red-Black tree, etc.) without the use of standard libraries. I have a Computer Science degree, but I have not used that knowledge in the real world since I graduated in 2003. So when the interviewer would pull out a question like that, I most likely would not do it as effortlessly as they would have liked.
Now, these are essentially "Tech Interviewing 101" questions. These types of questions are asked over and over and over again. There are even books dedicated to these questions alone. So why couldn't I study from these books and get these answers in my head so I would be able to do better with these questions during my interviews? I certainly could have, but I fail to understand why tech companies need these canned responses. Especially when the position I was interviewing for needed to be tested for this knowledge. For example, in over seven years of Ruby on Rails development, I've never had to implement a B-tree from scratch.
In most of the startups I have worked in for the past ten years, I've been involved in the interviewing process. I never really got a good feel for candidates when asking them questions that they could answer if they simply studied a book. These questions are good for simple screening, but not when the candidate is already in their third interview (as it happened with me with one company).
Out of all the interviewing techniques that I've seen others employ, I have two techniques that I like using, and they were great indicators of the candidate's ability to perform for the company. The first one is to ask them to talk about a recent project they have worked on as if we were going to be working on that project and were starting from scratch. This question is great because it allows the interviewer to notice a lot of things that coding exercises probably won't reveal. Is the candidate passionate about his work? Do they not only mention what went well, but also what went wrong? Can they mention a few things they would change now if they could? It's an open-ended question that seems a bit hard to fake. It also gives a feel for how they can fit culturally. If they bash their former company or co-workers while talking about this, that's a red flag to me.
The other technique I like is asking the candidate to build something (outside of the interview, on their own time) related to the position they're interviewing for, but having very few specific guidelines. For example, at the previous startup I worked for, we gave front-end engineering candidates an API endpoint to pull in certain data and asked them to implement something with it. The only guidelines were to pull that data from the API endpoint and put their work repository somewhere where we could access the history. Everything else - their choice of tools, how they displayed the data, what they did with that data - was entirely up to them. It has the drawback of taking up the candidates time (which kind of sucks when they're offered no compensation for it), but the task should be short enough, about four hours for someone who knows what they're doing. This is great because it shows people actually doing real work, and quickly shows who goes the proverbial "extra mile".
None of the companies I interviewed at employed these techniques, nor any others that can more accurately measure how I would work in a real working environment, like pair programming on a real business problem (although I do have to thank them for not asking me to answer insane "brainteasers"). That's why I've been getting offers now. Those extending offers have proof that I can deliver results for their business, which is what really matters for any company. And that's what interviewing should prove. Algorithms don't prove that.
Interviewing is not an easy task, and I'm sure no one has it 100% perfect. Bad hires can always slip in and cost a lot of time and money. But asking questions that don't necessarily prove what someone can do for your business can probably lead to a bad hire down the road while leaving a potentially great hire out.