Archive for the ‘Interview Advice’ Category

Today’s article is a guest post from CJIQ fan Zac Morris. Whilst reading my book he emailed me about my section on interview technique, and specifically about being confident and outgoing with your interviewers as often candidates can appear hostile either intentionally or unintentionally.

Zac is on the autistic spectrum and correctly felt that my articles didn’t take into account what interviews and the process is like for someone with autism. I think it’s something that isn’t spoken about enough and I felt it was best for Zac to do a post to talk about the situation in his own words.

I discovered Sam through his blog post: “Why I hate Spring”; something I reference when discussing Java frameworks with people. I recently purchased his eBook: “JAVA INTERVIEW BOOTCAMP”, which has been an extraordinary resource. When I purchased the eBook, I was signed up for a matching email subscription, which is why I received the email below…

In Sam’s book, “JAVA INTERVIEW BOOTCAMP”, several elements in the Soft Skills and Interview sections rubbed me the wrong way, but when taken as a whole, the positives outweighed any negatives. Unfortunately, when I received this email it brought up some of those feelings of being rubbed the wrong way.

I had never interacted with Sam; I didn’t even know if he was actually involved in the creation of this email, or if it was part of a marketing company, but I decided to take a chance with a very basic response:

It’s absolutely not an extrovert thing and I should specifically cover that. My main point was that a surprising number of candidates are actively hostile/ it’s not because they’re introvert, usually the opposite.

Introvert candidates are great (and very common). If someone’s quiet because of nerves you can tell straight away and it’s the interviewers job to make them feel more comfortable and work with them to get the best idea of what they would be like to work with.

Let me know if you have any other Thoughts or questions,

S

While I really appreciated the response, I still felt Sam was missing my point…

You see, I am on the autistic spectrum (“Ultraviolet”/Highly Functional), which can result in me being overwhelmed by certain situations. ​ At 48, I’m very practiced at coping at a professional level. I have approximately 30 years of work experience, 26 of those with fortune 500 companies; my last non-contract position was 15 years with Cisco Systems, working full time remotely from home.

I decided back in September 2014 that it was time for something different, and having never had much trouble finding work, I gave my notice and decided to take a few months off for some personal projects. Unfortunately, between working from home all those years and taking time off, I’m finding my coping skills to be a bit rusty. On top of that, I’m running into more challenges, even downright roadblocks, in the marketplace than I expected.

Ten years ago, things like the ADA (Americans with Disabilities Act) would have been a tool to help people like me by mandating “reasonable accommodations” in the workplace, but today, to get around this requirement, companies have specifically instituted two hiring design patterns: temp-to-hire and building a “culture” around the OpenOffice philosophy. The first means that because you are not an actual employee, they aren’t required to make reasonable accommodations, and the second means that providing someone with a private/quiet workspace is considered an unreasonable accommodation, because it would be counter to their OpenOffice culture. I’m finding very little awareness, much less understanding, by employers and their interviewers of what a serious problem this can represent for someone like me. Yeah, that’s my cross to bear, but when I got Sam’s email, I felt a bit defensive.

I would like to challenge you; just because you may actually be pretty good at identifying an Introvert from an Extrovert, you should never assume that skill is absolute. You have no real idea what that person getting off the elevator may have gone through to get to that point in space and time.

I then went on to relate an elevator story of my own:

Recently I went to a job interview in a building that had a very strange elevator system. It had a bank of elevators and two digital touchscreen keypads. You had to punch in your floor number, then it would tell you which lettered elevator would take you to your floor. Having never experienced this type of system, I did not know this, so I stepped into the first elevator that opened and there were no buttons. Another person on the elevator saw my dilemma and said, “You enter your floor on the keypad outside”. So I stepped out, and I see the digital pad which is laid out like a phone style number-pad [1-3, 4-6, 7-9, #0*]. My appointment was on the 11th floor. Hindsight being 20/20 I should have used it as a number entry pad, but that’s not typically the way that an elevator system is laid out (and in my defense I wasn’t even sure if the building had more than 9 floors). So I had to go ask the security guard how to get to the eleventh floor. He laughed and said that I just hit the “1” button twice. Now I have an IQ of 159, so on top of the embarrassment of being laughed at, this simple thing made me feel quite stupid, not something you want to feel right before a job interview. By the time I got to the correct floor, I was a minute late, quite overwhelmed, and I was immediately lead into a conference room where two people were already waiting on me.

I went on…

Yeah, I get it, the world isn’t fair, but as someone that is billing themselves as a self-help author, you have a higher responsibility to show multiple sides to every story (interviewer and interviewee). You could have expanded your “Be guy #2” with something to that effect, instead it came off as judgmental vs. helping people realize that an interview is a kind of show, and the two absolutes of any show are: “The show must go on”, and “As an actor in a show, you have a part to play”.

Like I said, I’m decent at coping, so even after my own elevator experience I was able to turn on the “interviewee persona”, but others with my condition might not be so practiced, or (and here’s the important bit) even know that it’s something they even need to practice.

It is all part of what I believe to be de facto expectations of extrovert-styled normative behaviors used to define professionalism. I get it, expectations are expectations, but for someone like me, the discussion of soft skills in the interview process would be much more helpful/productive framed in the idea of an interview being like a show in which there are roles to play, otherwise it just feels like a judgment of who/how I really am. To some that may sound like simple semantics, but for people like me, it is a very important semantic!

This is a brilliant email and you’re 100% right. This is something out of my area of experience and I imagine that’s the case for most people who are recruiting. […] I’d love for you to flesh this email out into a blog post which I could use on CJIQ. I think stories like yours are unknown to most recruiting people and you could really help a lot of people on both sides of the fence.

So here we are. I really do hope that this post can help people on both sides of the fence: help interviewees like me better understand the expectations of employers and interviewers and how it’s possible to learn skills in interviewing without compromising who/how you are; and help employers and interviewers better understand that they can’t assume that they know someone’s story based on a few words said (or not said) when getting off an elevator.

My post on creating a Java developer resume (which you can read here) has proven to be one of the sites most popular. I’ve been even more impressed by the number of people following through to the links regarding online resumes. This is clearly something are interested in, as they should be. The vast majority of firms do online research on candidates now, and a lack of online presence can be a warning sign. On the positive side, including a link to your online resume on your paper CV can ensure that people always see the latest version of your CV, and you can use this to direct them to your other sites online. It’s also much easier to bookmark a candidate for later than to file the CV away where it will inevitably get lost.

As a result I wanted to put together this step by step tutorial to getting your online CV up. It’s often difficult to know where to start which means people are paralysed into inaction. Below lays out everything you need to do to get your CV online in under 10 minutes. You have 10 minutes right?

I have created the videos to guide you through, but the full instructions are listed below too.

Part One: Buying your domain

You need a domain to point people at which has your CV. Fortunately this is really easy to do. If you can get yourname.com then that’s perfect, but if not there’s some other great domain endings geeks use, particularly .me and .io. For this example I went for samatkinson.me.

You need to buy your domain and hosting from somewhere. There are tons of options at various price points out there. I use A Small Orange for every single one of my sites. They’re consistently rated as one of the best providers in online polls (such as this lifehacker one). The big thing for me is the support; if I have any issues, from breaking one of my code templates to having issues setting something up they have 24/7 chat support with no waiting times. I can’t recommend it enough. There are other hosting providers available though and it’s completely your choice.

Enter the domain that you’re looking for; for me that was samatkinson.me. This will search for that domain and similar domains.

If your domain is available then select it, else play around with other options. If you’re really struggling, pop your name into Domainr which will help you come up with some innovative domain ideas.

On the next screen you can just pass straight through. We’re leaving the nameservers pointing at ASO as we will buy our hosting from them too. ID Protection will hide your details on places like whois. It’s expensive but for the privacy conscious it’s a good idea.

This will take you through to your cart. But we’re not done just yet, as we need to add hosting. A website has to be hosted on a server somewhere. Fortunately this is very cheap! Click on “Add another product” on the right.

This will take you to the hosting options. For an online CV you only need a very small amount of space so the “tiny” option will be sufficient. If you select small or above you will be able to use multiple domains with the same hosting which can be quite cost efficient.

On the next screen we want this hosting to be used with our domain, so we can just click next.

Skip straight pass the next two screens unless you want one of the add ons. I never select these.

And now you’re done! Checkout with your details and make sure to write down your login details.

Bonus! Get 15% off at the checkout using coupon code “aE1yQ”

Part 2: Uploading your template

The obvious question at this point is “What template?”. You have three options

Write it yourself: Not recommended! It’s a lot of effort and, based on some I’ve seen in the past, it probably won’t look great.

Use the CJIQ template: As a bonus for every reader of Java Interview Bootcamp they receive an exclusive resume template. This too is based on bootstrap. This is what I used in the tutorial and video, but the instructions are EXACTLY the same as the free template above.

From the ASO homepage, select “Support and Account Center” from the top right and login.

On the next screen you will see “Your Services”. This is your hosting which we need to log into. Select it, then “View Details”.

If you don’t know your cPanel login then you can select “Change Password” to set a new one. Else, head straight to “Login to cPanel”. This will take us to our control panel where we can get the details for uploading our resume.

Enter your login details which will take you to the cPanel. There is a ton of stuff here we can ignore. We want FTP. FTP is file transfer protocol, which allows us to upload files to our hosting. In the “find functions” box, type “FTP”.

Select FTP Accounts. On the accounts page scroll down to the “FTP Accounts” header. You will find your FTP account here. Click “Configure FTP client”. This will give us the configuration to allow us to upload our template.

You will now be presented with configuration files for a number of FTP clients. An FTP client is a piece of software you can download which will handle file upload. I’m a huge fan of Cyberduck, which is available for Windows and Mac and is completely free. You can download it from https://cyberduck.io/. Once you’ve done that, download the Cyberduck configuration and doubleclick the file that is downloaded.

Cyberduck will now open. Enter the login details for your FTP account; the address you selected from the FTP accounts list (e.g.something@yourdomain.com) and the password (which you can change on the FTP accounts page).

Make sure the username includes the FULL account, not just the bit before the @symbol.

Once you’re logged in you’ll be shown everything that’s in your domain. This is normally just a cgi-bin folder. We can now upload anything to our domain by dragging and dropping it in.

Unzip your resume template which you have downloaded. We want index.html to be in the space cyberduck is showing you. Go inside the folder your index.html sits in and select everything (cmd+a or ctrl+a for windows). Drag and drop the files into cyberduck.

The files will upload to the server. When it’s complete, your website will be live! Congratulations!

You only get one opportunity for a first impression. From then on in 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 difficult interview even harder. On the other hand if you arrive and instantly 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 first impression.When those pages land on someones desk it is the first time they have been exposed to you and what you stand for. Interviewers literally 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 fo me this happens 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 are going to have differing opinions on what makes a good developer.If there was a standardised 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 google nearby and I believe people have a tendency to prematurely optimise code; real performance problems happen very rarely.That means there are interviews where I come out and know I have done terribly, and I don’t care. I’m comfortable knowing I don’t want to work for them 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 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 bullet proof 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.

Java Developer Resume Format

How long should it be?

This is the source of much debate.My view is vehemently that if possible, it should be one page (with an absolute maximum of two).People don’t have time to read resumes in details 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 communitcate 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 of 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.

Opening blurb

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.

However, 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? I can guarantee the person reading your CV won’t know.If someone asked you during thte 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 skim the rest. Get this section right and put your most impressive material first.

Employment history

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 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. are 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. So 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 personally 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!

Extra curricular activities

If you’ve done stuff in the company which is extra to your day job, absolutely 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 courses or training that you think is pertinent then put it down. If you’ve pioneered or innovated new things then put it in. Maybe you introduced the department to continuous integration. Perhaps you organised for guest speakers to come and speak to the team or you’ve organised for teams to do presentations to each other in a weekly forum.It’s this kind of extra work that can make you a stand out candidate in a competitive marketplace.

Education

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.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 come with a list of every technology the candidate has ever touched.Some CVs even have scores 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 as I covered in my article on phone interviews, 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 then don’t list it!

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 then 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.Most day jobs limit the tech we can use; if you then go home and play with NoSQL or node.js then putting this on your resume shows you have 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.

If you really want to stand out then build an online CV.These have become very trendy recently and are a great way to ensure you’re giving out the most up to date information in an attractive format.There are a couple of options for this.You could create your own site; there’s some great free templates such as http://www.bootstrapzero.com/bootstrap-template/responsive-developer which you can quickly throw up .Alternatively there are websites such as https://www.visualcv.com/and http://vizualize.me/ to create attractive and interactive online CVs quickly and easily. If you go for one of these options, put a line at the top of your CV which says “For the most up to date version of my CV, head to http://blah.co”. You may not get a ton of hits, but those that click through will likely be impressed.

Hopefully you’re now comfortable putting an awesome CV together. However if you’re still unsure and need some feedback on your CV, email it to hello@corejavainterviewquestions.com and I’ll gladly take a look. I promise to reply to all emails.

Whilst looking through twitter yesterday I came across an article on JavaWorld: “6 ways to nail the job interview”. In it, Doug Mitchell (the CEO of Argenta Field Solutions. Nope, me neither) dissects how “Gen-Y candidates, though tech savvy and digitally plugged-in, didn’t seem to have a clue about how to dress for, prepare for or conduct themselves in an interview”.

Take a few minutes to read the article. Go on, I’ll wait. Done? Good. Now forget everything that it said. This is the sort of article that really annoys me because it’s just plain dangerous. The fact that the term “Gen-Y” is used should be an instant red flag translating to “old person who doesn’t know what they’re talking about”. Developers (particularly the top up and coming talent such as the readers of CJIQ) are not like most people, and their interviews are not like most interviews. Getting the big CEO to give the stamp of approval may make him feel better but it’s a terrible move for a company. If the guy or girl can come in and code up a storm, and the tech lead is happy with their fit, then that should be an instant approval.

Tech lead: “So can we hire him?”

CEO, reclining, smoking cigar: “Sorry, I rejected him”

Tech lead: “Why? He was an amazing programmer, he paired well with the guys and he’s got tons of great ideas that are going to help us!”

CEO: “He didn’t wear a suit and he didn’t know anything about the company so I showed him the door. Kids today! starts ranting something about all this social media nonsense“

Do you realise how ridiculous this is?! Great developers are incredibly hard to find and we now live in a world where flexible working and office casual dress code exists. Companies (and CEOs) need to adapt to this changing nature or get left far behind.

Let’s look at each of the 6 ways discussed:

1. Dress for the role you want: With this I technically agree. You don’t want a role where you have to wear a suit. Have you seen developers in suits? The suit never fits and they end up looking like a kid going to a funeral. Interviews are stressful enough without dressing like a clown. Trousers and a shirt are absolutely fine. Don’t do the top button up either. No tie! I’ve actually had people rock up in jeans before, and that’s ok (albeit a little risky; stick with trousers if you can). I understand you’ve got a busy life and, if you’re really good, then what you wear really doesn’t matter.

2. Leave slang and dialect at the door: “Keep it professional, formal and polite” says our new friend Doug. What a great way to build rapport with your new team and company! Don’t get me wrong, saying “yo dawg” is a big no, but that’s just good life advice. You’ll quickly get a measure of your interviewer but most will be trying to understand if you will make a good fit on the team or not. Be friendly and open and try to work with them on a personal level. You want the interviewer to leave and say “I really like that person”.

3. Bring printed copies of your resume: Seriously? If the company looking to hire you can’t make the time to hit the print button before they come to an interview when you’ve taken time out of your day to come to their office for and to spend time preparing for then screw them. They’re not worth your time. Companies need to treat candidates with respect.

4. Become an expert in the company: Candidates interview for tons of companies. I do not expect you to become a master of mine. If you’re getting towards the final stages, or maybe it’s with a smaller company, then it can’t hurt to take the time to have a look on wikipedia or the corporate website. That’s just a good idea so you can understand if you want to work there or if you’ll find it interesting. But as a way to judge a candidate in an interview? That’s just the CEO massaging his own ego. No other employees care.

I also enjoy how this part encourages small talk. But obviously, professional, formal and polite small talk. But don’t take it overboard! Nothing worse than building a really good relationship with the interviewer.

5. Never badmouth your previous employers: Partial credit for this one. The thing is, you’re leaving your current firm for a reason, and that reason isn’t going to be rainbows and kittens. Chances are you’re not happy with something there, and the interviewer wants to know that. You then both know what you expect from the next role and can be sure you’re a fit. It’s even fine to highlight flaws of your old team or company during the interview, as if it’s constructive then you’re clearly demonstrating you know what good looks like and what you want from your new role. I would probably avoid a 5 minute tirade against your former firm though.

6. Ask about the next steps: 1 point! Absolutely ask about the next steps. It shows you’re keen and want to continue onwards and it means you’ll know the timeframes before you get your next answer. One out of 6 ain’t bad eh?

Alas I fear that articles like this will result in hoards of polite developers in ill fitting suits arriving to interviews everywhere. Hopefully if you’re reading this you’ll know better, and that’s going to get you the job.

Sam’s Note: This is a guest post by one of the smartest people I know, the amazing Jim. It’s a brilliant read and I hope you enjoy it as much as I did.

Jim Bennett is an international C# geek who has spent time hanging around in finance and startups for the past 15 years in 3 different continents. When he’s not writing desktop WPF apps for large banking clients he’s building mobile apps using Xamarin, blogging and being amazed that his 2 year old is better on his iPad than he is.

He doesn’t like pina coladas or walks in the rain, but does like beer and thai food and will happily talk tech whilst you buy him either (or preferably both).

Let me start by saying I LOVE technical tests. To me they are the most important weapon in the interviewers arsenal. Asking text book style questions or scribbling on a whiteboard is all well and good but when you are employing a coder you really need to see how well they code. It’s no different to employing a wedding photographer or an architect – you want to see how well they can actually do the job by looking at their work before you commit.

So what do I mean by a technical test?

What I am referring to here is giving the candidate a problem that they can code in their own time and their own style. It should be in the main programming language that you need from them (or a choice if you are employing for a polyglot or trainee role) and should be related to the domain you are working in. The instructions to them should be simple and concise but otherwise they should be left to solve the problem their own way. Remember, the aim here is to allow the candidate to show what they can do, give them a chance to shine.

Before I give an example, I must start by saying that my background is not in Java. I’ve been a C# developer for many years mainly doing front end development for the finance industry, so the bulk of the tests I have created in the past have all been UI based. The example I will be using is from a C#/WPF technical test I would give to front end application developers, but the basic principles can be applied to any test.

The test I have given in the past is to build an order blotter. This is a data grid based application that shows rows of data that correspond to orders from clients to buy or sell shares. These blotters would show the symbol for the shares being traded (e.g. MSFT for Microsoft), if they are to be bought or sold, the amount to buy or sell and the current market prices. The order information would update only when the shares are actually traded, but the prices update regularly – sometimes many times a second.

The candidate is provided with a library that publishes order information with constantly changing prices and is asked to create this blotter application to show these orders and provide live updates of the prices. They are also asked to support submission of an order through the given library by creating a simple dialog to enter the order information. The candidate is asked to support unit testing and ensure the application is responsive. These last two statements are left deliberately vague as the candidate should be aware of the standard patterns and practices that would be used to support these. Other than that they are free to code how they see fit.

As an interviewer what I am looking for in their solution is:

Good, clean, well structured code.

Use of standard design patterns – especially good separation of concerns to allow unit testing

Appropriate naming of classes, methods and properties to provide self-documenting code as far as possible.

Something that works – delivery is one of the most important features of software so the app needs to work just by getting the code, building it and running it.

A reasonable looking UI. In the timescales given there isn’t time for full user experience analysis but there should be basic attention to detail like labels, input controls and buttons lining up.

I also like to add a small gotcha. In this test my gotcha was a 5 second pause when submitting an order. As a UI based test responsiveness is an important feature. If you make the call from the UI thread the app will lock for 5 seconds which is a very bad thing. Any programmer who doesn’t care about this lock up or, even worse, doesn’t notice is not a good UI programmer and is an instant fail.

How should I go about creating a test?

The ideal test should be designed to find the kind of developer you need to do the job that you are employing for. If you are looking for a web developer then it should obviously be web based, if you are looking for a front end developer then it should be UI based to show both coding and UI/UX skills, for a real time code developer it should be something with a performance consideration. You could even do the test given in the example above as a command line app in Java to test back end developers. It should also be simple to explain, with you providing everything needed except the computer and development environment.

It should also be short. You are asking a candidate to fit a few hours into their schedule around their current job, family and other commitments. Your timescales for them to deliver their solution should also be long enough to give them time to complete without feeling rushed. If you give them an 8 hour test and 1 day to do it in when they are at work then don’t be surprised if no-one wants to do it. I find a 2-3 hour test with a week to do it (allowing for a whole weekend, with more time for existing commitments such as a holiday) is about right.

Most importantly, you should do the test yourself. So should other members of your team. This allows you to ensure the instructions are clear, everything is provided and the timescale is sufficient. If it takes you 8 hours to deliver a solution you can’t expect a candidate to do it in 2.

You should also be available to answer questions on the test once the candidate is working on it. Not dumb questions that show that the candidate is not up to scratch, but if they ask for a clarification on a requirement then you should provide answers – especially if their first language is not the one that you’ve used to write the requirements.

Assessing the test

You’ve designed the test, made sure it’s doable in the timescale given and sent it to your first candidate. A week later you get the solution back. How do you then asses it?

The first and simplest assessment is: does it work? Getting the test back to you can be hard – if any required binaries are included they might get blocked by corporate email scanners so you have to be very flexible about receiving the code. One of the best ways is to use a private Github repo that you share with the candidate (assuming your company allows Github access, some are very strict). But once you have all the code you should be able to do a one click build and run. Anything more complicated (such as updating packages from a public repo) is fine as long as the candidate has documented this and it seems logical. If it doesn’t build, doesn’t run or compiles with too many unacceptable warnings then it’s an instant fail. I know this sounds hard but if the candidate can’t create a working simple program then this is a big red flag. This is the chance for a candidate to sell themselves by showing what they can do – if they can’t so something that works in a situation this important then it’s unlikely they would be bothered to do a good job when they are actually hired. I know of at least one manager who ignored a test that didn’t build and was badly coded and was talked into employing the candidate anyway by a recruitment agent – and the candidate turned out to be a really bad developer.

The second thing I look for is this: does it fulfil all the requirements? Being able to take requirements and convert them to code is an important part of software development, so their program must fulfil every requirement. You will need to be flexible on interpretation. As mentioned above you should be available for questions but in some cases candidates don’t like asking questions or don’t think that they can ask. This means that they may interpret something a different way. Any major requirement misses then I fail the candidate.

Once I am happy with the delivery side, I then look at the code starting with the class or file structure – is it logical and well named? I then dig into the code. Does it use the right design patterns, is it easy to read (allowing for language issues), is it testable and does it have tests? Essentially, would I allow this code into my repository and release it to production. Remember though that this is only a short test so you have to make some allowances such as only having a small amount of test coverage to illustrate that the code is testable rather than spending time doing full coverage. You also need to be flexible with style – for example I hate one true brace (putting the opening brace on the same line as the for loop/if statement etc.) but would never fail a candidate for using it.

If the code is all good then I would invite the candidate for a short interview, either in person or over the phone to discuss the test. What I would be looking for here is for the candidate to prove they actually wrote the code instead of outsourcing it (yes, it does happen). This would be a simple discussion, get them to explain the code structure, what code does what requirement, discuss the patterns used and demo the functionality including how it matches the requirements. Some places insist they do the test on-site to ensure they write the code themselves, but I prefer at home with a follow up discussion. On site means a number of hours out of their work day and if a candidate is interviewing at a number of places they may not have enough holiday for all the tests. On site also can make candidates nervous, exam style nerves can impact their performance and not let them show their best work. On site also means using a company provided computer which may have different developer tools to what the candidate is used to. This can have a negative impact on productivity which becomes a major problem when you only have a couple of hours to do the test. For example as a C# programmer I am used to Resharper so if I had Visual Studio without it I would be like a fish out of water and this would impact my productivity. This would be the same for Java programmers used to IntelliJ who had to use Eclipse.

If the code is bad I would provide constructive feedback to the candidate along with the rejection. Everyone should be given the chance to learn and grow as a programmer and if there is any way we can help weaker programmers get better then we should do it.

How does this test fit into the interview process?

I like to do this test at the very start of the interview process. My normal flow is to get a stack of CV’s via recruiters or adverts, wade through them looking for relevant experience (and ignoring their style, some people just can’t write CV’s but are great programmers). If they tick all the boxes for what I am looking for I send them the test. If they refuse to do the test then it’s into the bin with their CV. If they don’t have the resources to do the test (such as not having a computer) then again into the bin – software developers who do it as a job with no passion outside of work are not in my experience the best performers.

Once I get their test solution back and do the follow up chat then it’s on to the rest of the interview process. At this point you already know they can code so now it’s the time to look for cultural fit (do they get on with the team and you), sell them the job and make sure you can all work together. Some technical follow up is good to understand the depth and breadth of their knowledge so you know what training is needed or can work out a plan to get them up to speed. It also allows you to ensure they have the basics covered. If they ace the test then I don’t think you need to hammer them in too much detail – just enough to ensure the test wasn’t too easy.

The last stage of the technical test – feedback

I like to ask all candidates, whether they pass or fail, for feedback on the test. It should be a continually improving process – if everyone fails then maybe your test is poor. If everyone passes then goes on to fail at later stages then maybe it’s too easy. If it takes to long then it needs to be shortened. Your recruitment processes should always be improving so getting this feedback and actioning it is vital to being a good recruiter.

The other side of the fence…

As a candidate, I also love technical tests. They can be a fun challenge, allow me to show off what I know and can do, but most importantly give me some confidence in the team I will be working with. As an employee I want to work with smart people, people I can learn from and can help me grow as a programmer. As part of my interview process as a candidate I also need to interview the company to ensure they can provide this kind of working environment, and an interview process that doesn’t filter out bad developers by verifying their coding ability is a warning sign that the existing employees might not be that good.

Summary

In summary – technical tests rock. If you don’t have one then hurry up and create one before you recruit anyone else. And prepare it now. You might not be recruiting currently but it takes a few days to get a good test ready so you need it done before that stack of CV’s lands on your desk and you boss demands you hire someone yesterday.

I’m a huge fan of using a phone interview at the start of my interviewing process. As someone trying to recruit it’s important that I have some way of filtering the hundreds of CVs that I get. I’ve come to accept most people are terrible at writing their CV, or just plain bend the truth, so before I meet them face to face it’s good to speak to them on the phone for 20 minutes to ensure that they do in fact 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 from this page you can be sure to come out on top of the pack.

Preparing for your java phone interview

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. 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. Chances are the interview will be technically focused as design interviews are really hard to do without a piece of paper or a whiteboard. You never know, you might hit lucky and get some gems of information for your research.

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 then time to simply to hit the books and get learning. 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 there5 minutesbefore 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 (more on that shortly). 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. Chances are you can’t remember what you wrote on it so have it in front of you as it’s very embarrassing when someone asks you about a part of your CV and you have no idea what they’re talking about.

Also 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 you’re quick off the bat. I want to know that you care about this role and have spent the 30 seconds it takes to look at the job description and that want to know more. Interviewers (and people in general) are egotistical like that. 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 thinking and you ask it straight away. Have 2 or 3 questions lined up. It doesn’t matter if you really want an answer, the act of asking is what matters.

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.

Phone interview 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 right. Although I think it’s more like 4 seconds. The amount of candidates I call that sounds grumpy and/or uninterested is crazy. This instantly turns me 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 me you’ve been looking forward to the interview then you’re in my positive books and the interview is yours to win.

Speak slowly. You don’t want to rattle through the interview at lightening 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 interviewing 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 (we can hear the keyboard)

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 I probably know the answer. It’s absolutely fine to say “I don’t know about that, but I’m happy to have a guess 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 get my respect.

How to run a phone interview as the interviewer

What does a good technical phone interview look like? Pretty much the same as a normal interview, only you’re limited to asking questions that don’t need a pen and paper to explain. You want to save the big guns for the face to face interviews though; this interview should be just to screen the candidates to check they have the basic skills that you’re looking for.

Most interviewers fall back on core java questions. Definitely include some of these as I’ve had a number of candidates claim to be java developers but who have clearly not touched a line of code in many years. A couple of core questions around exceptions and collections can easily weed this out. The phone interview format lends itself well to a more open discussion. The candidate you’re hiring is someone who’s going to come in and help with designs and technology choices. You want someone with ideas and experience. Do they have opinions or are they just content using what’s put in front of them? For this purpose I recommend basing the majority of the interview around open ended “Tell me about technology X you have on your CV. What do you think about X? Is it a good choice?” type questions. This allows a candidate to show off their knowledge if they have it, and by playing devils advocate with their answers- “But why not use technology Y?” you can see if they understand the reasons for choosing a technology and whether those views align with your teams.

What you will get asked during the interview

Due 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 learn. 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. Have a look at some of the questions on this site, such as on Java collections.

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 CV and figure out what your opinion is on them. The interviewer most likely won’t care what your opinion is specifically but be interested to know that 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 and have them on hand.

Riddles. This is made up of the google-esque questions like “how many grains of sand are there in the world?”. 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. 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 so try and engage the human side and have a 2 way discussion. If a candidate fires a question back at me during their answer I enjoy it. These conversations 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 were actually really good. Conversely I’ve had terrible people who thought they were brilliant. Simply wait to hear back from them and relax comfortable 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 in there 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.

Conclusion

Hopefully you’re now feeling more confident about your upcoming interview. If you have any questions that aren’t covered here then why not drop me an email at hello@corejavainterviewquestions.com, or leave a comment below?