Java Programming Interviews Exposed E-Book

Noel Markham

• Herausgeber: John Wiley & Sons
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Englisch

Seitenzahl: 513

Veröffentlichungsjahr: 2014

Beschreibung

If you are a skilled Java programmer but are concerned about the Java coding interview process, this real-world guide can help you land your next position Java is a popular and powerful language that is a virtual requirement for businesses making use of IT in their daily operations. For Java programmers, this reality offers job security and a wealth of employment opportunities. But that perfect Java coding job won't be available if you can't ace the interview. If you are a Java programmer concerned about interviewing, Java Programming Interviews Exposed is a great resource to prepare for your next opportunity. Author Noel Markham is both an experienced Java developer and interviewer, and has loaded his book with real examples from interviews he has conducted. * Review over 150 real-world Java interview questions you are likely to encounter * Prepare for personality-based interviews as well as highly technical interviews * Explore related topics, such as middleware frameworks and server technologies * Make use of chapters individually for topic-specific help * Use the appendix for tips on Scala and Groovy, two other languages that run on JVMs Veterans of the IT employment space know that interviewing for a Java programming position isn't as simple as sitting down and answering questions. The technical coding portion of the interview can be akin to a difficult puzzle or an interrogation. With Java Programming Interviews Exposed, skilled Java coders can prepare themselves for this daunting process and better arm themselves with the knowledge and interviewing skills necessary to succeed.

Leseprobe

Table of Contents

Cover

Part I: Navigating the Interview Process

Chapter 1: Dissecting Interview Types

Looking at the Phone Screening Process

Reviewing Technical Tests

Handling Face-to-Face Interviews

Making the Decision

Summary

Chapter 2: Writing a Noticeable Resume

How to Write a Resume and Cover Letter

Writing a Cover Letter

Summary

Chapter 3: Technical Test and Interview Basics

Technical Written Tests

At-Computer Tests

Face-to-Face Technical Interviews

Summary

Chapter 4: Writing Core Algorithms

Looking at Big O Notation

Sorting Lists

Searching Lists

Summary

Chapter 5: Data Structures

Lists

Trees

Maps

Sets

Summary

Chapter 6: Design Patterns

Investigating Example Patterns

Commonly Used Patterns

Summary

Chapter 7: Implementing Popular Interview Algorithms

Implementing FizzBuzz

Demonstrating the Fibonacci Sequence

Demonstrating Factorials

Implementing Library Functionality

Using Generics

Summary

Part II: Core Java

Chapter 8: Java Basics

The Primitive Types

Using Objects

Java’s Arrays

Working with Strings

Understanding Generics

Autoboxing and Unboxing

Using Annotations

Naming Conventions

Handling Exceptions

Using the Standard Java Library

Looking Forward to Java 8

Summary

Chapter 9: Testing with JUnit

The JUnit Test Life Cycle

Best Practices for Using JUnit

Eliminating Dependencies with Mocks

Creating System Tests with Behavior-Driven Development

Summary

Chapter 10: Understanding the Java Virtual Machine

Garbage Collection

Memory Tuning

Interoperability between the JVM and the Java Language

Summary

Chapter 11: Concurrency

Using Threads

Working with Concurrency

Actors

Summary

Part III: Components and Frameworks

Chapter 12: Integrating Java Applications with Databases

SQL: An Introduction

JDBC: Combining Java and the Database

Testing with In-Memory Databases

Summary

Chapter 13: Creating Web Applications

Tomcat and the Servlet API

Jetty

Play Framework

Summary

Chapter 14: Using HTTP and REST

The HTTP Methods

HTTP Clients

Creating HTTP Services Using REST

Summary

Chapter 15: Serialization

Reading and Writing Java Objects

Using XML

JSON

Summary

Chapter 16: The Spring Framework

Core Spring and the Application Context

Spring JDBC

Integration Testing

Spring MVC

Summary

Chapter 17: Using Hibernate

Using Hibernate

Summary

Chapter 18: Useful Libraries

Removing Boilerplate Code with Apache Commons

Developing with Guava Collections

Using Joda Time

Summary

Chapter 19: Developing with Build Tools

Building Applications with Maven

Ant

Summary

Chapter 20: Android

Basics

User Interface

Persistence

Android Hardware

Summary

Appendix: Introducing Scala

Scala Basics

Functions as Values

Immutability

Summary

Introduction

Overview of the Book and Technology

How This Book Is Organized

Who Should Read This Book

Tools You Will Need

Downloading the Example Source Code

Summary

Part I

Navigating the Interview Process

Part I covers many of the essentials for a technical developer interview, from writing an appropriate resume to more technical topics, regardless of any language specifics.

Chapter 1 discusses the different types of interviews that are used for assessing candidates.

Chapter 2 explains how to write an appropriate resume and cover letter, and highlights the points that interviewers often look for when reading resumes.

Chapter 3 describes how to approach the different interview types.

Chapter 4 covers some basic algorithms, such as sorting and searching. These are popular topics for an interview and are essential for understanding in a day-to-day programming job.

Chapter 5 covers some important data structures. These too are often discussed in interviews, and knowledge of these is essential in most development roles.

Chapter 6 is on design patterns. Design patterns are often a favorite interview topic.

Chapter 7 looks at some useful interview questions, which are often used across a variety of programming languages, not just for Java interviews.

Chapter 1

Dissecting Interview Types

Simply put, employers conduct interviews to recruit new talent, or to fill a necessary gap to improve a team’s productivity. Within a development team or department, you will find a wide range of skills, and on the whole, this is key to making a team gel. It is simply not possible for one person to develop and manage a professional-grade application, there is too much to manage: developing feature requests for product owners, maintaining test environments, and answering any ad-hoc queries from the operations team are all daily tasks for the team managing the development of an application. Development teams will often need one or several application developers. They may even have dedicated front-end developers and database developers. Some teams are even lucky enough to have a dedicated build manager.

Varying ranges of experience are important, too. Having developers who have put several applications live and supported them is key to any new project’s success. Graduates, or developers with a couple of years’ experience, are also vital: These employees can often bring a different perspective and approach to developing an application, and the more experienced team members can mentor and coach them in the delicate process of developing large enterprise-scale applications within a team of many people.

When it comes to interviewing for new talent, the process and experience for the interviewee can be quite different from company to company. Understandably, it falls on the shoulders of the team’s developers to interview for new developers. First and foremost, a developer’s day job is to write and produce tested, working applications, and not to interview people. As a result, a developer interviewing people for additional roles may often be under-prepared, and perhaps even uninterested in performing an interview. In a face-to-face interview, this is going to be one of the first hurdles to cross: You need to make the interviewer interested in you.

Companies, and especially technology and digital companies, are getting much better at realizing how important the recruitment process is. Some of the more progressive employers often put emphasis on recruitment within internal company objectives. This puts the responsibility on the employees to make the company an attractive place to work, with the hope that this will attract the top talent, which in turn will bring productivity, success, and profitability.

The first impression for an interviewer will be the resume, sometimes called a curriculum vitae, or CV. How to make an eye-catching resume is covered in the next chapter.

As you move through the interview process for a particular role or company, you will encounter different styles and methods of interviews. Generally, the “interview pipeline” for a candidate is designed to be as efficient as possible for the employer, with the face-to-face interviews coming late in the process.

The interview pipeline will usually start with a phone screening, followed by one or more technical tests, and finally some face-to-face interviews.

Looking at the Phone Screening Process

Companies often start the interview process with a telephone screening. This is advantageous from the company’s side, because it can take a lot of people to organize a face-to-face interview: finding available times for all the interviewers, HR, and possibly a recruitment team, meeting rooms, and so on. This is also helpful for you, because you won’t need to take much time away from work. Many people like to keep it quiet from their current employer that they are looking for jobs, so it shouldn’t be too hard to find a quiet corner of the office or a meeting room for an hour to take a phone interview.

If you do an interview over the telephone, make sure you are prepared well before the time of the interview. If you have to take the call while at work, book a quiet meeting room or find a quiet corner of the office. If that is not possible, you could go to a local coffee shop. Make sure beforehand that the noise level is appropriate: You don’t want to be distracted by baristas calling across the café or loud music playing in the background.

If you are expecting to do a remote live-coding exercise, make sure you have Internet access wherever you are. Have a pen and paper handy in case you want to make notes during the call for questions to ask later. Use a hands-free kit when typing: It will make the call much clearer for the interviewer. You don’t want to waste precious time repeating questions or re-explaining your answers—this is very frustrating for all involved.

It might not even hurt to have a few notes in front of you for any topics that may come up during the call. This is not cheating; it can help calm any nerves and get you settled into the uncomfortable, alien experience of having to convey technical explanations over the phone to someone you have never met before. Note, however, that if and when you have an interview face-to-face with the team, you won’t be able to have any notes in front of you.

Usually a phone screen lasts for 30 to 60 minutes, and you should expect some very high-level questions. The kinds of questions that come up in a telephone interview are often about language-agnostic algorithms. You may be asked to verbally describe these, or you may even be asked to attempt some live-coding challenges in a shared, collaborative document editor, such as Google Docs, or perhaps a bespoke interview-hosting website, such as Interview Zen (www.interviewzen.com).

At any point in the interview process you should know the basics about a company. Look at the “about us” page on their website. Read their blog; find out if they have a Twitter account. If you are applying for a small company or a startup, try to find out some more about the senior members of the company, such as the CEO and CTO. They can often be quite active in a local development community.

At the end of any interview, the interviewer will often ask if you have any questions for them. Answering no to this question will leave a bad impression; it will show that you do not care enough about the role. Considering you now know that this question will more than likely come up, think about what questions you want to ask long before you even go for the interview. Think about what you want to know about the team dynamic, how the team works together, and what the office environment is like. Only you can come up with these questions. This is not the time to talk about the salary or anything else to do with the package that comes with the job. There will be plenty of time to talk about that once you have been offered the role.

Reviewing Technical Tests

A technical test can be used as a supplement to or instead of a phone-screen interview. This may even happen as part of a phone screening, or you may be invited to the office for a technical test.

A technical test often consists of some simple questions covering a multitude of areas related to the nature of the role. If the role is for working on a web application, you could expect questions about the Servlet API and perhaps some frameworks such as Spring MVC or Tomcat. You should be aware of the nature of the role, and any languages and frameworks used.

These tests are usually performed alone, and can take a variety of approaches. Some interviewers rely on a pen-and-paper test, often asking some simple definite-answer questions, or others may ask you to write a simple algorithm, often around 10 to 20 lines long.

If you find yourself writing code on paper, you should take extra effort to make sure the code is understandable. Any decent employer should understand that you may make some elementary mistakes around method naming, or miss a semicolon, but you should always aim to give no excuse to an interviewer to not ask you back for any further interviews.

Another popular technique is to provide a coding test on a computer with a functioning IDE. This is a fairer way of testing, because it is a similar environment to how candidates work when doing their day job. They may not provide Internet access, but may provide offline Java documentation instead.

When you are tested with a fully functioning IDE, or even just a compiler, you have no excuse for producing code that does not compile.

Whatever you are asked to do, write unit tests. Write them first. Although this may take additional time, it will ensure that the code you do write is correct. Even if a test makes no mention of writing unit tests, this will show to anyone examining your test that you are diligent and have an eye for detail. It will show that you take pride in your work, and that you think for yourself.

For example, method names in JUnit 4 and onward are free from any kind of naming convention (as discussed in Chapter 9), so if you saw a question similar to the following: Write a simple algorithm to merge two sorted lists of integers, you could quickly start by writing a list of test cases, and these will then become the method names for your JUnit tests.

Covered in depth in Chapter 9, method names in JUnit 4 and onward are free from any kind of naming convention, so you could quickly start by writing a list of test cases, making them method names for JUnit tests. Some example test cases for the given question include:

twoEmptyLists oneEmptyListOneSingleElementList oneEmptyListOneMultipleElementList twoSingleElementLists oneListOfOddNumbersOneListOfEvenNumbers oneListOfNegativeNumbersOneListOfPositiveNumbers twoMultipleElementLists

The contents of each of these test cases should be easy to understand from the name. Given a well-defined API, writing the test cases should take no more than five to ten minutes, and you can run these tests as a frequent sanity check when implementing the actual merge. This will keep you on track as you are writing and refactoring your real code.

These given test cases probably do not cover every possible code path for merging two sorted lists, but should give you and the interviewer confidence in your actual implementation.

Most modern IDEs allow you to automatically import the JUnit JAR without needing any Internet access at all; it comes bundled with the IDE. Make sure you know how to do this for a few IDEs, because you may not get a choice of which one to use in a test situation. At a bare minimum, you should be able to do this for Eclipse and IntelliJ. They are both smart enough to recognize the @Test annotation and prompt you to import the JUnit JAR.

Try to write test cases concisely and quickly. Any reasonable interviewer will not mind the odd missed test case, understanding that you want to show the range of your abilities in the time given.

If you are ever given a paper test and a test on a computer, you have the advantage of being able to check your code on paper by writing it on the laptop! Some companies do take this approach—they will provide some simple, exploratory Java questions on paper, and then ask you to write a more in-depth, small application.

Considering you are applying for a job as a developer, it is reasonable to expect to demonstrate your technical ability during the interview process. It is worth noting that this is not always the case—interview standards can be so varying that it is not unheard of to have a brief chat with a hiring manager, and that is all. This approach does not normally work out well for the employer, and thankfully this does not happen as often as it used to.

Like all parts of the interview process, you must be prepared. The job specification page should contain a lot of technical information about what languages, technologies, and frameworks are used. A job specification page should be available on the company’s recruitment website pages, or if you cannot find it, you should ask the company for it. You should not be expected to know every bullet point on a job specification inside and out, but the more you can show, the better. Employers will be looking for a willingness to learn and adapt, so make sure you convey this in an interview. Most importantly, you must want to learn the technologies the company uses.

Again, understand what the company does; you may even be asked specifically for what you understand about the company, or specific applications developed by the team you are interviewing for. If the company has a public-facing website, make sure you have used it. If the role is part of a game, make sure you have played it. Some employers have a rule that candidates are a definite “no” if they have not used the product developed by the team.

Handling Face-to-Face Interviews

Following a successful technical test, you should be asked for a more personal interview, meeting members of the immediate team you would be working with as well as a hiring manager, and perhaps some members of a recruitment team or human resources. This can often happen over the course of half a day, or a full day. It may even be set over several meetings on several days, usually depending on the office location—how easy it is for you to keep returning for more interviews—the availability of the interviewers, and your availability, too.

As a rule, the interviews will get less technical as the process progresses. A typical set of interviews may be as follows:

A technical interview, covering any work done in a pre-screening or an individual test

Several more technical interviews, covering more topics and questions of interest to the hiring team

You may be expected to write some code on a whiteboard or to do some pair programming.

An interview with one or several members of the business side of the team, typically a product manager or project manager

An interview with a hiring manager. This will cover some softer skills, away from the technical side. This is to see if you are a good fit for the team.

A final debrief from an in-house recruiter or HR representative. Salary expectations and other contractual conversations may happen here, as well as any information about next steps.

In preparation for any upcoming interview, try to think about possible questions that will be asked. If you are expecting to cover any code you wrote in a phone screening, online, or in a previous technical test, try to remember what you actually wrote. It may help to try to write out from memory any small applications that you wrote as part of your test. It does not matter if it is not exactly as you submitted it the first time, but it will help jog your memory, and you may find some improvements to discuss in the interview.

When doing any face-to-face interview, be prepared to be stretched to the limit of your ability. Answering with “I don’t know” is not an admission of failure; it is simply that the interviewer is trying to understand the limits of your knowledge. Of course, the later you reach that point, the better. However, you cannot expect to be an expert in all domains, so there should not be much concern if you can demonstrate a deep understanding of, say, Spring and Hibernate, but your knowledge of database transactions and concurrency is not up to the same level.

The interview process itself is not perfect. This is not an examination; just knowing the right answer is not enough. The interview team is checking to see if you will be a valuable addition, perhaps looking to see if you would be a suitable mentor if you are interviewing for a more senior role, or if you show drive, determination, and passion if you are trying for a junior role.

Sometimes even this is not enough; perhaps the interviewer is in a bad mood, or having a bad day. The interviewer could even be mentally distracted from a broken build that happened just minutes before stepping into the interview. Unfortunately there is not much you can do in these circumstances. Always be polite and try not to upset the interviewer during any discussions.

Often late in the process, once the developers are happy that your ability matches their expectations, you will meet with the hiring manager. The role of this interview is to discuss your fit within the team, talk about some of the expectations and softer skills that are required for the role, and discuss your own career development within the company.

Like in all steps of the process, your manner and engagement are being examined here. The hiring manager wants to see that you are keen, smart, and able to hold a decent conversation. It is very rare that a developer sits alone and writes code all day with no interaction with anyone else. Talking to other developers, product managers, and many other people is necessary on a daily basis, and one of the main points of this conversation is to ensure that your communication with others is at an acceptable level.

Sometimes, if the interviewing team feels that you are not quite the right fit, they may terminate the interview early, informing you that they are not going to pursue the role any further. If this happens, it can be quite a shock, especially if you are not expecting it. Be assured that it is nothing personal, and is not a slight against your ability; it is purely that your skills do not match up with what they need. Try not to let this affect your confidence, and ask yourself if there is anything you need to brush up on before any interviews with a different employer.

Making the Decision

Being offered a role is not the end of the process. First, you must be absolutely sure that you want the role. If you have any doubts, even after an offer stage, approach the hiring manager or recruitment agent. They can often allay any fears you may have, or fill in the answers to any questions you didn’t ask during the interview process.

Even after any further discussions, if you still feel that the role is not right for you, do not take it. You would be better to carry on looking rather than taking the job, being unmotivated, and then looking to move soon after, or worse, not making it through any probationary period.

If you are happy with the role, you will be offered a salary and perhaps other benefits as part of your employment package, such as stock options, a pension, and medical benefits. You may have some room to negotiate on the package at this point. Remember, the hiring manager and the rest of the team now want you to work for them. They have invested a lot of time and effort in examining you, and if they cannot provide you with an attractive offer now, they will have to start the process all over again. Do not push your luck, though: A developer salary and package will fall only within a certain range in the team’s budget.

Summary

If you are inexperienced with interviews, they can be quite daunting. The best way to remove any fear is simply with experience; the more interviews you have under your belt—successful or otherwise—the more you understand exactly what interviewers are looking for, and how to tackle the questions given. Although the questions in this book will provide a good insight into the types and styles of questions you might encounter during an interview, the actual execution of answering these questions effectively will only come with practice and experience.

Remember at all times that interviews are a two-way process. Although the interviewing team dictates how and when the interview process happens, you are interviewing the team, too. It is solely up to you to decide if you actually want to work for this team. Make sure you answer that question before you commit and move jobs.

People can find rejection hard from interviews, especially when they have had much success in academic life. Interviewing for a job is not the same as taking a university or college exam; getting the question right is not always sufficient. Every single aspect of you is being examined, from your personality to your skills, but also whether your skills match with what the hiring team needs. There is no shame in being rejected for a role. Getting the questions right is only half of the battle.

The biggest key to acing any interview is preparation. Make sure you understand the domain properly, and try to visualize what exactly the interviewers are going to want from the interview. Think about the questions they may ask, and make sure you have some questions of your own to ask them.

Chapter 3 visits the different interview types discussed in this chapter, and delves a little deeper into your conduct and how to produce good and relevant answers. Before that, however, Chapter 2 looks at the very first stage of the hiring process, before any interview takes place: how to write an appropriate resume and cover letter to get noticed by the recruiting team.

Chapter 2

Writing a Noticeable Resume

A common joke amongst recruiters and interviewers is that they always throw half of the resumes in the trash without reading them, because they do not want unlucky people working for them.

Getting your resume noticed can be quite hard, and may involve a little luck. The advice and writing technique shown in this chapter will hopefully reduce the reliance on luck as much as possible.

How to Write a Resume and Cover Letter

The written part of a job application generally consists of two parts: a resume and a cover letter. A resume is an account of your professional qualifications and other relevant skills, whereas a cover letter is a personal letter to the interviewer that describes how the specific role you are applying for suits you, and what extra qualities you can bring to the team along with the role.

Even though your resume should appear generic, you should tailor it to a particular job. When you submit your resume, make sure you tweak it in favor of the job you are applying for, focusing on your most prominent skills that match the job specification.

A resume should never be more than two pages in length. Most interviewers are developers in their day job, and simply do not have time to trawl through pages and pages of a career history. Keep it concise and relevant, and concentrate on your most recent roles.

With this in mind, you should make sure that any key information you definitely want an interviewer to see is toward the top of the first page. Focus on the key strengths you want to convey here. Do not waste space by adding a title that says “Resume” or “Curriculum Vitae”—everyone reading this document knows what it is. One of the most important things you want the interviewer to remember is your name; make this as your heading, and make it the largest font on the page.

Some candidates now put a small headshot photograph on their resume. This can help interviewers put a face to a name when discussing candidates after performing several interviews, but it is up to you whether you want to include a photo; it will not have any overriding positive or negative effect on your chances of a job offer.

A common approach nowadays is to have a developer profile at the top of the page. This is a short paragraph, perhaps three or four lines, that sums up your aspirations and career to date, and describes what you are looking for from your next role. An example profile might say:

An experienced Java developer with four years experience in the retail and banking industries. Always keen to learn new technologies, and looking to take more leadership over project delivery.

By placing this toward the top of the page, the likelihood of an interviewer reading this statement is high. The profile shown here is written in the third person. It is purely a matter of preference if you write it in the first or third person, but, like the rest of your resume, make sure you are consistent.

Something else to include early in the document is a section on key skills. This can be a list, perhaps a set of bullet points that you see as your most employable traits.

Whatever you write here, make sure you cover as much ground as possible. If you have experience in languages other than Java, mention them. Say what operating systems you are experienced with. Mention which tools you use, such as the IDEs you prefer, as well as other aids to your role as a developer such as source control systems.

Do not just write a list of acronyms. Do not just write a list of every library and tool you have ever touched. Interviewers will not pay much attention to several lines of acronyms—“SQL, XML, JDBC, HTTP, FTP, JMS, MQ,” and so on. It is much better, and more engaging for the interviewer, if you describe your key skills as:

Expert with Spring JMS and the HTTP protocol, some experience with Apache Cassandra.

Whatever you decide to include in this list, make sure the items are appropriate. Any key skills you list should be reflected elsewhere on your resume, such as in your description of previous roles.

Include a small section on your education and qualifications. Start with your most recent qualification. Include the dates you attended the institutions. If you have a university or college degree, include the titles of any theses, dissertations, or papers you submitted. You do not need to be too detailed about your high-school qualifications. Include a single line highlighting when you attended the school, and any key examinations.

If you do not have a university qualification, be a little more detailed about your grades in key subjects, such as math or English.

As you gain more experience, you can place less emphasis on the education section in your resume. If you are applying for senior or leadership roles, employers will be much more interested in seeing evidence of what you have achieved in the workplace. Regardless, you should always include your highest qualification.

Unless you have just left school, the majority of your resume will be made up of your work experience. Treat each role as a different section, and for each role, include the dates and locations of where you worked. You should include a brief description of your responsibilities and what you achieved. Where appropriate, mention any technologies or libraries you used. Similar to your key skills section, summarizing your experience with bullet points is fine: Any interviewer will want to read and understand your experience as quickly as possible.

Remember that the interviewers are interested in what you have achieved, what your role was in any team success. Rather than describing a role as:

I worked on the team that released the game XXX. It received two million daily active users within the first month.

It would be much more informative to say:

I was responsible the development of the server for game XXX, focusing on its stability. It handled two million daily active users within the first month, with no downtime.

This way, you have made it clear what your role was on the team, what your responsibilities were, and what was achieved thanks to your input.

Where appropriate, try to use powerful adjectives when describing your work. By describing yourself as a “lead” developer, or having the “sole responsibility,” or being a “core team member,” you are emphasizing your value to any work within a development team. Remember that you must be able to validate your descriptions.

If you have any gaps between employment dates in your resume, you must be prepared to talk about them in an interview. If you decided to take some time off and go travelling, that is fine; if you were made redundant or were laid off and it took you several months to find a new job, that is fine, too. But employers will be interested in knowing what you did with your time off. Prospective employers will be looking for candidates who are productive, forward thinking, and proactive. If you can truthfully say you were helping with some open-source projects or doing some kind of charitable work, this will put you in a lot better favor over someone who cannot explain what he or she did with any time off.

Even if you tried to start your own business and it failed, there is no shame in this at all. In fact, most employers would see this as a positive personality trait.

If you have any appropriate online presence, providing links is often attractive to employers. If you have a Github profile, a link to it will give employers additional insight into how you work. If you write a blog, include a link to that, too. If you answer questions on question-and-answer sites such as Stack Overflow (stackoverflow.com), provide links to some of your popular answers or to your profile page. This is very informative as to how you work and think in a “real-world” environment, rather than the strange, alien environment of a set of interviews.

You should expect any interviewers to perform an online search for you. If you have a Twitter account or Facebook account, or similar account that is easily traceable to you, make sure the content posted is something you are comfortable sharing in an interview. If it is not, make sure you have the privacy settings configured appropriately.

Candidates often include a small section toward the end of a resume of some personal interests. This can have very little bearing on a decision to call someone in for an interview. Although it can show that you are an interesting individual who does more than just work, a decision to interview someone will be made on the relevant professional credentials on a resume. If you are struggling to fit the contents of your resume into the hard two-page limit, leave this off.

Some candidates also include one or two references with their contact details. There is no issue if your resume makes no mention of references, but if you choose to include them, make sure they are up to date. Speak to your references beforehand, and make sure they are prepared to expect a call and talk about your best qualities. Failure to do so will reflect poorly on your reliability.

Writing a Cover Letter

The cover letter is a chance to show that you have done your homework about the role you are applying for. It should be relatively brief, much less than one page, with the aim of persuading a recruiter or interviewer to invite you in for an interview.

Use this letter to highlight any key entries on your resume that you feel are relevant for the role. Also mention your most recent role and what you did there. If a current employee referred you, mention him or her by name: Many companies offer a referral bonus for any successful hire. You want to make sure to follow through on this—if you are hired, you might even get a cut of the bonus!

If you are not currently employed, the cover letter is an ideal place to say what you have been doing since you left your most recent role.

You should also state why you want to join the company you are applying to. If it is in a different industry, explain why you would like to move industries, too.

Say why you are looking for a new role. There is nothing wrong with wanting to leave to develop yourself and your career, but you must be able to articulate that in the letter and in any subsequent interviews. You should also mention any softer skills you feel you would bring to the role.

Even if you have contact details on your resume, include a line in your cover letter explaining how best to get in touch with you. You want to leave no excuse for not being invited in for an interview.

The body of an example cover letter could look like:

Please find my resume attached for the software developer role.

My current role is as a server-side Java developer for Company X. I have been at the company for three years and worked on two different teams as a Java developer in that time.

I feel that both Company X and I have gained a lot from my employment there, and I feel it is time for me to move on and apply my technology skills in a different industry, and hopefully gain some new ones too.

I am confident I can bring my enthusiasm and experience to Company Y and to this role. I look forward to hearing from you soon.

It is these small attentions to detail that may differentiate your job application from another candidate’s.

Summary

Your resume is the first thing that any prospective employer will see about you. It is an advertisement, your brand. You have full control over this document, and so you should make every effort to make sure it is perfect.

There should be no mistakes at all on your resume. Double-check all the dates, make sure there are no spelling mistakes, and make sure the grammar is correct. Simple errors on your resume will give the impression that you do not care, and, therefore, can’t be trusted to produce professional-grade, properly tested applications.

Keep the formatting consistent. Your resume does not need to have fancy headings and several typefaces: You are not applying to be a graphic designer. Keep your formatting clean, simple, concise, and easy to read.

Get others to check your resume, and take any feedback from them constructively. Read and re-read it several times; you will always find minor adjustments and other small changes to make.

Schedule a small amount of time every two to six months to keep your resume up to date. You will find it easier to remember any key points you want to highlight. Also, updating your resume more frequently means you will be making fewer changes at any one time, so the chances of making an obvious error or typo are limited.

Always try to keep your resume to two pages at maximum. This allows an interviewer to print it on a single piece of paper, double-sided. Over time, as your experience grows, you will have to be judicious in what you decide to keep and what you decide to remove to keep the document under a two-page limit. This can be hard at times, and you may find yourself fiddling with margin widths and font sizes to fit on as much as possible, but sticking to a two-page limit is key. Interviewers simply do not have the time or the interest to read an eight-page resume.

If you take only one thing from this chapter, be aware that anything you write on your resume is fair game for an interviewer. Do not lie; do not say you have skills or experience where you do not. If, or perhaps, when, any falsehoods are uncovered in an interview, you can almost be certain you will not be receiving a job offer. Even if you manage to get through an interview with a false resume, most employers will perform thorough background checks, and any wrong qualifications or false roles will be uncovered there.

The next chapter looks at how to handle assessments once an interviewing team is happy with your resume, and would like to find out if you would be a good fit in terms of skills, knowledge, and personality.

Chapter 3

Technical Test and Interview Basics

Undertaking an interview for a Java developer will inevitably require an employer to test your technical ability.

This chapter covers some of the testing formats used by interviewers to see if your programming skills match what is required for the role they are trying to fill.

The questions provided throughout this book will usually be asked within one of the interview formats discussed here. If you have never had to do a technical interview, or it has been a while since you last did one, this chapter should set an expectation of how recruiters assess candidates.

Technical Written Tests

Technical written tests are often used as a screening technique for interview candidates, and are usually done before any face-to-face interview. Candidates will be asked to take a short, written test so that the interviewing team can assess whether they are worth interviewing.

This is beneficial to the interviewing team, because they can get a good idea about the ability of the candidate without having to put in much effort. Quite often, interviewers can find it hard to differentiate candidates from the resume alone, because many resumes consist solely of lists of technologies used in previous roles. This should be a motivator to make sure your resume stands out from the list of average resumes a recruiter receives.

Offline, written-on-paper tests are not very good ways of assessment, because this is not the way you would usually write code. You have no IDE, no compiler, no Internet access to rely on; it is purely reliant on what is in your head.

Although it is not a very good method of assessment, it is still a popular recruitment technique, because of the minimal investment needed from the development team.

Whenever you are asked to take a written test, try to follow the same advice and guidelines you were given when taking exams at school. Make sure you read and understand the entire question before attempting to answer it.

Take a look at all of the questions first, so that you don’t get any nasty surprises as you are running out of time. The better written tests will have questions that increase in difficulty, meaning you should be spending more time on the later questions.

Sometimes, a written test will have more questions to answer than is physically possible in the time allowed. Don’t feel too deflated if you cannot answer all the questions. The assessors want to see just how quickly you work and figure out the answers, to understand the speed of your problem-solving ability.

Write legibly. It is highly unlikely that you will be hired for the quality of your prose, so if you are asked questions that require an explanation, do not be afraid to be terse and to the point with your answers. Use bullet points if necessary; just make sure you answer a question as completely as possible.

Writing code on paper is hard. It is very simple to forget a semicolon, the ordering of arguments to a method, or similar things you take for granted. Refactoring involves scribbling out method or variable names, or perhaps starting again with whatever you have written. Hopefully your interviewer will take this into account and accept that code written on paper will never be perfect.

If you are asked to sketch an algorithm on paper, try to think it through in your head first, before committing pen to paper. Do not be afraid to make a few attempts before being happy with your implementation: After all, that is how many developers write code in the real world.

At-Computer Tests

A slightly more professional approach used by interview teams is to ask you to complete a test by writing real, compiled code. Sometimes a recruiter will send you some questions to do at home, or perhaps ask you to come into the office to take a test.

This method should be a little closer to how you write code in real life, and so, any interview nerves aside, you should feel a little more comfortable with this type of assessment.

If you are asked to perform the written test at home, try to mimic your own working conditions as much as possible. You will have full Internet access for any documentation, and you will have, within reason, much more time to do the test than you would in a one- or two-hour interview slot in the offices of the company you are interviewing for.

If you are asked to go in to the office, and, if you are lucky, the computer you are using for any test will be connected to the Internet, you will be able to look up any Java API documentation if necessary. If you do have Internet access, resist the urge to rely on search engines or question-and-answer websites—try to attempt the questions using your own ability as much as possible.

Some at-computer tests are performed offline, but they will give you access to Java API documentation stored on the computer’s hard drive.

Hopefully an at-computer test will make use of an IDE, although you may not get a choice, so make sure you are familiar with the basics of the more popular IDEs, including Eclipse and IntelliJ. Most IDEs are also shipped with the Java API documentation for the standard Java libraries, so you should be able to look up how certain methods work directly in the code.

Of course, the best thing about using a modern IDE is that it will check and compile your code as you type, so you can fix any trivial issues quickly.

Sometimes a test will ask a series of questions, and you will be provided with an interface, or method signature. You will not be able to change this interface because it is likely your code will be part of a larger application that needs that interface to run, such as a web application server.

Alternatively, the reason for not being able to change any method definitions will be because the interview team may have a suite of unit tests to run against your code. This is another practical approach from the interviewers—they are able to see if your code meets the test requirements quickly, without much input from them.

From their point of view, making the tests pass is not the full story. They will also check any successful code for its quality, making sure the code is professionally formatted, any reasonable comments included, and just to get a general feel for how you write code.

You may be asked a less rigid question, where you have no predefined method template or interface to work from, such as writing a small application from scratch. It can be a lot more daunting to get started when faced with an empty file, rather than filling in the blanks on a template with the method name, return type, and parameters filled in.

If you are not sure how to start, some people find it helpful to draw some diagrams of the components of the application, and how they expect it to work and fit together. This can then trigger the creation of any domain objects and the application logic of how they all fit together.

Regardless of your approach, make sure you write tests. Even if you have not been told to write tests, you should do it anyway. Tests will guide the writing of your application, and you will find that as you are pressed for time, the tests will keep checking that all your code fits together as you expect. If any refactoring prompts test failures, you can quickly roll that change back, rather than carrying on obliviously and then having recruiters reject your test straight away because it didn’t work as expected.

Most IDEs have the JUnit jar packaged within the application and the ability to auto-import the jar into the project when it sees you are writing a JUnit test case, so do use that if you can. Most interviewers will be impressed, especially if you have not been explicitly asked to write tests.

Face-to-Face Technical Interviews

Often after some solo technical assessment, you will have one (or several) interviews face-to-face with other developers. Often, they will ask you some technical questions, and will ask you to answer by writing out what you would do on paper, or perhaps on a whiteboard.

This can be quite a strange environment if it is not something you have ever done before, or if you are used to the comfort of an IDE and compiler.

Interviewers will often ask you to write in a specific language, or perhaps in pseudocode.

If you are asked to sketch out an algorithm on paper or on a whiteboard during an interview, and you are asked to write in Java (or a different language, for that matter), try to get the syntax as correct as possible. Try to remember all semicolons, and try to get any API library method names correct. However, the interviewer should not expect this to be perfect; after all, that is why you use a compiler in the first place.

Usually the approach for an active offline coding interview is that the interviewer will give you the requirements for an algorithm, and will then leave it to you to solve.

One useful approach is effectively to think out loud. Build up your answer, providing a commentary as you do. The interviewer will usually be involved, so treat it as a conversation. If you are not sure about a certain approach, make this clear. There is no harm in going down a wrong path, if as soon as you realize, you can explain why and what changes you are making because of it.

More often than not, an interviewer is interested in your thought process just as much as the correct answer. If you are asked a question you have had before, and you write out a perfect solution in 60 seconds, the interviewer won’t able to measure your problem-solving ability. It would be much better to let an interviewer know that you know the solution to the given problem.

Do not be afraid to ask questions. When the interviewers asked the question at the start of the interview, they were merely setting the problem in motion. Often there is more than one acceptable solution to a given problem, so asking appropriate, well-thought-out questions can help guide you to an acceptable solution.

When fleshing out an algorithm on a whiteboard or on paper, write quickly, and again, be sure to be legible, too. If the interview team looks at your code after interviewing other candidates all day, and they cannot read what you have written, they won’t be able to make a positive decision about your interview.

Summary

Whenever you are writing code for an interview, you will often be under pressure from the clock. This is for several reasons: It is simply practical for the interviewer, and for you, to have the interview process time boxed. They will have other people to interview, as well as their day jobs. You may have other interviews, or other things to do in your daily life. More importantly, interviews and coding tests are conducted within a time limit to see just what you are capable of achieving in the time given.

You can find several online resources for practicing test questions. Look around on the Internet for some sample tests to do in a restricted time frame to get yourself in the mindset. You may even find the challenges fun!

Whenever discussing a technical test implementation with an interviewer, one question to always expect is, “Does the code you have written work?” If you don’t explicitly write tests as part of the interview, try to think of some test cases for your code as you write it, because this will form a productive discussion toward the end of the interview.

Think through the code you have written, think about any improvements you would make, and be prepared to talk about those in an interview. Think about any limitations of the code, even limitations supplied by the given questions. One common question is to ask what you would change in your code to scale to several million users.

Preparation is key: Try to put yourself in the shoes of the interviewer. What would you ask?

The next chapter covers algorithm basics, sorting and searching in particular. These core computer science topics are often the basis for common technical interview questions.

Chapter 4

Writing Core Algorithms

Many of the algorithms you are asked to define or demonstrate in interviews are operations on lists, usually sorting or searching. This chapter examines several ways to assemble a list into an ordered list, and discusses the advantages of each approach. It also looks at a common approach to searching lists for a given value.