Common Interview Questions and How to prepare for an Interview.
The Interview Process
Perhaps you’re a fresh grad out of university and you’ve never looked for a job before and now you have absolutely no idea what you’re doing. Alternatively, it may just be a while since you last moved.
In my experience developers fall into one of two categories: extremely fickle, moving jobs every 1-2 years, or insanely loyal and remaining with firms for well over 8 years.
If you’re in that latter group in particular then it can be daunting venturing out into the real world again.
The first sections of this blog go into great detail on each of the individual stages associated with the Interview process and cover Common Interview Questions. And then explain How to prepare for an Interview but first let's take a look at the process as a whole from a 50,000ft level.
Stage 1: Applying for jobs
The first step on the journey to better employment is simply getting your resume onto someone's desk. How do you do this though?
Depending on your industry, the first port of call is probably to a recruiter. Recruiters act as the middleman between companies and potential hires, with the recruiting company getting paid based on them successfully placing a candidate into a role.
Particularly in finance recruiters are the only option for getting your CV seen, as most firms don’t have an easy way to directly submit your CV.
Recruiters have pros and cons. They have access to the entire market, they know what roles are available and it saves you having to manually search around for job roles. This saves a lot of time and effort.
They handle the interaction with the new firm so you don’t need to write cover letters or contact people directly. On the reverse though, not all recruiters are built equally.
Some are brilliant and will only submit you for roles they think you’ll excel at; they will guide you through the whole process and be understanding and work with you to get the right role.
However, there are a lot out there who lack integrity and are laser-focused on getting you into a job, whatever it is, so that they can get paid.
The best bet is to speak with friends and colleagues who have been through the process to see who they would recommend. I personally can highly recommend iKas (iKas International | Recruitment partner global financial services) who have offices in London, New York, Australia, Singapore and Hong Kong, and BAH partners (BAH Partners) who are exclusively Hong Kong.
If a recruiter is not an option then be prepared to work extra hard. You’re going to have to manually hunt for roles and submit applications and covering letters. But how do you find the roles? There are a number of places online you can go to to find roles:
Browse Software Developer Jobs
Monthly “who’s hiring” thread at HackerNews (Hacker News)
LinkedIn. It’s a gold mine. It has jobs directly advertised on the site, but you can also search for companies you like and follow them as they will advertise roles. Search for terms like “Java Jobs” in the group's section to find groups where companies directly advertise role to.
Job sites and job boards like JobAware, Job Search | Indeed, craigslist
This is not a fun process. You will be made to fill out your basic details over and over again, and you’re likely going to need to write cover letters for each role. But this does mean you can very specifically tailor your search to particular firms, roles or areas.
Stage 2: Interviewing
Every firm has a different hiring process. Whilst one company may interview you face to face for an hour before making a decision another one may have you go through 7 stages of tests and interviews with different levels of seniority.
If possible, ask what the process is from the earliest opportunity. Your recruiter or the hiring manager should be able to tell you. This should give you the most opportunity to prepare.
Below are the most common types of interview steps you can expect:
The Phone Interview
Phone interview’s often come early on in the recruitment process. They’re a great way to screen out candidates before bringing them in for a longer, more thorough interview. The interview will last anywhere between 15 minutes and an hour and will be focused on a limited subset of technical questions.
Being on the phone limits the nature of the questions which can be asked as they all have to be verbal. Lack of a whiteboard or pen and paper tends to make the interviews very theoretical or experience based, without much in the way of design.
Occasionally phone interviews can crop up later in the cycle, normally as a final round. This is normally after you’ve aced all of the other stages, and the manager who needs to sign off wants to have a chat with you.
It should just be a formality, and normally involves questions about your experience and what you want from the role.
The at-home technical test
I’m a big fan of sending a homework to a candidate. It allows you to prove you are technically able without the pressure of being in an interview setting.
Normally the exercise will take between one and three hours and will ask you to develop an effective solution to a problem, likely involving an understanding of complex requirements, some sort of algorithm and maybe some threading.
The important thing is to spend the time necessary to produce code that you are proud of before you submit. Any team that has this stage will value code quality highly so it’s important not to cut corners.
The In-office technical test
There is a wider range of possibilities if you’re asked to go in for a technical test.
It could be a complete equivalent of the at-home test; a number of firms don’t trust candidates not to cheat at home (and from experience I know this does happen) and so ask them to do an exercise in the office. Normally it will be much shorter though and take a maximum of an hour.
As opposed to a single exercise, it’s possible to receive a number of much smaller questions like an exam. This allows more focused questions on specific areas, and mean that if you fail one section of it you can still pass the test with flying colors.
My preferred method is the pair programming test. In this scenario, you sit down with someone from the hiring team and program together through a predetermined exercise.
Along with being tested on your technical ability the pairing exercise allows the hiring team to see how you work. Do you have a good grasp of keyboard shortcuts? Do you write tests first?
Why did you choose to design this the way you did? If you get the job you will all be working together very closely, potentially for years to come. It’s important not only that they like your coding style but that you like theirs.
Face to Face
In personal interviews is the best chance you have at landing a job, irrelevant of what stage in the process they are at. The simple fact is, people are biased.
If you can sell yourself strongly to an interviewer then that person is going to be your biggest salesman. “I interviewed this guy and he was really good, we’ve got to bring him in”. Often convincing a single person is all you need to grease the wheels of the entire interview process.
The face to face interview is likely to cover the broadest spectrum of questions and topics. Access to pens and paper or a whiteboard make this the best format to ask design questions in. Expect to be grilled about a system you’ve worked on before or asked to design something on demand.
Similarly, interviewers love to ask people to write up pseudocode, particularly questions around creating search or sort algorithms. This tees the path up nicely for some big O type questions, but more importantly, gives your potential employer the opportunity to see how you work through a problem.
One on one
The simplest interview. Person to person, normally for an hour or even more. This has the benefit that you are only trying to impress a single person, but this, in turn, means that if you get off on the wrong foot, or the person you’re interviewing with is having a bad day then you have a problem.
Try to get an understanding of who your interviewer is before you go to the interview if possible.
From my experience, these one to one meetings are normally with team leads or above, so whilst there will likely be some technical content the main purpose of the exchange is to understand how you are going to fit into the team and wider company culture.
Personally, I think this is the most difficult of the interviews. Normally 2 or 3 of your potential new team members will be sat on the opposite side of the table throwing their best questions at you whilst you try your very best not to embarrass yourself.
I find this interview the worst because impressing 3 people is really hard to do. Everyone has their own opinions and ways of working and the likelihood of you being able to satisfy all of your interrogators is slim.
The speed dating interview involves cramming in as many interviewers as possible within an allotted space of time. The default tends to be working through 3 separate interviewers.
You remain in a room and interview with each one for 20 or 30 minutes before they disappear and are replaced with yet more people asking different questions. I’ve even experienced this before when one of the interviewers has been dealing in using Video Conference.
From an interviewers side, this is great; you get a consensus opinion from a number of members of staff (anyone who gets a yes from all three is a definitive pass) and it also means you can interview 3 candidates simultaneously. This is a really effective way of churning through people.
From the interviewee side, however, it can be intense. That’s a lot of interviews! If you’re just doing 1 hour with one or two people then once you’re in the flow things are good. You can get comfortable with your interviewer.
However, seeing lots of different interviewers means you can’t relax. You’re constantly trying to figure out what each person is looking for. It is really hard work, and there is no way to prepare for it beyond regular java preparation.
The best advice I can give you if going in for one of these is to remember that everyone’s different.
Although generally there will be team themes (maybe they all love Test Driven Development) the individuals will all like different facets, prefer different technologies. As with any interview, try to strike up a rapport with the person on the other side of the table.
Whilst obviously it is important to be technically able, a huge percentage of your success is going to come down to whether the interviewer likes you and your attitude.
Example Interview Process
To give you an idea of what to expect, here are some example processes I’ve gone through before:
Major Australian Bank:
One on One Interview with team manager
2-hour technical interview; 1-hour face to face with a local developer, 1 hour with
2 developers over Video Conference
Interview With Department Heads
Small Charity Firm
Face to Face with the future manager and department head
Major International Bank
30 Minute phone interview
Pair Programming interview with 2 developers Group Grilling with 3 developers
Creating your resume
You only get one opportunity for a first impression, From which point it’s either working for you or against you. This applies across all media, from websites (where you have 7 seconds to impress the visitor) to meeting a new person at an interview (where you have even less).
Getting off on the wrong foot means you need to be incredibly impressive to stand a chance of landing your new role, which whilst not impossible is certainly going to make a difficult interview even harder.
On the other hand if you arrive and can make a bond with an interviewer then the job is yours to lose; psychologically they’re going to be rooting for you to do well, so as long as you don’t make any major mistakes then the person on the other side is going to do try his best to get you hired.
“But how does this relate to my CV?” I hear you cry. Your CV is your very first impression. When those pages land on someone's desk it is the first time they have been exposed to you and what you stand for.
Interviewers receive hundreds of CVS for every role so understandably very few of them stand out as exciting.
Let’s be clear; your CV is a sales document. After reading your hard-crafted words you want whoever is reading it to turn to the person next to them and say ‘hey, this guy looks really good. We should bring him in soon”. I would say this happens for me every 20 CVs or so.
Before we dive into crafting the perfect programmer’s propaganda, I have one crucial piece of advice that applies not just to CVs but to all of the hiring and interview processes that you’re going to go through.
Killer advice: Everyone is different
All of the people you are going to talk to during the interview process will have differing opinions on what makes a good developer.
If there was a standardized exam or some other way of telling a good developer from a bad one then it would make hiring a whole lot easier (and no, being a Sun Certified Java Programmer does not even come close).
Every interview you go to is going to have different questions and each interviewer is going to have a different set of values. One may value polyglot developers. Another may value TDD and BDD. The next may believe all code should be done in notepad and hand-compiled. There is no golden bullet.
As a candidate, it can be hard to remember this. Perhaps your CV isn’t getting you interviews, or maybe you’ve been on a couple of interviews and haven’t progressed. Your head drops and you conclude that you’re stuck where you are and that you’re not good enough to get a new job.
The reality is that you’ve just not found a place that aligns with your values yet, and that’s ok.
What you want from a job may make it easier or harder for you to find a role. For me, I hate big-o notation and performance questions because I have to google nearby and I believe people have a tendency to prematurely optimize code; real performance problems happen very rarely.
That means there are interviews where I come out and I know I have done terribly, and I don’t care. I’m comfortable knowing I don’t want to work for that team because their values don’t align with mine.
Does that make it harder for me to get a job? Yes, but it means that when I find a role it’s the one that I really want. You spend most of your waking life at work, so you may as well spend the time to get it right.
This is a roundabout way of saying that there is no golden template for your resume. You can send a CV to 5 different people and get 5 different responses.
All you can do is bulletproof your document so you don’t have stupid things like spelling errors (which happens a lot) and then use your text to craft a message that makes you as desirable as possible to the type of people you want to work for.
How long should it be?
This is the source of much debate. My view is vehement that if possible, it should be one page (with an absolute maximum of two). People don’t have time to read resumes in detail and they don’t care what school you went to or your last 15 jobs. They want a brief sales pitch about why your skills fit the job.
By keeping it brief and packed with only important information you’re making the job much easier for the reader whilst demonstrating your ability to communicate concisely.
On the other side, it should be noted that in the past I have been told by recruiters to bulk out my CV. If you’re working with a recruiter they will often cut up and edit your CV as appropriate for roles anyway.
As a result, I keep 2 copies of my CV; the first is a brief, single pager with my key roles and experience condensed down. The other is a 2 pager with as much stuff crammed in as possible for recruiters to work with.
Do not be tempted to create a 15-page tome with thousands of words. When I receive these it’s an instant red flag. Bigger is not better and you’re just highlighting your inability to communicate effectively. If the company needs your history going back 15 years then they will come and ask you for it at a later date.
A resume is your sales document to say what your best skills are with clear examples of you using those skills to achieve great things. Let me say that again.
Your CV is your opportunity to say what your best skills are. It should be achievement focused, showing what your amazing talents are, and what they’ve helped you to achieve.
Not all candidates include this but I think it’s the most important part. This is a single paragraph introduction to you and your brand. What do you stand for? What do you care about?
Think of this as your elevator pitch, where you can outline what makes you great and why someone should hire you.
Talk about what your passions are; maybe you love TDD, or you think of yourself as the tsar of concurrency. Start off with this. It’s a nice way to set the stall at the start of the document.
Avoid being tacky in your opening blurb. Don’t forget there is a person on the other side that’s going to be reviewing this; candidates seem to love piling in as many buzzwords as they can: “self-motivating with attention to detail”. What does that even really mean? I can guarantee the person reading your CV won’t know.
If someone asked you during the interview what about you exemplifies those skills could you answer it? I’m guessing not convincingly. Aim to write in a clean and simple fashion.
If there are some buzzwords you want to put make sure that you have the material to back it up; my CV talks about how I’m a passionate technologist, which I then back up with outside of work projects and examples of where I’ve used that passion in my roles.
The simple fact is, most of it won’t get read. The person recruiting has a lot of these to read through so will likely read only this paragraph and if you’re lucky to skim the rest. Get this section right and put your most impressive material first.
You don’t need more than the last 5 years or the last 3 roles, whichever is smaller. This should be brief and focus on what you produced and how you did it.
It’s incredible how many summaries I read which tell me all about the history of company X where the candidate worked and the ambitious project that the company was executing. That tells me nothing about the person behind the resume. Here is an example of what not to do:
“Senior Java Developer, Awesome Co. July 2012- July 2014
Awesome Co. is one of the worlds leading investment banks. Based in New York and with offices around the world, the company prides itself on a customer-centric approach to banking.
I was working on Project X. This project was a 200m investment to create a next-generation banking platform over an ambitious 3 year period based on Java and NoSQL technology. The project has a strong focus on agile delivery and creating a low latency system”
You’ll notice there’s almost no reference to the candidate. Too many programmer resumes are formed like this. Compare this instead to the following resume example:
“Senior Java Developer, Awesome Co. July 2012- July 2014
Successfully lead a team of 6 developers using agile methodologies and iterative delivery on an ambitious timeline to produce an industry-leading platform.
I introduced the use of iterative delivery and story planning which allowed us to accurately predict our velocity and allowed us to consistently deliver to production every 2 weeks.
I created a comprehensive NFT framework which allowed us to run regressions quickly and ensure we were meeting the high standards set by the business
Led the design of the system and introduced ActiveMQ and MongoDB to produce an exceptionally quick and easily tested system; all code was built using TDD”
This time the entire article is focused on the candidate. I now know what they have done and what they have achieved. It’s a much more convincing sales pitch.
Also, people love lists. A list of achievements is much easier to parse. Use lists as much as possible!
If you’ve done stuff in your job which is extra to the regular role you need to shout about it. The best candidates want more than to come in, code for 8 hours and then go home.
If you’ve been on a course or training that you think is pertinent then put it down. Here are some ideas; if you’ve not got any of these then start doing them now!
Any innovation projects you may have done, or tools and techniques pioneered. For example, maybe you introduced JIRA into your organization. Organized guest speakers to come and speak to the team
Organized teams to do presentations to each other in a weekly forum Contributions to Open Source Member of a community such as an agile group Participated in events like Startup Weekend or Angelhack.
It’s this kind of extra work that can make you a stand out candidate in a competitive marketplace.
99% of people reading your CV will not care about your education. A lot of programmers have come from non CompSci backgrounds, and some don’t even have degrees.
Your vocational experience is infinitely more important in a development role. Include your degrees, and maybe a line on your A Levels, nothing more. Put this section at the end of the document. It’s unimportant so waste as little space as possible on it.
List of technologies
Don’t do it. For some reason more and more resumes coming with a list of every technology the candidate has ever touched. Some CVs even have scored on them now to say how proficient in each technology the applicant is.
If you know a role is keen for a specific technology then tailor your experience section to explain how you’re awesome at this.
If you have stuff you want to cover off that hasn’t been suitable in any other section then have a small “skills” section. Whatever you do, don’t just write a list of technologies.
It impresses no one and the interviewer could call you out on any of those technologies. If you don’t feel comfortable being able to answer in-depth interview questions on a technology they don’t list it!
There are some great tips related to this and building a good CV in the Core Java Interview Questions Podcast with Sarah Sellers, a recruiter with a lot of experience in helping candidates out. You can listen to Podcast Episode 5: Recruiters! with Sarah Sellers |.
Top tips for standing out as a candidate
If you’ve done any “extras” in previous roles, then put these in. It proves that you go “above and beyond” in your role.
If you have personal projects or shared projects you contribute to the list these. Candidates with their GitHub on the CV make a big impression as it shows you like coding so much you go home and do even more of it. That’s passion.
If you have a personal website or blog then include it, but make sure it looks good and has been updated in the last 6 months. I’ve seen some terrible candidate websites, and it instantly puts me off. Make sure your site is looking good and up to date and it can absolutely earn you some extra credit.
If you’ve been playing around with technologies at home then list them and what you’ve been doing with them.
A lot of organizations will limit the permitted technologies you are allowed to use; if you then go home and play with NoSQL or node.js then by putting this on your resume you are displaying a wider awareness of technology which is a sought-after skill.
Make it look pretty
I’m being very serious when I say most CVs don’t stand out. They’re just blocks of text going into pages and pages. Having just a little bit of design can make a big difference.
I’m a huge fan of google docs for this; they have some basic attractive templates which can make you stand out just a little from the rest of the pile. It’s not much, but it’s often enough.
I’m a huge fan of using a phone interview at the start of my hiring process. As someone trying to recruit it’s important that I have some way of filtering the hundreds of candidates that get sent through.
I’ve come to accept most people are terrible at writing a resume, and some just plain bend the truth, so before I meet someone face to face I find it’s useful to speak to them on the phone for 20 minutes to ensure that they do know Java and get an understanding of their background.
As a candidate, it’s also an opportunity to make a good first impression. Many people panic that they won’t be able to do themselves justice over the phone (and indeed, candidates who fail often cite this as a reason), however with a few pieces of key advice you can be sure to come out on top of the pack.
You may be dealing with a recruiter or with the firm directly. Either way, contact them and find out the exact details of the phone interview. You want to be as prepared as you can be. Specifically, you should ask:
How long will it be?
What sort of questions will be asked? You’ll be lucky if you get an answer to this, but it’s good to know if the questions are more likely to be technical focused or design focused. Phone interviews tend to have a technical slant as design interviews are really hard to do without a piece of paper or a whiteboard.
It’s certainly worth asking as you might hit lucky and get some gems of information to help you in your preparations.
How many people will be on the call? Who will they be? Phone interviews with one or two people will generally be easier as you can identify who’s who and an understanding of their interests and question style. Above that will make it a little more difficult.
It’s the time to simply to hit the books and get revising. Chances are you’re going to get a lot of “what does this thing in Java do?” type questions, as they’re easy to do over the phone. They’re not necessarily good questions, but they’re the questions interviewers tend to fall back on.
Make sure that whenever you’ve booked your interview for you have somewhere quiet and private to go. Make sure you get there 5 minutes before the interviewer is due to call. There is nothing worse than starting your call flustered because you don’t have a place to do the interview and it leaves a terrible first impression.
As an interviewer I have a limited amount of time; I tend to bunch phone interviews to be back to back or slip them in between meetings. If you waste 5 minutes then you’re losing an opportunity to impress the interviewer.
Make sure you have a copy of your CV with you. The interviewer will have a copy too and will ask you about it. I would guess that you can’t remember what you’ve written on your resume to have it in front of you. It’s very embarrassing when someone asks you about a part of your CV and you have no idea what they’re talking about.
Ensure you go in with a pre-prepared list of questions for the end of the interview. You will get asked and it’s important that you are quick to respond.
I want to know that you care about the role I’m hiring for and have spent 30 seconds to look at the job description and that want to know more. Interviewers (and people in general) are egotistical.
It doesn’t matter if it’s a simple “I was hoping you could tell me more about the role”; just make sure you don’t spend 5 seconds in silence as if you hadn’t expected the question to be asked. Have 2 or 3 questions lined up? It doesn’t matter if you really want an answer, the act of asking is what matters.
For the exceptionally lazy, here’s a list of example questions:
Please, can you tell me a bit more about the team? What size is it? What experience levels?
Is the team based in one region or geographically split?
How does the team work? Do you use agile?
What’s the biggest frustration in your current job?
What’s your favorite part of working at the company and in the team?
What does an average day look like?
How hard is it to use new technologies in your company?
What training exists?
It’s also an opportunity to impress and show off. Say you know the people you’re interviewing are really keen on a technology or technique, like Test Driven Development.
Use your questions to promote yourself! “I’m a huge fan of TDD and was wondering how exactly do you use it in your team?”. Or “I’ve always wanted to learn TDD but have never been given the opportunity.
I find the concept really exciting. Do you think the learning curve is manageable?”. This is music to an interviewers ears because you actually care. If I’m doing 3 interviews a day, 5 days a week things like this really make a big difference.
Tips for giving the best impression
When your phone rings, think positive. Be positive. Sound happy. As cheesy as this sounds, the old adage of “you have 7 seconds to make a first impression” is spot on.
The amount of candidates I call that sounds grumpy and/or uninterested is crazy. This instantly turns an interviewer against you and unless you nail all the questions you’re going to have a hard time getting through.
Conversely, if you pick up the phone, sound excited and tell the interviewer you’ve been looking forward to the interview then you’re in the positive books from the start.
Speak slowly. You don’t want to rattle through the interview at a lightning pace. But, don’t speak so slowly as to bore the interviewer. Most importantly, know when to stop.
I’ve had candidates give me 5-minute monologues on Spring before I’ve had to step in. Being able to craft a succinct answer is a hugely important skill, not just in interviews but as a java developer.
It takes practice but it is well worth it. If you’re worried about not answering the question fully, simply say “is that ok or would you like me to continue?”.
Chances are the interviewer will have picked up on something you’ve mentioned and will change the direction of the question or ask a new one. If not they may simply ask you to continue and you can keep talking. Some quick don’ts:
Don’t sound bored
Don’t chew gum
Don’t google answers
Don’t interrupt the interviewer
Don’t be afraid to say you don’t know. Trying to guess your way through isn’t going to fool anyone. If I’m asking the question then I probably know the answer.
It’s absolutely fine to say “I don’t know about that, but I’m happy to try and work it out if you’d like”. That way everyone knows you’re not trying to lie your way through. Candidates capable of admitting they don’t know will always gain respect.
What you will get asked during the interview
Due to the limitations of the telephone, you can be fairly certain that the questions will be based in one of four categories:
Core Java: threading, exceptions, data structures & algorithms, object-oriented programming etc.
This is the basic stuff you simply need to take the time to revisit. Whether or not they are good questions to ask to determine your ability is irrelevant; most interviews will fall back on this so it’s good to be prepared. Reading the second half of Java Interview Bootcamp is the best place to start.
Technology discussion. “Have you used technology X (or “I see from your CV you’ve used X)?”, “Can you tell me about it? What do you think of it?”. My default go-to topics are Spring and Hibernate as they have a lot of questions that can lead from the initial one and really go into depth. They also appear on most people’s CVs.
This is the sort of question I prefer to ask as you can get a proper understanding of a candidates knowledge and whether they understand the tools they use, or if they just use them because they’re told.
Look at the core technologies on your resume and figure out what your opinion is on them. The interviewer most likely won’t care what the opinion is specifically, more than you can articulate the pros and cons of each side and draw a conclusion.
Techniques. I love asking about these. Every office works differently; agile vs waterfall (yes, waterfall still exists), TDD/BDD/other DD, programming style etc. Again, if you have put these on your CV then you need to be sure you have good answers for your experience with them.
If your department uses TDD so you’ve put it on the CV but you don’t actually do it you’re going to look bad. Again review your CV and look at what you’ve listed; come up with strong explanations for each of them.
Riddles. This is made up of the google-esque questions like “how many grains of sand are there in the world?” and “What would you do if you were stuck in a lift for an hour and a half?”.
It’s good to try and read up on some of these just to get comfortable with answering them, but in reality, they’re not something you can do a great amount of study for. Personally, I’m not a big fan of these, but every interviewer is different.
Try not to guess what the interviewer is looking for or what you think the interviewer believes is the “right” answer. They may intentionally lead you down the wrong path to see if you’re a “yes man”.
Stick to your opinions even if they seem controversial. Be polite, be honest, and try to engage in an open discussion. The person on the other side of the phone isn’t a robot to try and engage the human side and have a 2-way conversation.
If a candidate fires a question back at me during an answer I tend to enjoy it. An interview should be two way.
After the interview
Normally you should have a pretty good idea of how you’ve done, but don’t fret. I’ve had candidates who thought they’d tanked who was actually really good.
Conversely, I’ve had terrible people who thought they had done brilliantly. Simply wait to hear back from them and relax comfortably in the knowledge you’ve done your best.
If you don’t make it through then don’t sweat it. The fact is that every interviewer is different and has different opinions, every company values different things and you may not fit into the team at that time. That’s ok. Just keep applying to different roles.
On top of this there is a human element; maybe the interviewer woke up on the wrong side of the bed, or they haven’t had lunch yet so they’re hungry. It’s terrible to think that this could affect your potential job but it’s a fact of life. Whatever you do, don’t contest the result.
Emailing back to try and explain something better now you’ve had time to think about it or asking to be seen again isn’t going to work and may damage your reputation.
The industry is surprisingly small (particularly thanks to LinkedIn) so hold your head high, take the time to review what you could have done better for next time and move on.
Face to face interview
The vast majority of interviews you are likely to undertake during a recruitment process will be a variation of the face to face interview: as discussed earlier in the blog, there are a huge number of variations a recruiter can pick and choose from.
Although there are tips and tricks specific to each one there are some key tenets that run through them all which enable you to best represent yourself as a candidate.
Whilst having the technical skills for the role is obviously crucial the reality is that success is often determined by gut feel-whether or not the interviewers have a good “feeling” about you.
You can influence by the way you present yourself; your handshake, the conversations you have and your body language. In my experience, these things end up being massively influential when making a decision about a candidate.
It is cliche, and I’ve already said it multiple times, but first impressions really are everything. The initial meeting can be the difference between success and failure even though you’ve not answered a single question.
Although I think any bias is unconscious, people will ask easier questions of candidates that they like from the initial introduction alone (and vice versa harder questions for difficult candidates.
But what makes a good first impression?
Turning up on time:
It’s baffling that this needs to be written down but the number of candidates I’ve had arrives late is incredible. You are being interviewed by busy people who are taking the time out of their day to sit with you.
The moment you arrive late you’re in the “no” column and fighting to escape. Ideally, try to arrive about 5 minutes before the scheduled start time.
It is also important not to arrive too early. I know everywhere I’ve ever worked has struggled for meeting room space and if you get there really early it puts the burden onto the interviewer to find somewhere for you to wait.
You don’t want to have them pulled out of an important meeting to deal with your arrival because you’ve turned up far too soon.
It varies by industry, but I’ve found generally people don’t bother with a full suit and tie combination anymore, generally just wearing trousers and a shirt. I think this is preferable and will help you to relax.
If you feel more comfortable wearing a suit then go for it, you’re not going to get marks against for dressing too formally (although I would recommend taking your suit jacket off when you get to the interview itself).
However, make sure that whatever you wear fits properly: don’t be the classic stereotype of a geek wearing a suit two sizes too large.
I’ve had people show up to interviews in jeans and a t-shirt before. Don’t do that ever. You will never make a bad impression by dressing up too much, however, you certainly will by dressing too casually.
Never underestimate the importance of a good handshake. There are three types of a handshake. The first is the weak, limp shake which a lot of geeks suffer from as we tend to be timid.
You are making a statement about the type of person you are with your handshake. If yours has no-pressure then the conclusion is you are weak in the office: less likely to stand up at the whiteboard or to have strong opinions. All from just a handshake!
The second sort of handshake is the bone crusher. At the very another end of the spectrum is the type of person who has heard that a strong handshake is important and as a result attempts to crush the other person's hand as a show of force and strength.
Again, avoid this. It signifies you are an overbearing personality or you’re overcompensating for something. It also hurts! This is equally as bad as the limp handshake.
Instead, we want the third shake, the Goldilocks of handshaking: just right. A good handshake conveys confidence but without being over the top. It is firm, with good pressure, but without leaving the other person feel they need to go to the hospital with a broken hand. Unsurprisingly this takes practice.
So practice! Ask your close colleagues, friends or family to practice with you. It can take only 3 minutes of testing out different pressures to figure out what a good handshake is for you but it can make a huge difference in your first impression.
I was lucky enough in school to have a teacher who ran a lesson dedicated to this and it has stood me in good standing ever since.
The awkward moment where you finally have to talk. The two major things you need to consider here are what you want to say, and how you’re going to say it.
Body language, mannerisms, and tone are all understandably important. Your job is to convey to the interviewer that you are excited for the interview and job opportunity. You would be surprised by the number of candidates who sound like they have no interest in being at the interview.
If your tone is dull and you sound like this is just another interview your recruiter is putting you through then why should the interviewer be willing to spend his time with you? Sound interested. Sound excited. Sound like you want the job!
Go into your interview with some ideas for small talk. Again, we programmers tend to be a quiet bunch lacking in conversational skills. Chances are there’s going to be some point from when you’re collected in reception to the interview starting where you’re going to need to fill the gap with conversation.
This is a great opportunity for you to sell yourself, whether you’re talking about something you’re working on at the moment or just being honest about your nerves.
It’s a chance to make a good impression and to bond with your interviewer. If you’re really struggling then ask questions. “What are you working on at the moment?”.
“I was reading up on Java 8 last night, have you seen the new stuff on default methods?”. It allows the other person to talk and takes the pressure off you and is also a great way to build a relationship.
People are usually better at talking than listening and will be pleased you’re asking questions and giving them the chance to talk. It sounds cheesy but it’s true.
Once you’ve made your incredible first impression, the hard work begins. Depending on the stage of the interview the content may vary greatly so it’s important to know what you’re going in for.
Make sure you talk to your recruiter or the hiring company beforehand and ask what will be involved in the interview; how many people, how many stages, what sort of questions.
Normally companies are happy to release this information to help you prepare. Never forget that the people interviewing you want you to get the job. They want you to be the amazing developer they’ve been looking for and you need to prove to them it’s you.
This is the bread and butter of most interview processes and the main focus of this blog. A group of developers asking you a series of questions on java programming, algorithms, and design.
This is always going to be the most difficult part of any interview process. The domain space is so huge you could get asked anything, and some interviewers pride themselves on asking esoteric questions. However, most people aren’t like that and will limit themselves to a core set of questions.
In preparation for a Java interview, you have to make sure you’ve revised the core material. Even though you spend all day every day working in the code the fact is that most of the “complicated” parts of the language are infrequently used but regularly asked in interviews. At a minimum you need to revise the big three:
A natural extension on collections is to study algorithms as the questions will often revolve around writing an algorithm to sort a data structure. These two are covered later in the blog.
You are also quite likely to be asked about your design experience. One that seems to pop up regularly is “Tell me about something you’ve designed” or “tell me about the system you’re working on at the moment”. Normally you will be given a whiteboard and asked to sketch out the architecture and asked to explain as you go along.
This is a nice open-ended question and can give you a good opportunity to show off by engaging in discussions around technology choices and resilient design.
Finally, you are likely to get asked “fluffy” questions. A huge amount of being a developer has absolutely nothing to do with code. Development practices is a great example; I love to ask candidates about their experience with agile development for example.
It allows a clear delineation between people who just do what they’re told and people who take an active interest in the development practices and understand their purposes. There’s also the non-technical questions that fit into this section: “What excites you about going to work?” is another one of my favorites.
When answering these loose open-ended questions don’t feel the need to launch straight into an answer and blab your way through. It’s ok to take the time up front to think of a good answer. This is not the sort of information people keep ready in their heads and the interviewer knows that.
The Management Interview
After you’ve cleared the hurdles of the developer team you will normally end up in a room with a manager. This may be the team manager (who will likely still be technical to some degree) or it may be a department head (who is quite removed from the day to day). The likelihood is that this is going to focus heavily on the interpersonal fluffy questions.
The purpose of this interview is to get an understanding of your experience as part of a team, to figure out your potential as an employee and to determine if you will be a good fit for the team and the company.
There is no right answer to these questions and it will depend entirely on the values of the person interviewing you and the firm you’re interviewing with. Some firms are looking for people who can bring a breath of fresh air and stir things up, people to bring new ideas and mix things up.
Once when I was being interviewed by a head of development I spent a huge amount of time talking about the importance of continuous delivery and having build monitors as information radiators, all of which he had heard about but had never tried to implement. By showing I could bring some valuable new skills to the team he was exceptionally keen to hire me.
Conversely, a large proportion of the people who interview you will be looking for people who can slot in seamlessly with the team or company and hit the ground running.
If you know someone who’s already working there you can find out what “good” looks like to that team/company and tailor your answers accordingly, but most of the time you won’t know what your interviewer is specifically looking for.
Don’t worry about this, and don’t try and guess based on the intonation or questions asked. Just be honest and try to show where your expertise and passion lies. The simple reality is not everyone will fit in everywhere, and that’s ok. Just talk candidly about your experiences and opinions and try and strike up interesting conversations.
Be confident and outgoing. Even though the person you’re talking to is in management it’s no reason to get nervous. Think of the worst case scenario: you don’t get the job.
That’s ok. Most of your peers will struggle with this interview as it’s heavily focused on being able to give articulate answers and have interactive conversations.
If this is not your strong point then practice. Ask a friend (preferably not in IT) to drill you on these questions until you no longer sound nervous.
What do you enjoy about going to work?
What do you dislike about being a developer?
Why are you leaving your current job?
If you could change one thing about your current team what would it be?
What does a good team look like?
What makes a good developer?
Tell me about a time you had a conflict at work. How did you deal with it?
Tell me about the biggest mistake you made at work?
What are the technical tests?
Over the years I’ve tried many different types of ways of screening candidates; phone interview, speed dating style, full on the technical interview and everything in between. My favorite method by far is the technical test, also known as the coding homework.
The technical test is simply an exercise or set of exercises given for you to complete at home. Normally it will take one to two hours and will be reasonably challenging, involving some level of complexity such as Threading or algorithms. The instructions will likely be emailed to you, giving you a certain time frame within which to complete it.
Why are they good?
Most interview processes do not involve the candidate writing any code. This is crazy! You’re interviewing to be a programmer and most job interviews don’t involve you doing any programming. If you’re lucky enough to be in a process which does involve looking at your code there are 3 main options they could use:
Bring you in and watch your code. This could be a pair programming exercise or it could be simply sitting you in front of an exercise and watching your code.
I’m a big fan of the pair programming interview as a mechanism to use later on in the interview cycle to get a good understanding of how a programmer interacts with other people and designs their way through a solution.
Ask for a code sample. Less popular than it used to be, but the equivalent of asking a graphic designer for their portfolio. Most of the code people write is for their employer and cannot be exported outside the firm, so it relies on the hiree having personal projects to showcase.
I’d recommend if you do already have projects that you upload them to GitHub and include them on your CV: you look good for having the project and it shows you’re proud of your code.
The Technical Test!
The problem with a pairing interview is that it takes a lot of time out of the hirers day, often 2 people taking 2 hours per candidate. This is expensive, and so it is better saved to the end of the process. Code samples, on the other hand, aren’t standardized.
They give a view on what your code style is but are unlikely to answer all of the questions the interviewer has about your ability. It also means as an interviewer I need to get myself around a new problem space and code base for each and every candidate which takes a lot of time and effort.
Coding Homeworks, on the other hand, take relatively little time to review. They’re standardized, which makes the recruiting team's job easier and ensures candidates are compared on a level playing field.
The challenge can be written to ensure it tests whatever facets the company values; algorithms, threading, design etc.
Personally, I find them a great first or second stage interview to sort the wheat from the chaff and immediately filter out a huge number of candidates. A lot of people talk a big game on their CV but are terrible programmers.
However be wary of using this too early in the process if you’re putting a hiring process together. I’ve had a number of candidates refuse to do the interview when they’ve not even had a phone interview yet.
When asking a candidate to take 1 or 2 hours out to write code they will often want the opportunity to talk to you first so they can get more information on the role and make sure it’s worth their time.
On the other hand, I’ve also had candidates be extra excited for the role because it’s shown we value a candidates ability to code highly, a very desirable attribute.
How to pass
This may sound obvious, but a the very minimum you need to produce something that compiles, runs and solves the problem. I’ve reviewed far too many submissions where the code simply didn’t compile.
This is a straight no. Don’t expect the reviewer to spend a lot of time trying to get things working. Use a standard build tool like maven and include clear, step by step instructions in a readme file.
Ensure you read and follow the instructions to the letter. I once had someone submit a solution in Scala despite the instructions specifying Java. This just wastes everyone's time.
If you are at all unsure then ask. Chances are you won’t be the first person to have the issue, and if you are then they can amend their instructions for future candidates.
Your target should be to write code you would be happy to see go into production. At the highest level, I’m looking to see if the very best code you can produce (which is what this should be) is good enough that I’d be happy for you to commit to my codebase.
Clearly “good code” is a very personal opinion but if you submit something you’re proud of then that is the best you can do. If you don’t pass because of the code style you can rest assured that the team is not a good fit for you.
As an example; If I was rejected from a team because I didn’t comment my code I’d be glad I missed out because I believe that code should be written with good naming and broken down so that it’s clear what’s going on without comments (with the exception of APIs). Your code is a representation of what you value.
Some key things to check before you submit: - All methods, classes, tests, and variables are consistently named - Remove all commented out code.
Don’t leave the unused code in; a good IDE like IntelliJ will clearly highlight if a piece of code isn’t being referenced - Delete any unused classes or tests - Remove any main methods you wrote “just to test if something worked” - Remove all breakpoints! They show up if the reviewer uses the same IDE
Above and beyond this it simply comes down to creating a good solution that solves the problem. Read the question thoroughly and jot down what the concerns are. Is the problem latency sensitive?
Is there a large data volume? If a UI is involved is there a responsiveness concern? If you write a list of what’s important (and what’s not) it will give you a good guide when creating your solution so you can optimize the right things.
Do not prematurely optimize! If the solution asks you to read in a file of 10 lines, don’t write an incredible caching solution. It’s 10 lines!
Make sure to write tests. Tests are great anyway, but if you have tests written for the key requirements you can be sure that you’ve ticked them off whilst proving to the creator you’ve read, understood and coded for them.
Once you’ve finished, put your solution into whatever format requested (zip, GitHub, jar) along with your comprehensive readme and email it to another computer. If you have a spare laptop then great, if not then maybe a friend.
Try it out on here before you submit it; you want to ensure you avoid the issue of “Works On My Machine” where it looks fine on your laptop but works nowhere else because of some esoteric setting or an assumption you’ve made.
If you can send it to someone and they can get it up and running with no guidance then you’re good to go. Send it in and keep your fingers crossed!
Following the technical test
What comes next depends entirely on who is hiring you. Some people will give you a simple pass/fail with no feedback. In this scenario go back and ask for feedback anyway.
If you’ve failed then it can be comforting to know why so you can improve next time (or perhaps it was a style issue as mentioned, in which case you can rest in peace).
Even if you’ve passed it can be good to know any areas the team felt you could have improved on. This way you can allay these fears in the next round.
A common practice is to bring you in to discuss the code. I really like this as a concept. Often code cannot explain a design decision by itself and it can be a good platform for the hirer to understand how you think. Why did you model the domain like you did? Why did you use composition over inheritance?
Before the interview spends an hour looking over your code trying to think of questions and preparing answers. Saying “I don’t know” about why you crafted your code in a certain way does not look good. Design and implementation decisions should be deliberate. Some key questions I like to ask of candidates:
Why did/didn’t you make this final? Is this immutable?
Are there any threading issues here?
This code seems quite complicated. Why did you write it this way? Is there any way you could simplify it?
You’ve written comments here. Why?
Why did you choose ArrayList/LinkedList/Another thing?
Are there any third party libraries that could’ve helped you with this?
You’ve overridden equals/hashcode. Why? What changed as a result?
For anything where speed is a concern: Did you test this to see if it made a difference?
Remember, there is rarely a “right” answer. The questions are there to prompt a discussion and to see if you understand the concerns of each choice. Don’t feel the need to make stuff up or compromise because you think the interviewer is looking for a certain answer. Stick to your opinions and have a sensible discussion!
Tell me about your system
This is one of my absolute utmost favorite questions to ask during a face to face interview. Right now in your current role, you’ll be working on a system (maybe more than one), and you’ve put hours of your life into it.
You probably have a bunch of guys and girls you’ve worked with to put the system live and deliver some awesome value to someone.
This should be the one thing that you know really really well. Nonetheless, the number of candidates that get caught out by this question is incredible. You wouldn’t believe how much some people struggle with this.
Why are you getting asked this question?
For the interviewer, this is a great way to gauge a candidates experience. Some developers will often just use the technologies put in front of them and neither understand nor care why.
This should send up a big red flag. Being a java developer is about much more than knowing the syntax. You need to understand why systems are put together the way they are and what the pros and cons are. I expect this from candidates irrelevant of their experience.
It also doesn’t matter whether you were involved in architecting the system or not. You should be able to take a view on the decisions made, whether it’s positive or negative. Remember, the architecture of the system itself is not on trial; if you think it’s terrible then you can say as much.
Very few people get to work on true greenfield projects and build their solutions up from the start, and in reality, every system is going to have flaws; and that’s ok. The important thing is that you know the weaknesses in your system and you can explain how you would do things differently.
Take advantage of the opportunity
If you are lucky enough to get this question then seize the chance with both hands. More than any other part of an interview this gives you the opportunity to step up and show yourself as an excellent candidate. If you can crush it then you’re well on your way to a job offer.
Sit down with a pen and a piece of paper and draw your system out. If you think the system you’re working on currently isn’t interesting then use something else you’ve worked on in the past.
As a rule of thumb the interviewer shouldn’t care specifically about the project you’re working on right now, they just want you to talk them through a system.
Draw the relevant components. What languages are they written in and what technologies are frameworks used? Do you agree with those choices or do you wish there was something different?
Draw and label the communications between them. Does it use files? Bus? Sockets? Pigeons? Write it down. Now explain exactly why each thing does what it does. Why was it chosen?
It doesn’t matter whether you were involved in the decision, or if you agree with it. Explain the reasoning (or what you think the reasoning was), and outline if this is a good or a bad thing.
If you have a way you would prefer to do it, then say that as well. Most choices, in reality, boil down to some sort of nonfunctional requirement. “This is very latency sensitive so we chose this middleware to fit that requirement”. “The traders don’t really care so we made this a batch process as it’s easier to support”.
Your job with this questions is to show that you understand the requirements of each component and how that relates to the technology choices. Don’t forget that requirements are never purely functional. How do you support the application? What is the mean time to recovery? Is the system global or local? What happens if your datacenter floods?
This interview is fictional but should be representative of what you could expect in a real interview. Apply this sort of questions to your own system.
Can you please tell me about your system?
Sure. It takes a bunch of transaction data from downstream systems and stores it. It performs some complex transformation on it and makes it available for end users and further upstream systems to use.
Ok, could you draw it for me, please?
Sure. So, first of all, we have the importer. This slurps in the data from a bunch of our downstream systems which have information about orders and reporting in. It’s written in Java. It takes files once a day from 3 systems and also has the option to manually import data using some web screens we threw together.
Why did you choose to take files and not have a continuous update or something else?
Legacy reasons. These systems were built many years ago and there’s a reluctance to invest any money in them as they basically work. This limits us as we can’t create things like customer reports in real time, only once a day.
We are currently midway through a transformational project to allow real-time flows; although some systems will never be upgraded there are some brand new downstream that need to move onto our system and want a real-time interface.
That’s the bulk of my current job. The target state is to have a real-time flow of data so that the business can see the orders as soon as they’re put in.
I’ve put an HTTP interface in there to allow intraday updates as a tactical fix. That won’t cope with the data loads we’re targeting but we haven’t concluded how yet.
Ok, and is this system global?
Yes, we have an importer in New York and London. The systems in each are slightly different in each region so we’ve had to tweak the code slightly.
Do you have 1 code base then or multiple?
We used to have multiple code bases. It was a nightmare patching fixes across them so we’ve recently merged into a single GIT repo and we’ve added feature toggles based on each location. I really enjoyed learning GIT, it’s much better than SVN, and it was nice to put feature toggles into practice.
And what about failover? What happens if something goes down?
To be honest, it doesn’t happen very often, but until recently there was no failover. As it’s currently a batch system this has never been a problem but as we’re trying to move to real-time updates it means if we do get problems we get very angry users. As a result, we’ve started running 2 instances.
The second instance only exposes the real-time features though and doesn’t touch the batches. This is because we’d have had to introduce complex failover mechanics to stop 2 batches occurring. It’s a cost/risk analysis; if something goes wrong with batch it’s ok if it’s delayed for a bit whilst we fix it, which isn’t the case with real time.
Ok, so what does the importer do then?
It takes the files and updates and turns them into messages and puts them on our global bus. We have a bunch of components that need this data so hang it off this bus. It’s using IBMMQ: not my choice, it’s mandated by the company.
What would you rather use? Why choose a bus?
I’d rather use ActiveMQ. It’s much easier for testing and I’ve had a great experience with it when I’ve used it before. The bus was my idea. It removes a lot of issues with regards to failover.
Before we had a massive web of a point to point connections which were difficult to manage from a support perspective and meant that if a single component went down the system would collapse.
Having a bus breaks the tight coupling between components and has seen our overall stability increase significantly; we used to have 1 outage a month last year but since introducing this we’ve had no full blackouts.
Are there any issues using a bus?
It’s extra middleware which can be a nightmare to manage, particularly if you have a centralized team as we do. It also decreases the visibility of what’s going on. We had some problems with messages going missing and had to very quickly become experts at config tuning. I think overall it was a good choice though.
Do you know any other Bus technologies?
There are HornetQ and ZeroMQ. I’ve not had a chance to play with them but I hear HornetQ is really fast.
What format do you put on the wire?
We’re using XML. I wanted to use JSON but there was pushback from the upstream teams. JSON is much nicer, it’s more readable, it’s much less verbose and so smaller and quicker on the wire. However, the other teams are heavily invested in XML so we compromised.
Ok. What next?
We have a database that hangs off that records all the data imported onto the bus. We need a historical record of data so this stores it for up to 7 years. It’s a basic MySQL instance.
Why did you choose to hang it on the bus? Why not have it attached to the importer?
Couldn’t you have a case where the bus collapses and you’ll lose a message?
We make sure to log stuff as it comes through the importer so we can manually reconcile messages in a worst-case scenario. If we had to do a DB transaction every new record it would be really slow in the importer.
We felt it was best to decouple this completely. It also made failover easier, as the importers just need to worry about who’s publishing to the bus, and don’t need to mess around with database connections.
Some of our streams consume this raw feed, but for others, we have an enhanced feed. This transformer enriches the data with some information from a different database and puts it back onto the bus.
How quick is that?
Not very, it takes a few seconds. Right now that’s not a problem but as we move to real-time it needs to be fixed. I’d like to look at some near caching technologies for it.
We also have a set of user screens that feed the data. This talks directly to the transformer.
Why did you choose to directly connect it and not use the bus?
It’s another piece of legacy we haven’t gotten around to fixing. Ideally it would hang off the bus too but for now, it has a direct connection.
What connection are you using between them?
Plain sockets. We’ve got an embedded Netty server in the transformer. I’m a big fan of netty.
What about failover?
We run the Transformers in London only, but we run them hot warm. We have some basic heart beating on the bus so they know which is alive. If the heartbeats stop then the secondary takes over.
Have you had any issues with this? What about the split brain?
Yes, we’ve had split brain happen a couple of times. We were too aggressive with the heartbeat timeout so we’ve pushed that back. It’s an acceptable compromise if the transformer gets delayed for a few seconds during failover it’s ok.
You also can use this as an opportunity to express your knowledge of other technologies. In the interview, there are references to Netty, ZeroMQ, HornetQ, IBMMQ, ActiveMQ, Git, Feature Toggles, heart beating, XML vs JSON, MySQL and Oracle.
That’s a lot of technologies and design patterns. This is an effective way to show that you have a broad knowledge of your domain.
It’s impossible to know everything which is why when hiring it’s good to look for people who can introduce new ideas and technologies into the organisation. And if you don’t know any then spend the time to look on google. Type in “Alternatives to “ and the technology and you’ll have a ton of articles laying the arguments out for you.
15 Tips and Techniques for Interview
Time is a critical factor. It’s hard to know when to call a research task done because there’s always one more task that might give an incremental improvement. When doing reconnaissance, it can be even harder, because there’s no obvious point where additional effort returns less and less useful data.
Sometimes, when you’re researching you can get a few hours into a project and hit a wall, then a few hours after that find a piece of information that you can leverage into an entirely new round of research.
Other times, you hit a wall and that’s the end of it—additional work garners no worthwhile results. Still other times, you can find fascinating information that has no direct value to the task at hand but distracts you for hours. Because of this, it is wise to determine how much time to spend on each research task before you start.
Market Visual (www.marketvisual.com) can be used to search on a company name and a title and will give you a list of possible targets. A search on “executive Thesis Scientist” provides a nice list of potential candidates.
Market Visual, however, lists him as holding a shocking 257 jobs at 44 different companies in the course of his career. This is theoretically possible, but it seems somewhat unlikely.
Other hits from the same search indicate things like Strauss Zelnick with 216 roles at 65 firms, Lisa Hook with 138 roles at 35 firms, and Andrew Prozes with 104 roles in 30 firms.
The lesson here isn’t that some sites lie. This information could well be accurate. The lesson is that researching over 200 different jobs for a person with whom you may or may not interview is not an effective use of time.
Some data sets are cleaner than others, and the effort it takes to adjust data sets could often be better spent on other parts of the process. If you feel that you are spending too much time on a specific task, feel free to make a note to come back to it once you know more.
If the opportunity warrants deep research, do it, just remember how much time an activity is worth.
Jigsaw/SalesForce Data.com Connect
Jigsaw (jigsaw.com) is a tool that is often used by sales professionals and recruiters to identify people in specific roles in target companies. It can be used much like Market Visual but doesn’t go as deep.
Jigsaw uses a point system, where the more data you input into the system, the more you can get out. This can take some time; though, as a result, the data set is often cleaner.
Fortunately, when pursuing a job, you can find phone numbers fairly easily through Google or by calling an automated phone attendant, and it’s fairly easy to guess at email addresses. Jigsaw can help you with first and last names and titles, which is all you really need for targeting.
Uncovering Hidden Data
Now that you have a basic list, it’s time to dig deeper. There are two types of digging that you will need to do. The first involves gathering more information about the company.
This will involve mining the past and, if possible, projecting out into the future. The goal is to identify what challenges the business faces today, so you can position yourself to meet them tomorrow.
Along the way, you want to try to identify what has been tried in the past, so you don’t show up to the interview with tried and failed recommendations.
The second goal is to identify key information about the specific individuals who will be interviewing you. This is where the reconnaissance of individuals associated with a company will be important. The more complete your data and lists on these people, the better this part of the process will be.
When analyzing a company, you must constantly question whether you want to work there. At this point in the analysis, you have enough data to begin answering the question. You must also consider whether the company will want you to work there. This is by no means certain.
To gain a good job, you have to provide good value. This means that not only do they have to like you, but you also have to be able to show them that you can solve problems more cheaply or faster than anyone else they’ve interviewed. Gathering data is the first step to being able to do that, but decidedly not the last.
There’s more to the Internet than Facebook. Some people disclose information on older social networking sites such as MySpace and LiveJournal. If you can map them to niche sites, you can learn even more. This process can get technically tricky and can sometimes drift into getting more personal than you like.
If you can find a person’s username, often from a Facebook or Twitter search, you can then search on that username and start following them throughout the web. Since people tend to try to keep the same usernames on numerous websites, it’s fairly easy to develop a personal profile.
As an example, I chose the online name “guppiecat” as being globally unique a great many years ago. A search on that term uncovers the following online presences and many more:
This was a deliberate choice to boost SEO, but a significant amount of information can be found for people even if they are not attempting to improve their personal visibility.
Beware though—there are some things you may not wish to know about your future employer or coworkers. You may wish to avoid following links to sites referencing sexual content, such as FetLife. Depending on your own sensitivities, you may also wish to avoid political, religious, and news forums and other hot-button topics.
LittleSis (littlesis.org) is intended as a social whistleblowing site like WikiLeaks. Unlike WikiLeaks, this site focuses on personal interaction and tends to include data about politically active individuals, especially Americans and people with links to Americans.
If a person has an entry, you can expect to find a listing of political positions held, education and family relationships, important friends, and financial donations.
The “Interlocks” tab is one of the most interesting. This shows people who are connected to the target and how. It’s more transparent than sites like LinkedIn and easier to leverage.
Since most people on the site wield a fair amount of political power, they are harder to access, so the increased leverage may not get you much. However, if you are targeting a politically active individual, this can be a great way to find out what causes they support so you can alter your approach accordingly.
Alternatively, if you have strong objections to these causes, you may wish to stop your efforts involving this organization and find a new target that better meets your needs.
OpenSecrets.org and follow the money (www.followthemoney.org) are also political sites, but they track donations instead of power. Few people donate money in sufficient quantities to get listed, but if one of your targets does, it can tell you a lot about their political beliefs.
That said, there is a bias in favor of conservative organizations within the business, as such organizations tend to support taxation models that are more attractive to business owners. So a donation to a candidate may indicate a financial perspective rather than a social one.
Also, be aware that many donations are given under legal names, so when searching, be certain to convert any nicknames to full names and experiment with trying middle names and initials if they are known.
Often, it is easiest to search only on the target’s last name, then manually sort through the list to see if they are included. You can also search on the company’s name to see if the target organization itself has backed any candidates.
Social Mention (socialmention.com) attempts to track a target’s social activities. As with many data mining sites, the quality of the data returned will be highly erratic.
A search on the exact name is required, since otherwise, first and last names are searched individually. As with other searches, globally unique usernames tend to work better than more common names.
If your target has an active online video presence, this search will uncover highly useful information. However, for most hiring managers, the likelihood of that is low.
This site is included because as existing younger employees rise to positions of greater power, these sorts of niche social searches will become more useful.
The NNDB Mapper (mapper.nndb.com) provides graphical representations of the data stored in NNDB (nndb.com). This site serves as a repository for information about noteworthy individuals.
It is unlikely that the people who will be interviewing you will be sufficiently noteworthy to be listed, but it’s worth checking, just in case. This site can list different groups with which they are affiliated, as well as the types of links they have to those groups.
Entity Cube (entitycube.research.microsoft.com) is a project by Microsoft intended to improve the quality of search results for people rather than concepts.
It is a relatively new and highly experimental. Results vary day-to-day and sometimes stay static for quite a long time. Because it is a people-focused project with significant funding, it can sometimes return surprisingly useful results.
Wolfram Alpha (www.wolframalpha.com) is an attempt to reconceive how web searches are done. Its true power is in math and science searches; however, when searches are run against some companies or people, you can get very interesting
visualizations of the available public data. This is not likely to be useful for small companies or specific departments, but if you need additional information on large firms and general trends, the data returned can be quite useful.
Glassdoor (www.glassdoor.com) is basically a company review site. Just as you can get reviews of restaurants before you visit, at Glassdoor you can get reviews of organizations that tell you what it’s like to work there, whether the salaries are comparable, and, if you’re lucky, some of the interview questions asked.
Not all companies are reviewed on GlassDoor and, for those who are, you must always remember that there are bad reviews and there are bad reviewers.
Companies on sites such as this tend to attract a disproportionate number of bad reviewers because the people who are happy in their jobs are often too busy to write up a review of their experience.
Use Glassdoor to get some additional insight into your target organization, but remember that reviews are entirely subjective and that companies change over time. Older reviews should be given less credence.
Metaphor Mapping Adjusting to Your Target
Once you’ve found the people and have identified how they function within their organization, it’s time to figure out how they and their organizations think. The way organizations think of themselves metaphorically has been explored in great detail in Gareth Morgan’s excellent book Images of Organization.
Within the context of a job search, it is important to understand that the people with whom you are interviewing have their own concepts as to what they need and what you’d be doing.
These concepts are formed from several places, but at their core is the fact that metaphors are formed by, and in turn shape, the language used within an organization. Fundamentally, a metaphor can be thought of as one concept standing for another concept.
Thus, if you are interviewing at an organization that prizes speed over all else, you’ll see and hear language around things like workflow, downtime, delivery time, etc. Organizations focused on quality will discuss testing and best practices.
Organizations that think of themselves as organisms will talk about resource constraints and growth over time. Additionally, different departments will have their own metaphors. Industry metaphors abound.
The financial industries tend to discuss things in terms of growth and risk, and internal accounting groups adopt this language and way of thinking. Entrepreneurial fields also look at risk, but in a much more positive manner. Executives who come from entrepreneurial backgrounds tend to adopt this mode of thought.
Groups that work with customers tend to focus on internal and external pain and shy away from activities that could create pain. Thus, quality assurance and internal support groups will use metaphors of certainty and avoidance.
People also use metaphors of their generation, hobbies, and cultural backgrounds. Sports metaphors are particularly common in business, where phrases like “we don’t need a home run, we just need a lot of singles” and “move the project down the field” are common.
To maximize success, it is wise to understand how your targets think. Metaphors are one good way to do this.
Guessing at Metaphors
If you can’t find metaphors in active use, you’ll have to guess at them from stereotypes. Stereotyping can be dangerous but also quite useful. Just always keep in mind that you are stereotyping and could be wrong.
As mentioned before, industries have common metaphors. You probably know the metaphors of the industry you’re going into. It can also be useful to understand the metaphors used in the industries in which your targets have worked. For example, if you are pursuing a job in health care, you will encounter people using concepts like the following:
We have to keep the business healthy! (wellness)
We must protect our clients! (safety)
Buying our product is like a vaccine, it’ll keep bad things from happening later. (medicine)
If you are going after a job in the financial sector, you’ll see things like this:
It’s too risky to invest in that idea right now. (profit/loss)
This product will help you improve quarter to quarter! (reporting)
How will this affect our bottom line? (profit/loss)
You can often get a nice list of industry-specific metaphors by just doing a search on “<industry name> metaphors.” If this does not return an immediate list, look for interviews with leaders in that industry.
Go through the metaphor discovery process in the preceding section to find the common metaphors used in that industry. Go through each industry your probable interviewers have been active in, and spend some time thinking about how they have been trained to think.
The way you phrase your ideas must take these differences into account. Try practice interviews with older or younger friends or those people’s parents or children.
Explain to them what you want to do for your target company and ask them to repeat it back to you in their own words. If they have difficulty doing this, ask them to compare it to something.
Track how they do this. In general, younger people are more liberal, more familiar with technology, and more likely to reference consumer technology in their explanations.
They will use phrases like “help grow the company like Google and Facebook did” and “do something that can go viral.” Older people are more likely to use references to family, duty, and classic conservative values.
They will use phrases like “help the company refocus on what really matters” and “do things that people will talk about.”
Taking the time to understand what people have gone through, how they think about it, and what sorts of historical frameworks they use will help you connect with them.
Additionally, taking this one step further and trying to figure out how to communicate with them in their own language will shrink any generation gap and make your discussion far more successful.
Another rich source of metaphor is a hobby. People who knit, who play golf, or who do photography all have their own languages. Hobbies are listed on many social media platforms and are evident in interviews and photos.
It generally takes very little research to identify the things your targets like to do in their off-hours. While some executives’ primary hobby is making money, most people have one to three things about which they are passionate. Once you can identify that, you can start working with it.
Most hobbies give up their metaphorical secrets with a simple search on “<hobby> metaphors.” Others you may need to pick up on yourself. Fortunately, the Internet is a goldmine for this sort of thing. Watch “getting started” videos on YouTube and find online forums and mailing lists to read.
Learn a decent amount about the hobby so you can make a reference or two in your interview and portfolio material. If asked about it, say something like “I’ve really just started getting into it” or “It’s interesting, but I’ve never had the time to dive as deep as I’d like.” This will explain your lack of expertise without making it look like outright manipulation.
Of course, it’s always possible you might find it fun and get far more into it than you ever expected. There’s nothing wrong with this, but keep in mind that hobbies are intended to consume your time in an enjoyable manner.
Time spent on a hobby does not directly advance your goal of getting a new job. By all means, have your fun, but keep your ultimate goal in mind.
Rebottling the Genie
Though there is a general view in many HR departments that researching prospective employees via social media is to be avoided, an ongoing Career Builder survey run by Harris Interactive in early 2013 reports that many of them do.
In fact, between the 2012 and 2013 surveys, the number of hiring managers that do this sort of research increased by almost a fourth, with 43% of people admitting to rejecting candidates for several reasons, including:
Posting of inappropriate photos and information
Drug and alcohol use
Sharing of negative information about employers
Poor communication skills
Racist, sexist, and other negative comments
The same survey showed that positive information found from a similar search, ranging from professionalism to illustrating professional skills to showing a fuller picture of one’s personality, including creativity and outside interests, can make it more likely to receive an offer.
It is often stated that anything done on the Internet is there for all time. This is somewhat true. However, we do view the Internet through different lenses. Typically, we call these lenses “Google” and “Bing,” but there are others as well.
The most thorough way to purge unnecessary items from your Internet presence is to follow all of the steps for researching a prospective employer, but do it on all variations of your own name. Anything you find that makes you look like a poor employee should be removed.
Then, visit each of your social media and search platforms and review your privacy settings. While there are far too many to list here, a quick guide to URLs follows:
Odds are that you don’t want to make yourself completely invisible, even though most of these tools allow that. However, if there is a specific site that represents you in a less than positive light, you may wish to hide that one.
Since Facebook and Twitter are common sources of one’s poor choices being made obvious to others, there is a tool that allows you to scrub these profiles specifically.
SimpleWash (simplewa.sh) will scan your posts and alert you to any that you may wish to delete or alter. Like all such scanning tools, you shouldn’t completely rely on its accuracy, but it’s a good check to make sure that you caught everything.
Loading Social Media
If you don’t, create one at Google or WordPress under your real name. That will make it nicely searchable. Then, write three to five blog posts, each targeting an issue that you wish to have come up during the interview.
Be sure to proof each post before you hit “submit,” as once it’s up, it’s out there and will be cached in numerous search engines. If you wish, you can backdate some posts to make it look like you’ve been an expert longer than you truly have.
If you do this, though, be sure to do it at the time of creation; otherwise, search engines may show that you’ve adjusted the dates to make yourself seem more of an expert.
If you think there’s a chance that you’ll be caught, and you’re applying to an organization that is particularly touchy about such things (government and military), it’s best not to try that technique.
You can do also manage your profile at microblogging sites like Twitter. Find others in your field and start replying to their posts—but only if you can add to the discussion.
A good metric that employers use when looking at people on Twitter is the broadcast-to-discussion ratio. There should be at least the same number of discussion posts as there are initial posts. Hopefully, you’ll get some good discussions going and the ratio will be much higher than this.
As you create and communicate on social media, you’ll become more aware of the issues you are discussing. If you choose issues that interest your targets, you’ll become more aware of what drives them.
This will help you to be more interested in the interview but also will make you look better in their preliminary checks against you.
Most importantly, it allows you to refer interviewers towards something that drives them towards you. If they haven’t checked you out, try to lead the discussion towards something you blogged about. Then, in your follow-up letter, you can refer to your blog and try to increase their interest in you.
Determining Recent Finances
A successful organization will be more likely to hire you than one that is facing financial challenges. It can, however, be difficult to determine where your target organization sits.
If it’s a public company, you can look at stock performance on sites like Google Finance (www.google.com/finance) and Yahoo Finance (finance.yahoo.com).
You can also review recent documents from the SEC filings site (www.secinfo.com), though this may primarily be useful for US-based firms.
If the organization is a private company, you may wish to know what former employees have to say. Be careful, though. Some industries (governmental and military, for example) may consider this approach to cross an ethical line.
If you decide to do this, though, you can easily use the LinkedIn search techniques discussed elsewhere in this book, identify employees who left the organization in the last two years, then contact them.
Use short, to-the-point emails. Just ask them what it was like to work there if they think it would be worth applying, and whether or not the organization’s financial position is strong.
Just go onto LinkedIn and start doing searches on common keywords to find someone worth talking to. Then look at your link map and ask whoever links you to them to set up an informational interview with them.
This interview is not for a job but to help you understand what sort of things you need to be thinking about going into the interview you want to have. Many people in senior positions will gladly take an hour from their day to go out to lunch and discuss themselves and their needs.
By reviewing how Home, About, and Contact pages change, you can get a feeling for what has been important to an organization over time. For example, in the first Syngress archive, back in 1998, the company focused on publishing networking books.
As time went by, the focus moved to test preparation, then to security—and eventually, it was acquired by Elsevier, which focuses more generally on scientific knowledge, of which security is a component.
Discovering the Future
While it is not possible to foresee the future with anything close to accuracy, you do not need high levels of accuracy to land a job. The point of looking toward the future is to understand enough about the challenges facing your target to start coming up with solutions.
No one expects you to be able to actually implement them before you’ve worked at your target organization for a while, but the fact that you’ve put thought into the process will set you apart from other applicants.
Some guesses about what the organization is planning can be surmised from press releases and trends seen in the timeline. What direction is the organization moving? Is it focusing more on customers or on investors?
Is it trying to move faster or is it shedding unnecessary work and refocusing on the core business? Is the primary market full?
If so, is it trying to branch into new markets or trying to take over market share from other companies? If it’s a public company, how has the stock been doing? How has the stock of its competitors performed?
Nonfinancial benefits include less-tangible things. Educational options, such as a certain amount of money made available for college classes, conferences, or training, can be extremely beneficial, but only if you qualify for and use them. This money can be used to gain degrees or certifications and, ideally, to sustain them.
When working this into your total compensation calculation, consider how much you would actually use on a yearly basis. After all, not everyone has the time in their personal lives to take full advantage of courses. If you want to negotiate for more, do so by all means, but only if truly you plan to take advantage of it.
Time off is another benefit to consider. Many different models exist, from a simple paid time off (PTO) model in which an employee accumulates days off at a certain rate, to highly complex systems that combine personal days, vacation days, and sick days. In general, calculate your days off at your daily rate and add them to your base salary.
For example, if you are going for a $50,000/year job with two weeks of vacation, that indicates that each day is worth $192.31 ($50,000 divided by 52 weeks, divided by five work days in each week).
Thus, your two weeks of paid vacation is worth $1,923.10 ($192.31 times two weeks times five days per week). This sets your base salary at $51,923.10, at least for comparison purposes.
This way, the complexities involved in time roll over and converting between sick and personal time all go away, as all time is represented as dollars.
When it comes time to negotiate, you can find a lot of flexibility in terms of days off. Using days off as a negotiation point can allow you to devote entire weeks to advancing your work life (after all, you did just make them create a job for you, so you’d better deliver) with the certainty that you’ll be able to take time for yourself at some point in the future.
One other common benefit, at least in the US, is that of health benefits. Different organizations have different plans that vary by employee share, employer share, co-pays, dental, eye, etc.
It’s easy to compare plans based on total features, but it’s much harder to evaluate them based on which features you are likely to use.
Since insurance is a hedge against future losses, and you don’t know the future, some guesswork is required. Also, health benefits are often non-negotiable, as they are a group purchase. Just factor them into your total compensation plan and decide if you can live under such a health plan.
Common Job Titles
Having trouble coming up with a job title for a position you plan on opening? Here are some of the ones I’ve hired, interacted with, or even applied for over the years:
Application Support Analyst
Chief Information Officer (CIO)
Chief Technology Officer (CTO)
Cloud Product and Project Manager
Cloud Services Developer
Cloud Software and Network Engineer
Cloud System Administrator
Cloud System Engineer
Computer and Information Research Scientist
Computer and Information Systems Manager
Computer Network Architect
Computer Systems Analyst
Computer Systems Manager
Customer Support Administrator
Customer Support Specialist
Data Center Support Specialist
Data Quality Manager
Desktop Support Manager
Desktop Support Specialist
Director of Technology
Help Desk Specialist
Help Desk Technician
IT Support Manager
IT Support Specialist
IT Systems Administrator
Junior Software Engineer
Management Information Systems Director
Network and Computer Systems Administrator
Network Systems Administrator
Professional Services Engineer
Senior Applications Engineer
Senior Database Administrator
Senior Network Architect
Senior Network Engineer
Senior Network System Administrator
Senior Programmer Analyst
Senior Security Specialist
Senior Software Engineer
Senior Support Specialist
Senior System Administrator
Senior System Analyst
Senior System Architect
Senior System Designer
Senior Systems Analyst
Senior Systems Software Engineer
Senior Web Administrator
Senior Web Developer
Software Quality Assurance Analyst
Systems Software Engineer
Technical Operations Officer
Technical Support Engineer
Technical Support Specialist
User Experience Programmer