Hire the top 3% of freelance Java developers.

Toptal is a marketplace for top Java developers, engineers, programmers, coders, architects, and consultants. Top companies and start-ups choose Toptal Java freelancers for their mission-critical software projects.

No-Risk Trial, Pay Only If Satisfied.

We've been blown away by the level of talent we've been able to hire through Toptal.

Brad Rozran, Optimizely

Trusted by leading brands and startups

Our Exclusive Network of Java Developers

Harold Frazier, Jr.

Java Developer

Computers have been Harold's passion since he compiled his first program in elementary school. He will always appreciate how the software industry continues... to change and grow through technology innovations that make our lives more enjoyable and efficient. 

Hire Harold

JoyAnne Foster

Java Developer

JoyAnne is a software engineer with 20+ years experience. She has developed and managed the full life-cycle of multi-tier full-stack applications. She's se...lf-motivated and has extensive experience on front-end UI work, server code, and back-end DB management, but her love is JavaEE application development. 

Hire JoyAnne

Alex Loddengaard

Java Developer

Alex started his career at Google and then as employee #3 at Cloudera. His most position was as a solutions architect at Confluent, working on Apache Kafka.... He’s architected and built apps mostly on the back end—web stacks, data analytics, data pipelines, data engineering, microservices, and streaming ETL. He’s also done some simple front-end development, full-stack development, and Android apps. He's willing to work onsite in the Bay Area. 

Hire Alex

Anna-Chiara Bellini

Java Developer

When Anna was a kid, her brother got a Commodore 64 for Christmas. He played video games, and she started coding. Since then, her career has spanned many di...fferent projects and programming technologies. But regardless of the task at hand, she always brings the same enthusiasm and passion. 

Hire Anna-Chiara

Philip Frank

Java Developer

Lean, build, teach, repeat. Philip is a self-taught full-stack software engineer with nine years of experience working mostly on web and Android projects. H...e values openness and transparency a great deal so that he can understand why decisions are made in a certain way and can voice any doubts early on. In addition, learning and teaching is an important part of being a good engineer for him. 

Hire Philip

Nicolas Spessot

Java Developer

Nicolas is an experienced software engineer focused on Agile methodologies with experience in a wide range of projects like real-time messaging systems, clo...ud solutions, database design, airline booking systems, etc., using a variety of technologies and programming languages. Nicolas inspires confidence by clearly communicating risks, blockers, and new ideas, and by setting real expectations for the development of the product/service/project. 

Hire Nicolas

Radek Ostrowski

Java Developer

Radek is a certified Toptal Blockchain Engineer particularly interested in Ethereum and smart contracts. In the fiat world, he is experienced in big data/ma...chine learning projects. He is a triple winner in two different international IBM Apache Spark competitions, co-creator of PlayStation 4's back-end, a successful hackathon competitor, and speaker at conferences in Australia, Poland, and Serbia. 

Hire Radek

Furkan Varol

Java Developer

Furkan is a software engineer with a focus on back-end programming. With over five years of professional development experience, he is known for producing c...lean code very quickly, has a passion for learning, and enjoys solving algorithmic problems. He is dedicated and tenacious with his work and will be a great addition to any team. 

Hire Furkan

Christian Diego De Martino

Java Developer

Christian is a software engineer with over 16 years of experience developing applications for big corporations and startups in Java, Objective-C, and Swift.... Over the past few years, he's being developing apps using JavaScript with libraries like React and Node. Christian has a strong command of English and is able to communicate extremely well both orally and written. 

Hire Christian

Christopher Smith

Java Developer

Christopher is an expert JVM developer with solid experience building with Spring, Groovy, and the JVM ecosystem in general. He has managed the full softwar...e lifecycle from requirements to deployment, along with systems administration and networking (CCDP/CCNP). He is a proactive guy who's looking for projects that involve back-end engineering, infrastructure questions, networking, orchestration, and harder functional programming. 

Hire Christopher

Martin Ždila

Java Developer

Martin is software professional specialized in Java and JavaScript full-stack software design and development. He prefers open source software and technolog...ies. Martin considers himself very agile in learning new technologies and finding solutions to difficult technical problems. 

Hire Martin

Hire Java Developers Seamlessly with Toptal

Talk to One of Our Industry Experts
A Toptal director of engineering will work you to understand your goals, technical needs, and team dynamics.
Work With Hand-Selected Talent
Within days, we'll introduce you to the right Java developer for your project. Average time to match is under 24 hours.
The Right Fit, Guaranteed
Work with your new Java developer for a trial period (pay only if satisfied), ensuring they're the right fit before starting the engagement.


  • How are Toptal Java developers different?

    At Toptal, we thoroughly screen our Java developers to ensure we only supply experts of the highest caliber. Of the more than 100,000 people who apply to join the Toptal network each year, we accept fewer than 3%. You'll work with engineering experts (never generalized recruiters or HR reps) to understand your goals, technical needs, and team dynamics. The end result: expertly-matched talent from our network, hand-selected to fit your business needs.

  • What is the no-risk trial period for Java developers?

    We make sure that each engagement between you and your Java developer begins with a trial period of up to two weeks. This means that you have time to confirm the engagement will be successful. If you're completely satisfied with the results, we'll bill you for the time and continue the engagement for as long as you'd like. If you're not completely satisfied, you won't be billed. From there, we can either part ways, or we can provide you with another expert who may be a better fit and with whom we will begin a second, no-risk trial.

  • How fast can I hire Java developers through Toptal?

    Depending on availability and how fast you can progress, you could start your no-risk trial with a Java developer within 48 hours of signing up. Most of our engagements start within 2 weeks of discussing your project with us.

Tap Into World-Class Talent

  • Trusted Experts Only

    All of our talent are seasoned experts who ramp up quickly, readily contribute as core team members, and work with you to minimize onboarding time.

  • The Right Fit

    We have a knack for matching you with the right fit. Start working with your new hire on a no-risk trial period, paying only if satisfied.

  • Scale as Needed

    Hire in under 2 weeks and scale your team up or down as needed, no strings attached.

  • Seamless Hiring

    We handle all aspects of billing, payments, and NDA’s. Let us take care of the overhead while you focus on building great products.

  • Flexible Engagements

    Choose the engagement type that suits your needs — hourly, part-time, or full-time — with the ability to change anytime.

  • Expert Talent Matching

    Focus on your project and enjoy support from your dedicated account executive and expert talent matcher.

Guide to Hiring a great Java Developer

Mastering Java is no small feat. Its extensive class libraries contain a wide array of capabilities and nuances, many of which are lost on the average developer. Those who have mastered the language can have a significant positive impact on your team's productivity and on your system's performance. Here are some targeted questions to help identify true masters of the language.

How to Hire a Great Java Developer

The Challenge

Today, nearly 20 years after its initial launch, Java is reported to be the most in-demand language skill, and by a wide margin (twice as popular as the runner up, PHP).

With Java usage being so pervasive, there is no shortage of developers with Java listed on their resumes. But as with any technology, there’s knowing Java and then there’s really knowing Java. So how can you identify those who are true Java experts?

Java mastery, like many skills in life, takes time and a healthy dose of curiosity to fully leverage its power. Accordingly, as described in our post In Search of the Elite Few, an effective recruiting process needs to evaluate many dimensions of a candidate beyond just technical knowledge; attributes such as drive, integrity, and creativity are equally essential attributes of a master developer. Evaluating those dimensions of a candidate can then be augmented with questions – such as those presented herein – to help identify those who are true Java experts.

Assessing the Foundation

We begin with some questions that can help evaluate the depth of a candidate’s understanding of some fundamental Java paradigms and concepts.

Q: What are anonymous classes? When, why, and how would you use them? Provide an example.

Anonymous classes are in-line expressions, often single-use classes for convenience, that help make your code more concise. The following example instantiates a new ActionListener to handle events associated with a button:

button.addActionListener(new ActionListener() {
    public void actionPerformed(ActionEvent e) {
        /* do something in response to button action event */

This makes sense since the class isn’t used elsewhere and doesn’t need a name. However, if you pass an anonymous class to a registration method, for instance, you may want to keep track of its reference, in order to be able to unregister it later. Let’s extend the above example to demonstrate this:

ActionListener listener = new ActionListener() {
    public void actionPerformed(ActionEvent e) {
        /* do something in response to button action event */

/* some time later... */


Q: What are abstract classes? When, why, and how would you use them? Provide an example.

Abstract classes are useful for defining abstract template methods that concrete subclasses must implement. All concrete subclasses are therefore guaranteed to honor the API specified by the abstract methods in the abstract class they inherit from. This is somewhat similar to the way in which a Java interface specifies an API for all classes that implement it.

The common use case is where there is a category of objects that have a common behavior (e.g., all shapes have an area), but the details of calculating or performing those functions varies from one object to another. For example:

 public abstract class Shape {
     public abstract double area();
 public class Circle extends Shape {
     private double radius;
     public Circle(double radius) {
         this.radius = radius;
     public double area() { return Math.PI * Math.pow(this.radius,2); }
 public class Rectangle extends Shape {
     private double width, height;
     public Rectangle(double width, double height) {
         this.width = width;
         this.height = height;
     public double area() { return this.width * this.height; }

A couple of things worth noting:

  • Abstract classes may not be instantiated directly; only their concrete subclasses are instantiable.
  • A class may be declared abstract even if it has no abstract methods. This will preclude that class from being instantiated. This can be useful, for example, if a base class in a class hierarchy has no abstract methods but is not itself meant to be instantiated.

Q: Compare and contrast checked and unchecked exceptions. Provide examples.

Unchecked exceptions are exceptions that are not considered to be recoverable. Java doesn’t force you to catch or handle these because they indicate abnormal, unexpected problems with your code such as NullPointerException, ArithmeticException and IndexOutOfBoundsException. That is, these are problems you need to fix or prevent. Unchecked exceptions all derive from RuntimeException.

Checked exceptions are exceptions that are considered to be recoverable. Checked exceptions must explicitly be specified as part of a method’s API; that is, a method that may throw one or more checked exceptions must list those potential exceptions as part of its method declaration (the Java compiler will actually enforce this).

When calling a method that throws exceptions, the caller must either handle (i.e., catch) those exceptions or must throw them itself. For example, if a method throws a checked exception, the caller might decide to ignore the error and continue (swallow it), display a dialog to the user, or rethrow the exception to let a method higher up the call chain handle it (in which case it must also declare that it throws the checked exception).

For example:

public void readFile(File file) throws IOException, MyReadFileException {
    try {
        FileInputStream fis = new FileInputStream(file);
    } catch(FileNotFoundException e) {
        // We catch the FileNotFoundException and instead throw an IOException,
        // so we don't include FileNotFoundException in our "throws" clause above. 
        throw new IOException();
    if (somethingBadHappened) {
        // We explicitly throw our own MyReadFileException here,
        // so we do include it in our "throws" clause above.
        throw new MyReadFileException();

Checked exceptions clearly communicate and enforcing handling of error conditions. However, it can also be a pain for developers to continually need to include try/catch blocks to handle all known exceptions from the methods that they call. Although numerous checked exceptions are certainly permissible in Java, things can get a bit unwieldly. For example:

public void sillyMethod() throws DataFormatException, InterruptedException, 
	IOException, SQLException, TimeoutException, ParseException {

Accordingly, there has been raging debate for years on whether to use checked or unchecked exceptions when writing libaries, for example. As is true with many such debates, the truth is that there really is no one-size-fits-all, across-the-board correct answer. Checked and unchecked exceptions each have their own advantages and disadvantages, so the decision about which to use largely depends on the situation and context.

Q: Describe Generics and provide examples of generic methods and classes in Java.

Java generics enable programmers to specify, with a single method or class declaration, functionality that can be applied to multiple different data types. Generics also provide compile-time type safety that allows programmers to catch invalid types at compile time.

Here, for example, is a generic method that uses <E> as the placeholder for a generic type:

public <E> void printArray( E[] inputArray ) {
    // Display array elements              
    for ( E element : inputArray ) {        
        System.out.printf( "%s ", element );

The above method could then be invoked with various types of arrays and would handle them all appropriately; e.g.:

// invoke generic printArray method with a Double array
Double[] doubleArray = { 1.1, 2.2, 3.3, 4.4 };

// invoke generic printArray method with a Character array
Character[] charArray = { 'H', 'E', 'L', 'L', 'O' };

There may be times, though, when you want to restrict the kinds of types that are allowed to be passed to a generic type parameter. For example, a method that operates on numbers might only want to accept instances of Number or its subclasses. This is accomplished in generic using a bounded type parameter, which list the type parameter’s name followed by the extends keyword. For example:

// determines the largest of three Comparable objects
public static <T extends Comparable<T>> T maximum(T x, T y, T z) {                      
  T max = x; // assume x is initially the largest       
  if ( y.compareTo( max ) > 0 ) {
     max = y; // y is the largest so far
  if ( z.compareTo( max ) > 0 ) {
     max = z; // z is the largest now                 
  return max; // returns the largest object   

As with generic methods, the type parameter section of a generic class can have one or more type parameters separated by commas. For example:

public class Cell<T> {
  private T val;

  public void set(T val) { this.val = val; }

  public T get() { return val; }

  public static void main(String[] args) {
     Cell<Integer> integerCell = new Box<Integer>();
     Cell<String> stringCell = new Box<String>();
     integerCell.add(new Integer(10));
     stringCell.add(new String("Hello World"));

     System.out.printf("Integer Value :%d\n\n", integerCell.get());
     System.out.printf("String Value :%s\n", stringCell.get());

Q: What is multiple inheritance? What are some potential problems with it and why has Java traditionally not supported it? How has this changed with the release of Java 8?

Multiple inheritance is a feature of some object-oriented computer programming languages in which an object or class can inherit characteristics and features from more than one parent object or parent class. It is distinct from single inheritance, where an object or class may only inherit from one particular object or class.

Until Java 8, Java only supported single inheritance. We’ll discuss Java 8’s quasi-support for multiple inheritance shortly, but first let’s understand what problems can result from multiple inheritance and why it has been so heavily avoided in Java.

The main argument against multiple inheritance is the complexity, and potential ambiguity, that it can introduce. This is most typically exemplified by the commonly cited “diamond problem”, whereby classes B and C inherit from class A, and class D inherits from both classes B and C. Ambiguity arises if there is a method in A that both B and C have overridden. If D does not override it, then which version of the method does it inherit; that of B, or that of C?

Let’s consider a simple example. A university has people who are affiliated with it. Some are students, some are faculty members, some are administrators, and so on. So a simple inheritance scheme might have different types of people in different roles, all of whom inherit from one common “Person” class. The Person class could define an abstract getRole() method which would then be overridden by its subclasses to return the correct role type, i.e.:

But now what happens if we want to model a the role of a Teaching Assistant (TA)? Typically, a TA is both a grad student and a faculty member. This yields the classic diamond problem of multiple inheritance and the resulting ambiguity regarding the TA’s getRole() method:

(Incidentally, note the diamond shape of the above inheritance diagram, which is why this is referred to as the “diamond problem”.)

Which getRole() implementation should the TA inherit? That of the Faculty Member or that of the Grad Student? The simple answer might be to have the TA class override the getRole() method and return newly-defined role called “TA”. But that answer is also imperfect as it would hide the fact that a TA is, in fact, both a faculty member and a grad student. There are multiple design approaches and patterns for addressing this type of situation without multiple inheritance, which is why some languages (Java being one of them) have made the decision to simply steer clear of multiple inheritance.

Java 8, however, introduces a form of quasi-support for multiple inheritance by allowing default methods to be specified on interfaces (prior to Java 8, only method signatures, not method definitions, were allowed on interfaces). Since Java does allow a single class to implement multiple interfaces (whereas a single class can only extend a single parent class), the allowance in Java 8 for method definitions in an interface introduces the potential for the diamond problem in Java for the first time.

For example, if A, B, and C are interfaces, B and C can each provide a different implementation to an abstract method of A, causing the diamond problem for any class D that implements B and C. Either class D must reimplement the method (the body of which can simply forward the call to one of the super implementations), or the ambiguity will be rejected as a compile error.

Gourmet Java

Here we present some more advanced concepts and issues that master Java programmers can be expected to be familiar with.

Q: How can you exit a thread reliably using an external condition variable?

Sometimes developers want to terminate a thread when an external condition becomes true. Consider the following example of a bus thread that continues to drive indefinitely until the pleaseStop variable becomes true.

boolean pleaseStop = false; // The bus pull cord.

public void pleaseStopTheBus() {
    pleaseStop = true;

public void startTheBus() {
    new Thread("bus") {
        public void run() {
            // Infinitely drive the bus.
            while (!pleaseStop) {
                // Take some time driving to the next stop.
            pleaseStop = false; // Reset pull cord.

Seems straightforward. However, Java doesn’t guarantee variable synchronization implicitly between thread boundaries, so this thread is not guaranteed to exit reliably, causing a lot of head scratching with less experienced Java developers.

Getting the above code to work properly would require synchronizing the threads as follows:

volatile boolean pleaseStop = false; // The bus pull cord.
Object driver = new Object(); // We can synchronize on any Java object.

public void pleaseStopTheBus() {
	// Here in "thread 1", synchronize on the driver object
    synchronized (driver) {
        pleaseStop = true;

public void startTheBus() {
    new Thread("bus") {
        public void run() {
            // Infinitely drive the bus.
            while (true) {
				// And here in "thread 2", also synchronize on the driver object
                synchronized (driver) {
                    if (pleaseStop) {
                        pleaseStop = false; // Reset pull cord.
                        return; // Bus stopped.
                // Take some time driving to the next stop.

Q: How can null be problematic and how can you avoid its pitfalls?

For one thing, null is often ambiguous. It might be used to indicate success or failure. Or it might be used to indicate absence of a value. Or it might actually be a valid value in some contexts.

And even if one knows the meaning of null in a particular context, it can still cause trouble if the hapless developer forgets to check for it before de-referencing it, thereby triggering a NullPointerException.

One of the most common and effective techniques for avoiding these issues is to use meaningful, non-null defaults. In other words, simply avoid using null to the extent that you can. Avoid setting variables to null and avoid returning null from methods whenever possible (e.g., return an empty list rather than null).

In addition, as of JDK 8, Java has introduced support for the Optional<T> class (or if you’re using an earlier version of Java, you can use the Optional<T> class in the Guava libraries. Optional<T> represents and wraps absence and presence with a value. While Optional adds a bit more ceremony to your code, by forcing you to unwrap the Optional to obtain the non-null value, it avoids what might otherwise result in a NullPointerException.

Q: What is “boxing” and what are some of its problems to beware of?

Java’s primitive types are long, int, short, float, double, char, byte and boolean. Often it’s desirable to store primitive values as objects in various data structures that only accept objects such as ArrayList, HashMap, etc. So Java introduced the concept of “boxing” which boxes up primitives into object class equivalents, e.g., Integer for int, Float for float, and Boolean for boolean. Of course, as objects, they incur the overhead of object allocation, memory bloat and method calls, but they do achieve their purpose at some expense.

“Autoboxing” is the automatic conversion by the compiler of primitives to boxed objects and vice versa. This is simply a convenience, e.g.:

ArrayList<Integer> ints = new ArrayList<Integer>();

// Autoboxing.  Compiler automatically converts "35" into a boxed Integer.

// So the above is equivalent to:  ints.add(new Integer(35));

Despite their convenience, though, boxed objects are notorious for introducing gnarly bugs, especially for less experienced Java developers.

For one thing, consider this:

System.out.println(new Integer(5) == new Integer(5));   // false

In the above line of code, we are comparing the identity of two Integer objects. Since each new Integer(5) creates a new object, one new Integer(5) will not equal another new Integer(5).

But even more troubling is the following seemingly inexplicable distinction:

System.out.println(Integer.valueOf(127) == Integer.valueOf(127));   // true
System.out.println(Integer.valueOf(128) == Integer.valueOf(128));   // false

Huh? How can one of those be true and the other be false? That doesn’t seem to make any sense. Indeed, the answer is quite subtle.

As explained in an easily overlooked note in the Javadoc for the Integer class, the valueOf() method method caches Integer objects for values in the range -128 to 127, inclusive, and may cache other values outside of this range as well. Therefore, the Integer object returned by one call to Integer.valueOf(127) will match the Integer object returned by another call to Integer.valueOf(127), since it is cached. But outside the range -128 to 127, Integer.valueOf() calls, even for the same value, will not necessarily return the same Integer object (since they are not necessarily cached).

It’s also important to note that computation using boxed objects can take around 6 times longer than using primitives, as can be evidenced by way of the following benchmarking code:

void sum() {
	Long sum = 0L; // Swap "Long" for "long" and speed dramatically improves.
	for (long i = 0; i <= Integer.MAX_VALUE; i++) {
		sum += i;

Executing the above code with sum declared as Long took 6547ms whereas the same code with sum declared as long (i.e., the primitive type) took only 1138ms.

Q: What is type erasure?

The addition of Generics to the language has not been without its problems. A particularly thorny issue with Java Generics is that of type erasure.

As an example, consider the following code snippet:

List<String> a = new ArrayList<String>();
List<Integer> b = new ArrayList<Integer>();
return a.getClass() == b.getClass();  // returns true??!!

This should presumably return false since a and b are different class types (i.e., ArrayList<String> vs. ArrayList<Integer>), yet it returns true. Why?

The culprit here is type erasure. Once the above code passes all Java compiler validation, the compiler erases the String and Integer types in the above example, to maintain backward compatibility with older JDKs. The above code is therefore converted to the following by the Java compiler:

List a = new ArrayList();
List b = new ArrayList();
return a.getClass() == b.getClass();  // returns true (understandably)

And thus, in the compiled code, a and b are both simply untyped ArrayList objects, and the fact that one was an ArrayList<String> and the other was an ArrayList<Integer> is lost. Although in practice type erasure-related issues rarely cause problems for developers, it is an important issue to be aware of and can in certain cases lead to really gnarly bugs.

Q: Describe the Observer pattern and how to use it in Java. Provide an example.

The Observer pattern lets objects sign up to receive notifications from an observed object when it changes. Java has built-in support with the Observable class and Observer interface.

Here’s a simple example of an implementation of an Observable:

public class Exhibitionist {
	MyObservable myObservable = new MyObservable();

	public Exhibitionist() {}

	public java.util.Observable getObservable() {
		return myObservable;

	private void trigger(String condition) {

	private class MyObservable extends java.util.Observable {
		private void invalidate() {

And here’s a corresponding Observer example:

public class Voyeur implements Observer {

	public Voyeur(Exhibitionist exhibitionist) {
		// Register ourselves as interested in the Exhibitionist.
	public void update(Observable o, Object arg) {
		// Called when the observable notifies its observers.

There are a couple of downsides of using this though:

  1. The observed class must extend Observable and thus prevents it from extending a more desirable class (refer to our earlier discussion of multiple inheritance)
  2. Observed and observer classes are tightly coupled causing potential for NullPointerException’s if you are not careful.

To circumvent the first issue, an advanced developer can use a proxy (delegate) Observable object instead of extending it. To address the second issue, one can use a loosely coupled publish-subscribe pattern. For example, you might use Google’s Guava Library EventBus system where objects connect to a middleman.

Q: Describe strong, soft, and weak references in Java. When, why, and how would you use each?

In Java, when you allocate a new object and assign its reference (simply a pointer) to a variable, a strong reference is created by default; e.g.:

String name = new String(); // Strong reference

There are, however, two additional reference strengths in Java that you can specify explicitly: SoftReference and WeakReference. (There is actually one additional reference strength in Java which is known as a PhantomReference. This is so rarely used, though, that even highly experienced Java developers will most likely not be familiar with it, so we omit it from our discussion here.)

Why are soft and weak references needed and when are they useful?

Java’s garbage collector (GC) is a background process that periodically runs to free “dead” objects (one’s without strong references) from your application’s memory heap. Although the GC sometimes gives the impression of being a magical black box, it really isn’t that magical after all. Sometimes you have to help it out to prevent memory from filling up.

More specifically, the GC won’t free objects that are strongly reachable from a chain of strongly referenced objects. What that simply means is that, if the GC still thinks an object is needed, it leaves it alone, which is normally what you want (i.e., you don’t want an object you need to suddenly disappear when the GC kicks in).

But sometimes strong references are too strong which is where soft and weak references can come in handy. Specifically:

  • SoftReference objects are cleared at the discretion of the garbage collector in response to memory demand. Soft references are most often used to implement memory-sensitive caches.
  • WeakReference objects do not prevent their referents from being made finalizable, finalized, and then reclaimed. Weak references are most often used to implement canonicalized mappings.

Wrap up

Java continues to survive and thrive as a dominant and popular language. But as might be expected with any language that has gone through so many iterations, it has many nuances and subtleties that not all developers are familiar with. Moreover, the ever-increasing breadth of Java’s capabilities requires a great deal of experience to fully appreciate. Those who have mastered the language can therefore have a significant positive impact on your team’s productivity and your system’s performance, scalability, and stability.

The questions and tips presented herein can be valuable aids in identifying true Java masters. We hope you find them to be a useful foundation for “separating the wheat from the chaff” in your quest for the elite few among Java developers. Yet it is important to remember that these are merely intended as tools to be incorporated into the larger context of your overall recruiting toolbox and strategy.

(One final note: if your interest in Java is Android-centric, we suggest you read our Insider’s Guide to Android Interviewing as well.)

Top Java Developers are in high demand.

Get Started