Because machines still need humans
Tag Archives: hiring
August 20, 2013Posted by on
The world of professional software engineering is full of titles and grades. Employers use job titles as a means to help them build new teams with the right mix of talent, attract the right caliber of candidates when hiring, create attractive career paths and assist with compensation planning. However, many companies assign titles differently, making their systems difficult to understand, especially for younger engineers.
Sometimes employers will be very precise and define an engineering career track that might look like this:
Sphere of Influence
|Associate Engineer / Junior Engineer / Intern||0 years||Bug fixes, minor feature||Self|
|Software Engineer||1-4 years||Features||Team|
|Senior Engineer||4-8 years||Modules||Development Group|
|Principal Engineer||8-12 years||Product, Architecture||Company|
|Fellow||12+ years||Products, Technical Strategy||Industry|
This model is most often used by companies with large and well-established engineering teams.
Other employers use grades that sound more like movie sequels than job titles:
- Software Engineer I
- Software Engineer II
- Software Engineer III
- Software Engineer IV
- Software Engineer V
It probably won’t come as a surprise that the above bureaucratic-sounding titles are very similar to the definitions used by the US Department of Labor.
While it’s less common, some companies even drop the concept of job title progression completely and have everyone be just a plain old “Software Engineer,” regardless of their experience or talent. This can work wonders by preventing the formation of ivory towers and by empowering younger engineers to participate at the same level as their older peers. However it can be more difficult to implement because it goes against most people’s traditional (or even cultural) expectations, and it can cause unease for those engineers who strongly equate title changes with career advancement.
Given that there’s no standard structure for engineer progression, a Principal Engineer moving to a new company could be offered the less impressive-sounding title of Software Engineer, even though they may be taking on far more responsibility and increasing their sphere of influence.
Mature engineers tend to focus more on the opportunities and challenges available in a new position than they do about what they’ll be putting on their LinkedIn Profile. They know that any technical hiring manager worth their salt understands that every company uses different scales, and those managers won’t blindly assume that the candidate had been demoted mid-career if they see a title progression that looks somewhat backwards. They correctly focus on the engineer themselves and their innate talents, not on the details of their old business cards.
Should you worry about changing your title when making a move from one company to the next? No, you shouldn’t. At the end of the day, hiring managers for engineering positions are far more concerned about your technical chops than your title. Understanding your responsibilities and sphere of influence will be things that come out in the job interview. So, if you’re on the hunt for a new position, look for companies with a solid business model with a healthy and functioning team that will be taking on interesting challenges. Put minimal emphasis on the title you’ll bear once you work there, and focus more on how the position will allow you to develop your skills and knowledge. Those are the most valuable assets prized by any engineer, and by the managers who hire them.
April 30, 2012Posted by on
Bringing a programmer in for an interview and a coding test can lead to some interesting experiences, both for the interviewer and the interviewee. Most end up with the hiring manager telling them that they’ll “be in touch,” but sometimes a candidate just nails it. That’s when you consider extending a job offer before they get a chance to leave the building.
At TimeTrade we run a coding test during interviews that, for the majority of programmers, should take about 2 hours in total to complete. The whole test is comprised of a number of small problems to solve, each harder than the one before. That gives us a good initial gauge of performance based purely on completion time: if everything has been solved in under an hour, we’ll be smiling. But if two hours pass and even the first problem still hasn’t been solved, the candidate will most likely just be shown the door.
Above and beyond just solving test problems quickly, here are some signs that a programmer is truly awesome and should be handed a job offer before they leave your building:
1. They present multiple solutions
I recently interviewed a programmer who solved an entire set of tests twice: once with iterative solutions, and again recursively. I quickly made him an offer. Finding multiple solutions to a problem is a skill that engineers will need to use every day.
2. They write full documentation
Last year I interviewed someone who was so diligent, so detailed and so professional about his work that he created full Javadoc and comments for his code before he considered the solution complete. He even wrote fully automated unit tests and checked their coverage percentage. When I came back into the room at the 2-hour mark and found him typing furiously I initially thought he was having trouble with the test, but he was actually in the process of adding HTML formatting to his Javadoc. Engineers who do this intuitively are the kind you’ll want on your team.
3. They improve the test
We deliberately create tests that have some minor issues lurking within them, purely to see if the candidate (a) spots them and (b) is willing to fix them. It might be an inconsistent usage of quotation marks for strings, misleading variable names or anything along those lines. Candidates that look at all of the provided code as the test — not just the pieces we’ve asked them to write — are the ones who will do the same in our real product once they join our team.
An engineer who is willing to tell a potential employer that the supplied test contains problems shows that they consider the quality of their work to be more important than just agreeing to do what they’re told. Hire them and they’ll likely work wonders for your product, going above and beyond their assigned areas to make improvements where they are needed.
4. They refactor smartly
Most candidates like to get a solution working, then sit back and breathe a sigh of relief that they finished it successfully. That’s good, but rarely good enough to justify an on-the-spot job offer. The candidates that solve the problem but then jump right back in to refactor it are in a different category entirely. Their choice of algorithm doesn’t feel right, and they can’t ignore the feeling that it could be more efficient. Their code has some duplication in it, and that burns them up inside. These are the candidates who refactor, rewrite and improve their solution until it’s been crafted.
This can be a double-edged sword, though. If the candidate just keeps rewriting because they’re not happy until they reach a mythical point of “perfection”, there’s a chance they are one of those programmers who doesn’t know when to stop (and similarly, ship). However if they watch the clock carefully and are able to both solve the problem and refactor their solution before their time runs out, that’s a really good sign that you should consider an offer.
5. All other signs point to “hire”
Sometimes there are plenty of non-technical signs that you’ve found the right candidate. Your other team members take you aside and tell you, “We have to hire this lady.” Their personality feels like a great fit for the team. They have relevant and recent experience in what they’ll need to do. You know some people who have worked with them before and they tell you they are wonderful to have on a team (and that they’d hire them again in a second). The candidate is excited about the company and the opportunity and is hungry to start contributing.
If the candidate passes technical muster and all other signs point to “hire,” why wait? If you do, you may lose the candidate to another employer who knows how to read the same signs faster than you can. Instead, be decisive and make the offer fast, thereby telling the candidate how much the company wants them on board. It will help start the whole relationship off on the right foot, for both parties.
So the next time you’ve got a wonderful candidate in your building, don’t assume someone even better will arrive the next day. Make them an offer and get yourself – and the candidate – back to work.