Editor’s note: Now
for something completely different. Benjamin Weiss of Infusive Solutions,
out to colleagues in the HR and computer industries to develop a “hiring game.”
The “game” includes levels you have to “beat” to get to a job, starting with
the HR interview. The concept may seem like fun but the information Weiss and
his colleagues provide is invaluable.

The process of getting a software development position can,
at times, be stressful and convoluted.

Sure, sometimes your skills are so sharp or so unique that a
hiring firm will move faster than usual. Similarly, the firm may have a need so
urgent that leadership is forced to catalyze the offer stage.

But, many times software development candidates will find
themselves on an epic employment quest that requires complex progression
through different levels of hiring authorities before the job opportunity in
question is secured.

Wait a second … epic quest? Levels? Sounds a little like a
video game, right?

Let’s expand on that idea. When you think about it, hiring
authorities in technical interview processes are similar to the “bosses” that
players encounter at the climax of specific video game sections.

Just like a firm’s IT hiring managers, these bosses are
generally powerful gatekeepers that must be overcome before the game’s
protagonist (perhaps Mario, Zelda or Duke Nukem) can advance onto the next

And since different bosses have different characteristics,
protagonists need to deploy tailored strategies to successfully get past them
(though there may be overlap).

With that in mind, let’s make the process of securing a
software development job (which for us usually lands on the .NET/C# side of things)
more fun by treating this resource like the “cheat codes” to a game in which
you’re the protagonist preparing to go up against bosses, including:

  • The
    Human Resources Professional
  • The
    Senior Developer

  • The
    Software Manager

  • The
    Chief Technology Officer

In order to make these cheat codes all the more useful, the
organizing team at IT staffing firm Infusive Solutions
tapped experts in HR, software development and IT leadership to explain how
candidates can advance past each boss and reign victorious in a dream
development job.

Ready to start? Awesome! Put on your game face and prepare
to go up against the Human Resources boss in level 1.

Level 1:
Boss, The Human Resources professional

By: Jennifer
Loftus – National Director, Astron Solutions – Former President
of New York City’s SHRM Chapter

Anyone who has ever interviewed for a software development
job knows the first person you probably speak with is a Human Resources (HR)
professional. He/she has many questions to ask and holds the key to getting
through to the next levels where you’ll get to grapple with IT department
managers. But, how can you master this first level of the interview process,
which requires getting your application noticed, acing a phone screen and
building rapport with the HR boss in-person? 

Over the years, the HR professional has been stereotyped as
the police department of an organization, thwarting the efforts of internal
employees and prospective candidates. Remember Catbert from Dilbert, and
Toby from The Office?  They are
not the most flattering presentations of HR.

At times, you may find yourself frustrated by HR’s apparent
power over your career. However, HR’s main goal isn’t to prevent you from being
hired. Rather, their charge from leadership is to find the best-suited
candidates for a job opening, which may include any combination of education,
professional/supervisory experience and certifications depending on the
individual requirements of the spec. So what can you do to make sure that you
quickly rise to the top of the short list? Let’s explore a variety of
possibilities to help you build rapport with the HR boss and move on to level

Avoiding moves that get your avatar killed before the
first round interview with HR

Sending a résumé with typos

Your résumé is a reflection on you, your attention to detail
and your enthusiasm for a job opening. Sending a résumé with typos is a sure
way to say to HR that you do not care about the organization or the job.
Proofread and spell-check your résumé several times before sending it. Read it
out loud to catch errors you miss when reading. Ask a friend or relative to
read it as well. A fresh set of eyes may discover something you missed.

Sending a too-long résumé

You have accomplished many great things during your working
career and you want to celebrate them. HR wants to know that you are a good
potential fit for the job opening, but nonetheless has limited time to read
your résumé. Focus and edit your résumé to highlight your specific skills and
talents that pertain to this particular job opening. Your résumé should be
between 500 – 1,000 words, and two pages maximum. Using a small point size,
such as 8 or 9 point, is not an acceptable way to get around this matter. Use
an easy-to-read font in 12 point type.

Sending an incorrectly tailored résumé and cover letter

Customization, when done properly, is an excellent way to
show that you care. Therefore, before submitting that résumé and cover letter,
triple check to make sure that the job, organization and industry referenced in
the documents match the job for which you are applying.

For example, applying for a .NET development role at a
financial services organization with a résumé and cover letter expressing
interest in an IT management function at a non-profit swiftly puts you in the
“no interview” category.

One-upping during the in-person HR interview

Congratulations! You received a call from HR and have a
first in-person interview on your calendar. Here are a few cheat codes that
will help unlock the gate at the end of level 1 and help you move on to the
senior developer in level 2.

Arrive prepared and early

When you arrive at the employer’s office, you may have to
complete a variety of paperwork, including an application form. Build in enough
time for yourself to complete the paperwork so that your interview can start on
time. Waiting 20 minutes for an applicant who did not realize he or she would
have to complete an application can be frustrating, particularly if interviews
are scheduled back-to-back. Also, bring full contact information for at least
four truthful references who have agreed to speak on your behalf.

Dress professionally

As a general rule of thumb, it is better to be overdressed
than underdressed. Gentlemen, suit and tie. Women, a suit with a skirt and hose.
Wear dark, conservative colors and long-sleeved shirts. [Editor’s note:
Dressing in a conservative suit may not be appropriate for more creative,
startup-type environments so it’s always best to double check with HR

Take care of hygiene

Your personal hygiene should not be a distraction during an
initial interview. Before an interview, make sure that you do not smell of
anything strong, such as onions, garlic, coffee, cigarettes or perfume. Enjoy a
mint or a breath strip before you enter the employer’s premises to start the
interview on a fresh note.


During the interview, give your full attention and courtesy
to HR and turn off your cell phone to avoid unnecessary distractions.

Almost at level 2!

Proper clothing – check. Fresh breath – check. Fully
attentive – check. You are in the home stretch of level 1 now! Assuming that
you are in fact qualified for the job you have applied for, in no time you
should be on your way to interviewing with the IT department as long as
you  …

Maintain eye contact

Maintaining eye contact demonstrates your interest in the
position and the organization. Keep your eye on the interviewer – not your
hands, the ceiling, floor or window.

Go on the offensive

Many individuals have gaps in their work experience,
particularly after the economic downturn of 2008 – 2009. Rather than letting
the interviewer fill in the blanks to your detriment, proactively explain any
gaps in your employment. Being forthcoming and honest with such information
sets you above those who try to provide misleading information.”

Be prepared to speak about former employers

HR will most likely ask you why you left your last jobs, and
your favorite and least favorite parts of each role. Be prepared with your
truthful and tactful answers so you can respond quickly. Remember not
to bash your former boss
or colleagues as that reflects poorly on you.

Ensure understanding

Software developers use many acronyms: ASP, CAO, GAC, IIS,
etc. When speaking with an HR rep (who may be non-technical), define any
acronym the first time you use it to ensure common understanding. For example,
“when I earned my PMP, or Project Management Professional certification, I was
promoted….”  If HR still is unsure of the
term or acronym, he or she can follow up with more questions.

Ask questions

Do your homework on the organization and prepare at least
three or four questions to ask the HR rep. Some effective standby questions
include the following:

  • What is your favorite part of the organization?
  • Why do you work here? (People love talking about

  • How will IT support the organization’s plans for
    growth / contraction?

  • What are some common mistakes new hires make?

Say “Thank You”

If the interview has gone well, the HR rep should have spent
anywhere from 30 to 60 minutes with you. Within a day, say thank you for the
time by sending a handwritten thank you note in addition to an e-mailed thank

This old-school technique will set you apart from the crowd
and be appreciated and remembered by the interviewer. Include in the body of
your handwritten note a key point or two from the interview to personalize its
content. [Editor’s note: Be sure to have an extra pair of eyes on your thank
you note as a bad one could differentiate you in a negative way].

Alas, you’ve
avoided the landmines in the HR interview and your quest continues as you
journey on to meet the boss of level two: The Senior Developer.

Level 2:
Boss, The Senior Developer

By: Gayle
McDowell, Author of Cracking
the Coding Interview
and Founder/CEO of CareerCup

Just as actors have to audition for a part in a play,
developers also need to audition. Of course, a developer’s “audition” will be a
series of technical questions designed to test technical expertise.

Can’t they just know you’re good from your resume and
background? You would think so, but unfortunately, you can’t make any
assumptions. You could be lying or exaggerating on your resume. Or, your resume
could be ambiguous in certain ways.

One person’s “three years of experience with .NET” might
mean a few months of experience spread out over multiple years, whereas another
person could have three years of intense, everyday work. And, we all know that
years of experience don’t always have a direct correlation with skills.
Sometimes, the more “junior” person is better, and these questions are
designed to discover that.

Regardless of your feeling on the merits of these technical
questions, many companies stand by them. If you’re doing a lot of interviews,
it’s likely that you’ll encounter them and it’s best to be prepared.

Technical questions you’re likely to face will usually come
in one of three forms: knowledge
questions, coding/algorithm questions, and architecture questions. No
level of experience makes you “immune” to any type of question, though
it might affect the standards or expectations. In fact, many interviewers will
ask the exact same types of questions to all candidates, regardless of their
experience level.

Knowledge questions generally
have right or wrong answers. For example, an interviewer might ask you a
question like, “What does the keyword sealed in C# do?” or “Is it
possible to execute multiple ‘catch’ blocks?”

Obviously, the better you know the language, the better
prepared you’ll be for knowledge questions. You can also refresh yourself prior
to your interview by reviewing terminology and concepts from your preferred
programming languages.

Many popular interview questions can be found online on
websites like CareerCup
and Glassdoor,
so those are good places to look for questions you might face. For each concept
or keyword, make sure to think about where you might use them, what the
relative pros / cons are, and what the alternatives (if any) are.

If you don’t know the answer offhand, all is not necessarily
lost. You might be able to bring in your knowledge from other programming
languages or deduce the answer some other way.

For example, if you don’t know immediately whether or not
multiple catch blocks can be executed, you could think about how catch blocks
work and what it would mean to be able to execute multiple catch blocks.

Explain to the interviewer beforehand that you don’t know
the answer but you’ll try to deduce it. In some cases, you might actually be
able to demonstrate a better knowledge of the technologies by deducing the
answer than by already knowing it.

Coding and algorithm
questions are designed to test aptitude more so than pure knowledge.
That is, they’re tests of your coding skills and problem solving skills. They’re
supposed to make you think. This is good news actually; you don’t have
to just know the answer. The interviewer wants to see how you solve the

Coding and algorithm questions can vary substantially in
difficulty, and can include questions like:

  • Implement a program to check who, if anyone, has
    won a game of tic-tac-toe.
  • Given an array of integers, return the number
    that it repeated the most.

  • Design an algorithm to find the longest
    substring that is a palindrome in a string.

  • Given a binary search tree whose “left” and
    “right” pointers are represented with “first” and “second,” write a program to
    convert this tree into a sorted linked list. This conversion should be done in
    place, with the linked list re-using the “first” and “second” pointers.

Some of these questions might test knowledge of data
structures and algorithms, depending on your background and the company’s

To solve these questions, the following techniques work


Questions are sometimes more ambiguous than they appear. The
interviewer might have forgotten some details, or you may have misheard some of
the problem. Repeating the questions back and clarifying anything you’re
confused about can prevent you from running down the wrong track.

an example

If you don’t know how to solve the problem at first, using an
example can help you to brainstorm approaches. Be sure you come up with a
realistic example though. For example, if you’re writing up an example to find
the longest palindrome, you probably want to use a string with multiple

out loud

Your interviewer wants to know how you’re approaching the
problem; that’s part of why he/she is asking you this question. Talking out
loud will help show him/her that. It also has benefits for you though; it shows
you’re either making progress or that you’re off track. Your interviewer can
then get you back on track with some helpful hints.


If it helps you, consider writing pseudocode prior to writing your actual
code. This can be especially valuable in more complex code or in code that has
lots of little details and minutia.

your code

You may not get a computer to code up your solutions on; rather,
you will be expected to code on pen and paper or a whiteboard. Although your
interviewer probably won’t mind too much if you forget something like a
semicolon, you should strive to make your code as flawless as possible.
Pseudocode is usually not sufficient (although it’s fine as an intermediary


When you finish writing code in the real world, do you just check it in to the
source control system? Of course not. Likewise, in an interview, you shouldn’t
think you’re done just because you’re, well, done. Interview code needs to be
tested. No, you still won’t be given a computer, but you can run through your
code by hand using some examples.

When you find mistakes – and you
probably will – don’t panic! Mistakes are okay; no reasonable interviewer
expects you to just bang out flawless code, particularly when you don’t even
have a computer. Just think through your bugs and carefully try to fix the

On each question, you will be evaluated relative to other
candidates on the same question. Think of this like being “graded on a curve.”
The harder a question, the longer it will take to solve, the more bugs everyone
will have and generally speaking everyone’s performance will be weaker on an
absolute basis. Interviewers will therefore be a bit more lenient on all
factors. You don’t have to be perfect!

questions ask you to architect a system of some sort. This could be
something like an email system or a system like tinyurl.com.

In these questions, you should start off with understanding the constraints. Let’s
suppose we are building an email system. What are we building this for? Are we
building a massive email service like Gmail or Hotmail that needs to support
millions of users?

Or are we building an email system from scratch for a small
to medium sized company? What protocols will the mail system support? These are
all good questions to discuss with your interviewer.

Second, you should start with listing the components of the
system. For this example, you’ll probably need some servers for incoming and
outgoing mail, a database of some sort and possibly some servers or services to
configure it. The email clients themselves might also be considered part of the
system, particularly if it has a web frontend like Gmail or Hotmail. It might
be useful to get up on the whiteboard and start drawing some pictures; go ahead!

Third, you’ll need to describe how these components will
work together. When and how does each component talk to the other? Do the
incoming and outgoing servers talk to each other directly or does each read
only from the database?

Fourth, think about how to make the system better: faster,
more robust, etc. How will you handle having a lot of data? What will happen if
a server goes down? Is there anything you might want to cache in memory to make
the system more optimal?

Depending on the question, you might get into the details of
what technologies (which database, etc.) you might use. It would be wise to be
prepared with an understanding of the pros and cons of different technologies.

Phew! That was a
workout, right? Now that you’ve successfully navigated past HR and the senior
developer, it’s time to move onto level 3 and go toe-to-toe with the next boss
in the software development interview process: The Software Manager. 

Level 3: Boss, Software Manager

By: Ben Weiss,
Digital Marketing Strategist at Infusive Solutions

Special thanks to Sean Kennedy, Director of Software
Development at Steadfast
Financial, LP
and Ian Yamey VP of Software at Park Assist, LLC.

When grappling with the software manager in level 3 of the
interview, one of the first things to remember is that while this professional
will often have a technical background, these interviews typically evaluate
candidates on a more macro level.

On that note, it is generally assumed that if a software
developer has advanced beyond the “tech out,” they have sufficient technical
acumen for the role and now must be vetted for overarching problem solving

With that in mind, here are a few cheat codes to deploy when
preparing to go up against a software manager:

Don’t just answer the question

Because of the many intricacies that accompany software
development roles, a candidate with encyclopedic code knowledge may not be

Rather, these professionals must supplement their wealth of
existing knowledge with the mental agility to address a complex problem with a
level head and calmly design well-engineered solutions with a logical
step-by-step approach.

Those skills are difficult to test for and consequently,
many software managers will ask questions that might sound hard or even absurd
just to see how a candidate reacts.

One such question might be something along the line of “How
many pizzas were delivered in Manhattan last year?” While this may sound
unreasonable at first glance, the best development candidates will grab a pen
and paper and start devising a strategy to arrive at an educated estimation.

For example, you might start with the fact that Manhattan is
roughly 23 square miles, estimate the number of pizza joints per square mile as
well as a rough number of pizzas delivered by each establishment every day to
arrive at a rough conclusion.

This approach is far superior to just throwing out a number
or looking into the distance with your eyes glazing over. In fact, you’ll
virtually always be seen as a superior candidate than the next person who may
have experience and a well-padded resume but whose inability to tackle the
problem logically will suggest they can’t think outside the box and are only
successful when given specific instruction.

Ask about the big picture

On a similar note, software managers perceive the best
candidates to be those that want to understand how their technical niche will
impact the larger vision of the company.

Consequently, they’ll be looking for an indication that you
don’t just want to get your job done, but get it done in a way that makes life
easier for the rest of the organization and even more so for its

One strategy software managers may use to gauge such is
asking a candidate to do the simple task of drawing an action figure. In this
instance, the average candidate will just draw the first thing that comes to
mind. However, the best candidates will ask questions like ‘Is the action
figure targeted at males or females? What is it made out of? Should it have accessories?’

These types of follow up questions are fantastic to suggest
to software managers that you’re the type of person who wants his/her work to
fit into an established vision rather than someone who just wants to complete a
series of tasks and go home.

The bottom line is that you should be cognizant that many
questions in the higher rounds of the interview process may not be what they

Detail how you stay informed

Considering how quickly technology evolves, software
managers are looking for development candidates who are engaged with thought
leaders in their field and stay abreast of new trends so they can seamlessly
evolve their style and skills along with the industry. Consequently, if you
express that you regularly visit MSDN and follow Scott Guthrie’s work, that
will leave a far more resonant impression upon a software manager than if you
say you only read sneaker blogs in your free time.

Moreover, while you may not need to be proficient with the
latest version of C#, for example, software managers are nonetheless looking
for candidates who understand what’s new and exciting about latest and greatest
software iterations.

As such, even if you haven’t used the newest version of the
technology yet, be sure to research the new features so you at least appear

Show a desire to learn and create impact

Average software development candidates want a job. Awesome
candidates want a job at which they can become a better professional, make a
difference and be noticed.

To showcase you’re an awesome candidate to a software
manager, ask questions about what kinds of things you might be able to learn on
the job or how you as a developer would be able to transition an idea to an
implementation stage. These exhibit a willingness to constantly grow and
improve as well a desire to make your mark at the company, both highly sought
after characteristics.

So now you’ve
gone head on with the software manager and came out victorious, ready to
complete your quest for gainful employment as a developer after meeting the
final boss: the Chief Technology Officer (CTO).

Level 4: Final Boss, Chief Technology Officer (CTO)

By: Ben Weiss,
Digital Marketing Strategist, Infusive Solutions Inc.

Special thanks to Greg Meyer, Chief Technology Officer at
Strategic Technology Consulting, LLC.

The first thing to remember here is that the CTO’s profile
is highly variable. For example, at smaller companies, the CTO may be virtually
synonymous with the software manager or senior developer and thus the tools to
impress him/her in those instances can be found in the cheat codes for levels 2
and 3.

Additionally, at some firms, the meeting with the CTO will
be nothing more than a handshake and a brief chat about the firm and its goals.

But, for now let’s assume that you’ve advanced to an
interview with a “classic” CTO – a member of the executive committee who
reports to a CEO or board of directors, is deeply immersed and experienced in
business, finance and brand imaging and who is very much a C-level strategist.

In this case, any way you can show your interest and
commitment to forward-thinking technical investments, macro strategy,
interoperability between departments and team dynamics is paramount.

With that information in hand, here are a few other cheats
you can dial in before stepping into the CTO’s office.

You may not need to be long-winded about the tech

A CTO may ask you a few standard technical questions to
quickly gauge your qualifications. However, by the time you’ve landed at the
CTO’s doorstep, your technical abilities have likely been thoroughly assessed
by other members of the team. Consequently, understanding your basic technical
qualifications should happen relatively quickly without much effort required on
either side. Nonetheless, still prepare yourself to dive deeper if necessary.

Stay smart when talking about topics outside software development

Just as in the software manager interview, the CTO may ask
deceptively basic questions that have nothing to do with software development
to determine your fit for the role.

“Assuming that they have the skill set to do the work I try
to get [software development candidates] to talk about non-software development
topics as soon as I can,” said Greg Meyer, Chief Technology Officer at
Strategic Consulting Technologies, LLC in Maryland. “Asking someone the
question ‘Who do you prefer: the Ravens or the Redskins?’ provides real value.
It’s not the answer to the question, but the follow-on conversation that’s
important as it leads to an understanding of accessibility [whether or not you
maintain availability via phone and email once you leave the office] and value

Similarly, other CTOs may ask scenario-based questions such
as how candidates have overcome a big challenge in their life to see how
they’ve thought through obstacles.

Naturally, candidates who say they’ve never had a problem
they weren’t able to easily solve are passed over.

So don’t allow yourself to be lulled into a false sense of
security and use even the simplest questions as a platform to describe your
suitability to the role at hand.

Convey a desire to grow with the company as a loyal employee

Remember that another of the classic CTO’s responsibilities
is to bring on the right developers, provide the tools for those developers to
be successful and simultaneously shield the team from any wrath trickling down
from the top of the totem pole.

As such, if you indicate to the CTO that your energies will
be distributed across a range of other responsibilities outside of the job for
which you’re interviewing, that could yield major red flags since he/she will
need to deal with the fallout of poor performance or spontaneous developer

Convey Adaptability: Considering the CTO typically
pioneers technical strategy at a firm, he/she will be looking for developers
with the adaptability to forge new trails with concepts or technologies
expected to yield growth and innovation.

Therefore, if you come off as set in your ways, resistant to
change and only interested in a narrow set of tools, you will quickly fall
behind candidates who have the ability and willingness to use whatever tools or
strategies the CTO wants to pursue.

Ask Questions Beyond Coding: Many development
candidates come off as just coders – those who can develop code based on a
technical requirement. However, the CTO will be impressed by those who
transcend the notion of the coder and show themselves to be true software
developers capable of analyzing and optimizing technical and business

So while you will certainly want to ask how a specific
technology is deployed within that firm’s environment, prodding into
release/change management, version control, automated testing and
internationalization can indicate you may not only be an asset to the firm’s
technical niche but a valuable player who can contribute to the firm’s overall


Remember that every hiring process will have individual
differences. Different organizations will bring different professionals into
the fold, at times requiring candidates to meet with others like a portfolio
manager, law firm partner or CEO.

On the other hand, some interview processes (especially at
smaller organizations with fewer personnel) may be shorter because a single
person rides the line between the CTO, software manager and senior developer’s

Also, certain industries like finance and law may have
stricter behavioral and appearance requirements, seeking candidates that not
only have solid technical and problem solving acumen but who are polished and
have pervasively shiny hair and shoes.

Consequently, make sure to combine these general tips with
your own common sense and diligent research. Use resources like CareerCup,
Glassdoor, your personal network or a trusted recruiter to learn the specifics
of a firm’s process and then supplement your approach with the most appropriate
pieces of information within this guide.

And of course, should you ever need more assistance, don’t
forget that your friends at Infusive Solutions, CareerCup and Astron Solutions
are always here for consultation!