Because machines still need humans
Category Archives: Interviews
August 9, 2016Posted by on
If you’re interviewing for a software engineering position, there are plenty of articles and books out there to help you get ready to answer questions from your prospective employer. There are far fewer resources to help you learn which questions you should ask if you’re the one being interviewed. Having interviewed hundreds of software engineering candidates over the years, I can tell you that the questions a candidate asks are often extremely revealing. And, because they’re usually among the final questions in the interview, they often leave behind an important impression in the interviewer’s mind.
If you’re like most software engineering candidates, you are probably prepared to ask at least some questions of your potential employer during an interview. Standard questions usually probe into things like technology stack choices, benefits, or the amount of autonomy afforded if you get hired. While those are all important questions to ask, they don’t reveal the level of sophistication of the engineering organization you’re about to join. That’s harder to determine, especially if you’re only given a couple of minutes at the end of the interview to ask a couple of questions, having been grilled for hours already.
Given that you’ll likely also only work at a small number of jobs in your career, you want to choose teams that truly help you to grow, and to do that, you need to surround yourself with high-quality engineering talent. During any interview process, I suggest that you use this valuable opportunity to get a deeper sense of the quality of the team you’re looking to join.
If you want to quickly vet the quality of the team that’s interviewing you, one question can get to the heart of the matter with immediate effect:
“Why did you choose your current software development methodology?”
The interviewer’s answer to this deceptively simple question will reveal a lot about the engineering team, but also about the company’s organizational health.
The answer to this question tells you if the engineering group is aligned with the business needs of the company by building software in a way that matches those needs. It also tells you if the engineering managers are sophisticated enough to truly understand how software should be built at their company, or if they’re just run-of-the-mill folk who just apply the latest and greatest buzzword technique to make the team look modern.
Here are some not-so-great answers, along with what they’re revealing:
- “We use waterfall because, well, that’s what we’ve used for years.”
The phrase “that’s just how we do things here” will probably be heard regularly at a company like this. There might be nobody willing to challenge the orthodoxy or rock the boat because people there are comfortable, and change is generally resisted. In large companies, more modern development methods might be difficult to implement, or are perhaps isolated to only certain teams. In smaller companies, it’s often a sign of a lifestyle business culture, which generally won’t lead to massive growth in either top-line revenue or development careers.
- “We are a Scrum shop because the CTO used it in his previous company, and he’s super passionate about it. He’s even a certified Scrum Master.”
This answer tells us that Scrum might be getting applied religiously rather than rationally. Just because Scrum worked for the CTO when he was at a different company doesn’t mean it’s the most appropriate methodology in his current one. A candidate hearing this kind of answer should dig deeper into their decision criteria for using Scrum now, and find out if it’s being regularly evaluated as still being appropriate. Also, given the passion of the CTO for Scrum, he might be unwilling to consider other approaches that might be more suitable. In general, answers that lead back to a single person’s decision can also be indicative of a hierarchical and rigid culture.
Some encouraging answers might be:
- “We use Kanban because we’re an early-stage startup and we have limited financial runway. We need to find product/market fit as quickly as possible, so we need to maximize the flow of features, prevent blockers, and build a strong feedback loop around things that we ship. We’re planning to re-evaluate our choice once we get real paying customers.”
This answer shows how the business goal – reaching product/market fit before running out of money – matches the methodology chosen, and hints at a good amount of introspection on the part of the management team. Those are all very good signs. Also, the fact that they plan to re-evaluate is another good sign that they are open to feedback, and most importantly, to change.
- “We use something of our own invention that is probably closest to Scrumban. We run pretty disciplined sprints, and we love the data we get from doing them. But, we are always looking for improvements in everything we do. In fact, our process looks very different now compared to last year, and that’s mostly because of some great suggestions that the engineers made to how we do things.”
This company sounds healthy in numerous ways: they are introspective, they use data to inform their decisions, they have a culture of continuous improvement, and opinions from the team members are both encouraged and implemented. They’re also showing humility, another important thing to look for – beware of companies that arrogantly think their development process has no room for improvement.
In summary, a great answer to the question will:
- Show that the team builds software in the most appropriate way to meet the company’s needs
- Make the interviewer open up enthusiastically as they proudly describe more about how they have chosen to work
- Be an identical answer to what each of the interviewers give (beware of teams with managers who say everything is rosy when their engineers say it’s anything but!)
- Reveal how open the managers are to engineer-driven ideas
- Show how introspective the company is, and whether they have a culture of continuous improvement
- Get the candidate the most value out of their very limited “ask the interviewer something” time, allowing them to better evaluate the job opportunity
Remember, asking a really good question or two of an interviewer can help your chances of actually getting the job. A good interviewer will be thinking not just about your ability to write code, but about your ability to contribute to team culture and growth. But most importantly, the answer to this question will give you a strong sense of how much you really want the job. In an environment where engineering talent is at a premium and candidates are often vetting many opportunities at a time, companies that truly know how to build great teams will seek to “sell you” just as much as you want to “sell them.” Even if you don’t use this specific question, use this valuable opportunity to ask questions about topics that will shed real light on what your career would look like with the company — not on questions that can easily be answered with a one-line email later on.
January 27, 2014Posted by on
If you’re looking to get a new programming job, there is a very important fact to know about hiring managers. Since they are very busy and receive lots of resumes for open positions, they will build a mental profile of a candidate’s skills by scanning their resume in just a few seconds. Much like when you meet someone in person, first impressions count.
Hiring managers hone their speedy scanning skills through years of experience on the job. Knowing how they interpret your resume’s content is often the difference between moving to that crucial phone screen stage and being ignored. Here are a few hints about what messages your resume is sending to potential new employers about your programming skills.
If you haven’t bothered to run an automated spellchecker over your resume, you won’t be expected to take care when writing code on a daily basis. Typos on a resume are typically viewed as a sign of laziness and disinterest, and can easily lead to them being dropped right into the employer’s trashcan.
Experienced technical hiring managers will quickly evaluate the precision with which a programmer uses language in their resume, and they will extend that impression to the candidate’s programming skills. When the hiring manager sees your typos, they have unpleasant visions of the many bugs you would create in their applications.
Engineering candidates frequently send resumes that are more than 10 pages long, describing in complete and exhaustive detail every single project the candidate ever worked on. There will be a careful mention of the exact compiler version used on a 3-month contract for IBM back in 1994, along with cryptic company-specific project names like “EDT/BTS” that would only make sense to a handful of people on the planet.
The immediate thought that jumps to mind for the hiring manager upon receiving such tomes? That the candidate probably never revisits existing code to refactor it. The idea of editing a complex routine to break it up into simpler constituent parts for better maintainability and readability is apparently not something that they naturally want to do. After all, they’ve been adding to their resume’s content for years without revisiting it, so why would anyone expect them to do the same with their code? Also, excessive length can also imply that the candidate has a problem prioritizing. In today’s world, where engineers frequently have to juggle numerous projects, prioritization skills are necessary.
Technical acronyms are understandably commonplace in software engineering. However, when a quick visual scan of a resume makes a manager feel like they are swimming in alphabet soup, they often build an image of the candidate as being someone who only knows tools and frameworks and has little ability to design software at an architectural level. On the other hand, if the position being filled needs someone who can quickly create “mash-up” prototypes using a diverse set of existing frameworks and tools, having an acronym-heavy resume might be exactly what the employer is looking for.
Lack of Creativity
If an employer were looking for an engineer to build a sexy new web UI, a boring, unimaginative resume created using a Microsoft Word template would be the last thing they’d want to see. Using a dull, expected resume format usually indicates a lack of visual creativity and curiosity, and the employer will often question the candidate’s ability to build aesthetically pleasing web interfaces.
Granted, plenty of engineers whose expertise is in building services that don’t contain graphical interfaces (such as server-side libraries or SDKs) have resumes that don’t push any creative boundaries, and could easily make fine candidates for positions responsible for working in those kinds of areas. However, a decent eye for design is becoming increasingly important for many engineering positions.
Resumes filled with pompous, overly complex language can be a sign of a programmer who prefers to look smart rather than communicate effectively. While this kind of candidate may have written some very dense code that works, nobody on their team probably understands it, and everyone is afraid to touch it in case they break it.
Programmers who have recently left a long stint in academia to enter private industry often produce resumes full of lofty language. In those cases, it’s probably a symptom of them having to write peer-reviewed papers for years rather than a desire of theirs to show off how many grandiose words they know. Still, an overly verbose, high-register writing style can be a red flag that the candidate may not naturally write code that is simple for others to understand.
Candidates who have a history of jumping from position to position every year ring the alarm bells for many employers – they are the last people a company would expect to think about the readability and maintainability of their code. They will be considered as the kind of engineer that gets excited about working on new challenges but gets easily bored when asked to work on fixing bugs in existing features. Engineers quickly develop expertise in niche areas in any company, so having people leave after a short initial investment is not only costly for the employer, but can be detrimental to overall team morale.
A job jumper might be wonderful for a position that needs someone to build features quickly with the intention of handing their work off to a dedicated maintenance team, or as someone who can migrate from project to project, but they would probably need to be paired with others to oversee their work and ensure that their code is good enough to be allowed to go into production for years into the future. After all, the chances that they’ll still be in the same company when changes need to be made to their work are pretty slim.
What You Can Do
Your resume is a window into your programming skills and your personality. Make a special effort to overhaul yours to be viewed as a more desirable candidate to potential employers. For example, if you’re worried about your writing skills, have a professional proofreader check your resume for typos or stylistic mistakes.
If you are friends with a technical hiring manager, ask if they’ll help you by having them spend just a couple of minutes scanning your resume and then telling you what kind of programmer you appear to be, and in what kind of roles they believe you would fit. You might be surprised at the feedback, but at least you’ll be able to take some action to change how you appear to potential employers in order to make sure you increase your chances of not only getting a job, but of earning a position that is truly a great fit.
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.
March 2, 2012Posted by on
We’re currently hiring web engineers to help build the next-generation of TimeTrade’s online appointment scheduling system. Lots of resumes come my way, but 99% of them look exactly the same, following this format:
“I’m a web engineer looking for web engineering work”.
[No link to an online portfolio. No effort to craft the objective to match the position for which they’re applying. Typically describes only what the engineer wants to get out of a new position, rather than what she or he will bring to the company that hires them.]
HTML, DHTML, XML, CSS, JSON, REST, SOAP, AJAX, PHP, CGI, VI, EMACS, …
[A boat-load of technologies, old and new, sprayed onto the resume as one enormous list of acronyms. No effort made to describe which technologies they are expert in versus what they’ve spent 5 minutes playing with on a boring Saturday afternoon. Alphabet soup.]
[A lengthy dissertation about every place the candidate has ever worked. Yawn-inducing descriptions of how they worked there. No URLs for me to see the web applications they built.]
…and that’s usually all I get.
Is there a factory somewhere that churns these out on a conveyor belt? Should I blame Microsoft Word’s built-in resume templates? Or perhaps it’s the fault of tech recruiters who encourage this kind of lazy resume format in the name of “consistency”?
There are plenty of great engineers who could use their experience creating awesome web applications to build incredible resumes for themselves but ironically, never do. These programmers work in a world of aesthetics, creativity and technical artistry and yet advertise themselves with the passion of a 40-year accountancy veteran who enjoys working in the windowless basement of a bank and whose favorite color is gray.
So let’s fix that. Here are some tips that will help you rise far above the crowd.
Completely rethink your resume format
Why submit a typical resume at all? Check out these really creative online resumes that were found on Pinterest. This kind of out-of-the-box thinking might not get you anywhere with old-fashioned employers, but I’ll be blunt: a submission along those formats will get you noticed here, and will very likely put you far ahead of the pack with many other employers.
Build an online portfolio
One of the fastest ways for an employer to figure out if they want to interview you is to show them what you’ve already built. Web engineers have a massive advantage over server-side engineers because their work is visible by its very nature, and very often publicly accessible online. If you’re writing a old-fashioned resume, at least list the URLs for your proudest work at the top.
If your work isn’t public (because it’s only available on pay-per-use sites or hidden behind corporate firewalls) then see if you can get screenshots of your web applications in action and submit them along with your job application.
If possible, build a personal website to host your work samples and advertise yourself using the technology you work in every day. I’d be more than happy to receive a set of URLs to personal sites on a daily basis rather than a bunch of 7-page resumes.
Focus more on the “what,” not the “how”
Technology skills are important, but they’re really a means to an end. Employers want to get things done, and the technologies used to build new features and applications simply aren’t as important as the effort itself. So tell us what you’ve built in the past, the impact it had on your customers and business, and why it should matter to us. Then – and only then – tell us what whizz-bang technologies you used to do it.
Prove that you’re a human
I’m happy to review any wonderful out-of-the-box resume sent my way and give constructive feedback. Those who follow the suggestions above are more likely to hear the words, “You need to come and work here!”.