Anthony DePalma

+ Follow
since Sep 20, 2015
Merit badge: grant badges
For More
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Anthony DePalma

Hi Brian,

Excellent question! I agree with your perspective 100%, in fact on the first page of the book I stress the importance of answering something in your own words rather than memorizing any sort of definition. A memorized answer doesn't tell the interviewer anything different from one candidate to the next.

I always like to follow up a technical question with a why to probe into that level of understanding. Yes that's an example of an immutable object, why would you go through the trouble of making them? None of the 150+ questions are syntax questions or even yes or no questions. They are all designed to probe for information about the candidates ability to explain the concepts. So for example, when would you choose composition over inheritance when planning an object hierarchy, rather than simply define composition or inheritance.

In my experience, an interview that flows like a conversation is more effective than one strictly designed to test, because you can learn a little bit more about whats driving the candidates answers.
8 years ago
Hi Bijesh,

I was talking about architect interviews in another thread. This guide would help with the Java aspect of an architect interview, but its important to remember that an archiect is expected to know a wider variety of topics that are related or tangential to development.

For example, I would expect an architect to pass all of the senior level questions regarding Java, but also answer questions such as the software development lifecycle, agile methodologies, source control, database design, high level server configuration, etc. These kinds of topics are outside the scope of this guide, so you would need to supplement you're knowledge elsewhere. Unfortunately I don't have any good recommendations for an architect guide, because the range of topics can vary so greatly from job to job.
8 years ago
Haha, theres no such thing as asking an insulting question! In fact, asking a simple question is a great way to break some of the tension and stress from a technical screen. I usually ask what the static keyword means as my first question. I have been surprised on more than one occasion when a senior level candidate could not answer it. Its not unheard of that people put things on their resume just to make it look better, so asking simple questions is a great way to weed out the non-contenders and loosen up the real contenders with a freebie.

If its obvious that a senior level understands the concepts, I won't spend too much time on the simple questions. During an interview you are trying to assess the depth of someones knowledge, so if they are blowing through the easy questions I'll try to keep pushing until I hit the limit of their knowledge. But, I would be immediately suspicious of someone who struggles with simple questions and has no problem with the difficult ones. That could indicate that they were informed of the interview process ahead of time or something else that doesn't make sense. So don't worry about insulting anyone, I'm sure they'd appreciate a smooth start!
8 years ago
Hi Paul,

This book is geared towards an entry level or a senior level position. Of course, an architect would still benefit from it, but its important to remember that the scope of knowledge expected from an architect is much greater than core java concepts. For example, I would expect an architect to pass all of the senior level questions regarding Java, but also answer questions outside of Java, such as the software development lifecycle, agile methodologies, source control, database design, high level server configuration, etc.
8 years ago
Hi Gaurav,

There are certain APIs that are always good to know. I would recommend studying:

1) Every method in the Object class
2) The different types of collections in the Java Collections Framework
3) The JDBC APIs
4) The Servlet APIs
5) Concurrency APIs (Both standard APIs like Thread and Runnable, and the newer Executor Framework)
6) The Reflection classes

File I/O is of course useful as well, but the new NIO features are a little more niche. I think you might benefit from a website that lists all of the new features that were released from 1.6 on and just read a little bit about each topic so you won't be caught off guard in future interviews. Even if you don't know them in detail, it will help to show that you are familiar with them.
8 years ago
Hi Kaleem,

I wouldn't recommend this book for common coding mistakes or best practices, I would recommend a book like Effective Java, which is an excellent resource for that. This book is more of a high level resource, although it does address some common misconceptions like method overriding vs overloading, when to use abstract classes vs interfaces, and when to use composition vs inheritance, etc.
8 years ago
Hi Viktor,

I assume you are talking about Gayle McDowell's book? In that case, her book is certainly very informative, however I found the amount of information inside to be a little overwhelming at just shy of 700 pages hardcover. By comparison, I wanted to write a book that could be read in one sitting, and at the same time portray enough information to prepare you for an interview. In that sense, I would view both books as complimentary rather than competitive, because its easy to get lost in that much information and miss out on what the majority of interviews will focus on.

One of the hardest parts about writing my book was using as few sentences (and even as few words) as possible to get a crystal clear point across. But because of that, I found it much easier to digest and understand the content - not to mention relaying it back to an interviewer. Interviews are very time sensitive, so its important to answer an interviewers questions with as little fluff as possible, since they will very quickly see through anything that isn't the answer they are looking for. So the reason I present all the content in interview-sized chunks is to make that sort of interaction familiar to the readers.
8 years ago
Hi Rafael,

The reason I wrote this book was so that I would have a reference that I could use across different interviews, so I certainly hope it accomplishes the same for you!
8 years ago
Hi Jeremy,

Thats a great question. Unfortunately, this is one aspect of programming that is extremely difficult to capture in an interview. Even with interviews that ask you to code on the spot, its very unrealistic to expect that code to be pretty. Candidates are rushed, stressed, and pressed for time - in fact it can even hurt you to spend too much time making your code pretty if it doesn't work. And once it does, the interviewers are usually more interested in the next question. In the real world, refactoring is an essential part of programming, but that comes after the code because you get a better picture as the code is developed than you do right from the start.

However, there are some questions that can hint at a candidates mindset about this. For example, people usually ask about the four visibility modifiers and their differences. My follow up question to this is always: Why not just make everything public? If a candidate doesn't have a good answer to that, I know they are not concerned about information hiding, which doesn't bode well for the code they would write. The same goes for immutable objects - I'm sure you can tell me what it is, but why would you go through the trouble of making them? The ones who answer these kind of 'why' questions confidently tend to be the ones who write the cleanest code. I had an interviewer ask me once what my philosophy on coding was, which I thought was a great way to see how I really felt about programming. In the end, you'll have to look for clues to make an educated guess about the type of code they'll write. This is also why I advise against memorizing answers - I can't learn much about you if I hear the same thing from everyone else.

But I think the main reason code cleanliness is not critical in an interview is because a lot of good coding practices can be taught. In fact I make all my new hires read a coding standards document (if your company doesnt have one, I'm sure it would be a great help). Also I tend to be strict with the code review process - once people know that, they are more careful with future commits, just to avoid the hassle. Some things can be auto formatted of course, but I believe thats only a partial solution. If someone uses short obscure variable names, you can bet I'll make them refactor it to be more readable. In the end, its probably a gap in management if developers have these problems. But I have found that people are eager to learn how to write clean code, especially if they are surrounded by clean code. Messy code tends to stay messy, and clean code at least becomes obvious when its getting messy.

I can go on for days about clean code haha, but I better stop now!
8 years ago
Hi Doug,

Of course! I would hope the technical interviewers knew the answers to the questions they were asking haha. But the real value is having a big pool of questions to choose from. Again, this is all at the discretion of the interviewers, but it allows them to pick and choose questions that are more relevant to their position and take the question in different directions or towards related discussions, which gives the interview a nice flow to it.
8 years ago
Hi Arvi,

In the interviews I've conducted, we have taken the approach of starting off with the same basic questions, and probing further depending on the level of the position. For example, we might ask a beginner about garbage collection in general, but push further into the difference reference types or the division of heap memory for a senior. We might even ask the beginner those questions as well just to test the breadth of their knowledge, but we wouldn't hold it against them if they failed to answer correctly.

So while the book has questions for both a beginner and a senior level, it doesn't differentiate between the two because that is generally at the discretion of the company and their hiring practices. However, the book loosely differentiates between the more basic topics at the beginning and more advanced towards the end, so that can be used as a rough guide.
8 years ago
Hi Tim,

Every interview is a different experience for sure. My first interview was a conference room with 4 different people drilling me with technical questions. My second interview was a phone call with zero technical questions. My last one was seven different interviews with seven different people for the same job! But my method of preparation was the same for all of them.

First and most importantly, you need to be solid on your fundamentals. I would expect that to be necessary on any interview. I'd actually be concerned if they didn't ask me any thing about that - in fact I went on two interviews that didn't ask me any core java questions (and didn't know me beforehand), and both of them turned out to be bad news.

Aside from that, the rest of the interview usually revolve around two things: Your ability to communicate and your ability to solve problems.

Communication comes easier for some than others, but its a skill that can be learned through practice. Practice answering non-technical questions out loud, things like your prior experience, your weaknesses and strengths, reasons for leaving your job. I have a list of these types of questions in the end of my book. They ask these questions because they are interested in you, so make your answers interesting!

Problem solving is the hardest aspect of an interview, because it can really only come from lots of practice and experience. There are great resources such as, which can help with the building blocks for problem solving. But there is no shortcut for it.

In the end, it comes down to confidence. If you are confident in your fundamentals, and your ability to communicate, you will have a great chance of passing an interview.
8 years ago
Hi Riddhi,

Congrats on moving from QA to development! I have seen both sides and I must say, programming is more fun.

I think that you should start out with a book thats more geared towards java basics and object-oriented concepts. I recommended the Head First Java books in another question as a great beginner book. Without reading something like that, I would fear that my book is too succinct for a non-developer to benefit from on its own. However, I do believe it is a great compliment to a beginner book, because it removes a lot of the fluff and helps people focus on what topics are important for an interview.

I hope this helps, and good luck with your transition!
8 years ago
Hi Ishita,

Thats a very interesting question! I have certainly met people like your subordinate, who program because they have to, rather than because they want to. However, I don't believe that he doesn't have any opportunities to work on new projects. A person who truly enjoys their job will make new projects, whether its for a company or in their spare time.

But its a frustrating scenario, because I have felt that the more I learned about the language, the more I enjoyed working with it and applying that knowledge. I have often wondered if those types of people would follow the same path if they only learned more. But the more I think about it, I didn't learn more because I was forced to, I learned more because I wanted to. If they don't want to learn, there is not much you can for them.

On the other hand, it could just be that he is bored and that solving random exercises doesn't interest him. It would be an interesting test to see if he could write code that would solve or lessen some of the work he is doing. For instance, a program to automatically test something that he tests manually, so he at least feels some utility to these things he is writing. I obviously don't know much about his day to day work, but I can tell if he copy/pastes the answers to your problems, he at least enjoys solving problems in the laziest way possible haha. Maybe you can find a way to put that to use!
8 years ago
I am personally not a fan of tricky interview questions because of the same reasons you mentioned - they don't mirror problems you face in the real world, and I would be suspicious of anyone that knew the answer because it likely meant that they heard it before, rather than knew how to understand it. It simply isn't normal for someone to be able to spit out a tricky answer to a problem they've never heard. In real life, I wouldn't trust the solution!

However, some interviewers still ask these types of questions. When I was interviewing for my first job, after all the technical questions they asked me how many pennies would stack up to the empire state building. I had heard it before so I went through the motions of how many pennies per inch, per foot, per floor ect. Then they asked me another question about ferrying weighted people across a lake with a canoe.. something I hadn't heard before. I did my best to talk out loud and come up with a solution. It turns out my solution wasn't the best one, but it was obvious that they didn't care. They were more interested in me attempting the problem than actually solving the problem.

So, treat these types of questions not as tricks but rather as probes to see how you approach problems. The worst thing you can do is sit silently. Talk out loud, ask questions, spitball ideas, this is how problems are solved in real life. If you are solid on the fundamentals, I would have a hard time letting a trick question hold much weight.
8 years ago