How to respond to overly specific technical questions in an inteview?

Question

During a recent job interview I was asked what I consider to be overly technical specific questions. These questions are too specific because generally it is knowledge I don't need to store in my brain.

For example, I am looking for a Software Developer position and I was asked many specific questions for an hour about specific Java API methods, constructors, etc. There are thousands of these and I work in many different programming languages so I don't believe it is possible to memorize all API methods etc. Also, looking up the correct API takes seconds as long as you know its functionality.

My response to many of the questions was, "I don't know that off the top of my head. When I program I have a monitor for my IDE's and another monitor for my API's, I don't attempt to memorize all of them."

A couple questions come from this:

1. Is there a better response I could have used?
2. Are these acceptable interview questions and should I expect more of them in future interviews with this company or others?

Answer 1

1. I'd probably suggest something a bit more diplomatic as well as having more details as some may see this as a, "Don't bother me with trivial details, puny non-technical person," attitude. While the general idea is great, I'd mention which sites do you use for looking up the API as well as probably walking through an example where I got to know something fairly deep in the technology stack that shows that I'm not afraid to get my hands dirty.

2. The question is acceptable and in a way is a test. Will you give a way to handle these that makes the person go, "Ah, so you will take control here and change how I try to run this," or will you try to answer the question asked and blindly follow orders? Would you seek to clarify the question or the intention behind the question? I've had similar hours spent answering technical questions though there is something to being honest about not knowing something right now though you can look up the answer somewhere. I would think these questions are likely to be most common for intermediate developers, those with at least a year of experience but less than a decade for a general ballpark, where there is some expertise to be demonstrated yet not a great mastery of development in general that would be reserved for the more senior people.

Answer 2

Is there a better response I could have used?

Your answer was just fine. The important thing is that you're polite about it and make it clear that you're not in the business of memorizing documentation. The size and complexity of APIs have exploded over the last 20 years, and documentation -- especially the kind you can search automatically -- exists for a reason. Clueful interviewers will understand this.

Are these acceptable interview questions and should I expect more of them in future interviews with this company or others?

Any question that isn't illegal to ask where you live is "acceptable." Any question you get asked is also valuable intelligence about the candidate company.

I call the kinds of questions you got asked "manual page questions," because they're the sort of things you know about, have forgotten the details and can look up when needed. It's one thing to be asked a few in the context of larger discussions. Getting peppered with them in a rapid-fire manner for a solid hour is a red flag that the interviewer doesn't have anything substantive to discuss with you. It may also indicate that the range of things he asked about is his entire little world.

Your profile says you're in your mid-20s, which may also have something to do with it. I'm in my mid-40s and have noticed that I was asked more of those sorts of questions earlier in my career and fewer as time went on. When you're young, you have more capacity to memorize things and less experience from which you will have gathered the kind of wisdom that's fodder for really great discussions on interviews. That may not make a lot of sense right now, but trust me, it will in another 20 years.

Answer 3

I was asked many specific questions for an hour about specific Java API methods, constructors, etc

Above sounds like they were testing your fluency in particular API subset, see related question at Programmers: Is it a really required skill to program without API documentation?

^{...what it is to be fluent? It's when for someone looking at you it appears as if you code as you type... ...As if the right code simply flows from your fingers to the screen. As if you don't check the API docs, tutorials and manuals. Actually, you do check them all, but that's invisible because it's all in your head. You've got all the knowledge you need right there in your brain - charged, loaded and ready to use. ...That's fluent knowledge. It's when it takes you a minute to do what takes newbie an hour...}

As for your answer, it's probably best one can come up with when missing a "fluency test". Making honest point about not knowing it on top of your head is hard to beat, and for sure it's much much better than lame attempts to pretend a fluency when you don't have it "oh I knew that all a week ago but somehow forgot" - fluency doesn't evaporate in a week (it does in a several months without practice though).

Showing a fairly reasonable approach and lack of fear when working with API you rarely use gives you yet another bonus point - even if they target the API you just missed, they get an idea that you are capable of working with it anyway and even that you may become fluent after sufficient practice.

If I understand correctly, you didn't complain - that's a good move. Since you don't really know if fluency is important to them, it is just safer to avoid saying something that may sound like you don't understand / underestimate it.

---

One thing worth checking after the interview is whether API they tested you with is bragged about in your resume. If it is, this could be quite a bad sign. Just think of it, they probably picked your resume because of it, they were intentionally testing the match between what is stated in resume and the demonstrated skill. Failing fluency test in that case is something different from a routine failure for yet another randomly picked API (I failed an interview like that once, wouldn't want to repeat).

Overall, per my experience at both sides of interview table, fluency is desired and important skill, but rarely a determining one - as mentioned above, it is widely understood that skilled professional can acquire it through practice. These are acceptable interview questions and you should not be surprised with them in future interviews.

Answer 4

I don't attempt to memorize all of them

Memorization is only one way that knowledge can get into your mind. Another way is through sufficiently repeated exposure that engenders innate familiarity.

For example, I have never set out to memorize the maximum value that a signed 32 bit integer can take, yet I know that it's just over 2 billion, and I'm fairly sure the exact value starts 2147.... How? Because I've seen it enough times.

Now, admittedly,

I was asked many specific questions for an hour about specific Java API methods, constructors, etc

sounds like a lot of detailed questioning; but being asked a few such questions could simply be the interviewer(s) checking you have at least some vague acquaintance with these APIs.

Answer 5

I answer these questions by telling what I do know. For example, if asked which Java class is used to read a text file line by line, and I didn't know (I don't, even though I write Java daily), I would answer that I didn't know, but that I did know there were streams for reading binary and readers for reading text, and then say something about text encoding. All modern languages that support non-ASCII text have similar facilities.

Answer 6

I never commit to memory anything that can easily be looked up in a book

The value of a college education is not the learning of many facts but the training of the mind to think. - Albert Einstein.

I wouldn't worry about giving correct answers, but how you approach giving an answer at all. I'd hazard a guess that they are aware of the relative impracticality of the question so they're looking out for something else: Approach.

On one memorable occasion, I've been in exactly the same situation. While interviewing for a Senior Systems Architect/Integrator position, I was asked a very technical question in a technology I had been very clear was not my strong suit at the start of our session. When the question came, I told them that while I couldn't give them specific pieces of the technology that would be ideal for the problem, I offered alternatives in other technologies that I was comfortable with. I even proffered a likely solution in the tech I was weak in, based on residual memory and how I felt it should likely work. The interviewer proceeded to offer his opinion on approach and we moved on

At the end of the session, my interviewer stated he was impressed with my performance, not because I had all the right API calls locked down pat; Because he could see that I was working out in my head, a path to the solution to the problem. He said something along the lines of not giving him crammed or canned answers and how he could observe that I was working on actually solving the problem rather than giving him something regurgitated from a textbook. I got the offer (and turned it down for another).

While your current response is fine, you should at the minimum approach the problem with the aim of providing viable alternatives to the absolute correct answer, based on experience, residual memory whatever you have. Make reasonable and educated guesses that shows that you're firing on all cylinders and you're a ferocious problem solver. Not trying at all might not hurt you, but it really wouldn't help either

You'll be fine.

Answer 7

I will answer as I have been through the same situation myself and left interviews wondering what was I doing in there... and with my tongue in cheek I almost know which geographical demographic of interviewers you are talking about :)

A lot depends on the level that which you are applying at. If you say you have worked with Sun MS in the past and wrote a few public APIs then yes, these are valid questions and you should have been able to at least answer it bare bones. If not, then is the position you are applying for, such a role (writing public APIs) ? If yes, then yes, these are valid questions as a fair background in writing public APIs is required. If it was just another technical firm, then meh, the interviewer was probably trying to show you how much s/he knows. These are typical ego trips most interviewers with with substandard intelligence or with super intelligence will ask.

These are not typical interview questions unless you are applying for positions involving writing open source software and such, as discussed above. Most firms I have interviewed with in USA and whose interview panels I have been on, dont look for this level of detail. I would run from any firm which gets down to me remembering how an iterator is coded in java 7.

Answer 8

Anyone with limited knowledge can go through an existing code base and pick anything to "quiz" the next candidate about. It could be an indication of a place to avoid.

You should stick to your explanation that you may not know all these details off the top of your head, but are willing and capable of finding solutions. This is much better than someone who may try and fake it through the interview and pretend they are intimately familiar with all of it.

I hope they aren't resorting to playing head games during the interview. Programming is hard enough, so they should be spending their efforts on attracting the right people. They're much easier to find that way.

Answer 9

Is there a better response I could have used?

Addressing the meta-issue is generally a good plan. One way is usually to point out how you address the whole family of questions - which you did by explaining how you do research this type of question on the job.

When you have spotted a trend, I'd see if there's a way to backup and get to what the interviewer is asking another way... for example - "This the third question you've asked me about specific details of particular Java APIs. Is there a way I can help to back up and address your bigger questions? Are you trying to vet that I am an able developer in Java? Would it help if I explain how I treat a Java development project and what makes it different from the other languages that I routinely program in?"

Then give the interviewer time to re-direct, or otherwise comment.

Are these acceptable interview questions and should I expect more of them in future interviews with this company or others?

My initial bet is that in this case, the interviewer comes from a not-Java context. There are some cases where developers need memorized knowledge of certain aspects of a language. Java APIs just doesn't happen to be the right format for this.

You certainly will find that some interviewers interview this way, and about the best you can do is pivot to providing them something you can answer. As long as it's related to work and work-duties, there's no real "unacceptable" question. One interesting point is that crazy-sounding questions can be a good indicator that you should follow up. For example, I'd be wondering whether:

1. Developers really do need to memorize APIs because the IDE options are extremely restricted and don't offer auto complete.
2. This particular interviewer is quite old school or out of touch with the standard skill set of a Java developer
3. The whole company is focused on this kind of detail.

The answer may well spell out whether or not you even want to work in this company. It's worth asking.

Answer 10

I've muffed a number of job interviews by people that have asked highly technical questions. In the meantime, someone who didn't even know what database and/or language their system was written in would simply ask me: can you fix this, yes or no? I would get, and keep, those jobs, often for years. So this raises a bit of a question: if someone knows their way around Java APIs, what happens when they're confronted with a Sarbox rule that has to be implemented in code? Do they understand business as well as their language(s)? Often this is a hint that the workgroup is not focused on the bigger picture.

Answer 11

As an interviewee, you're not in the position to dictate about how you should be questioned.

So the best you can do is, if you don't know the detailed technical answer they are looking for, is "I do not know; I do not have that API function memorized". That's it! It's not the end of the world. No sniveling, no pouting, just a calm, "I don't know".

So you cannot answer. Who cares? They are going to ask the same questions of other candidates being interviewed. If someone has all that stuff memorized, then by golly, that is the person they are looking for. More power to him or her!

Maybe they are looking for someone who has recent, in-depth experience with very specific API's and can just spew out the code like it's in the cuff of his or her sleeve. In other words, a quintessential Java monkey.

On the other hand, if they find that none of the candidates has even 10% of it memorized, then they will just have to deal with the aftermath of their inane knowledge sampling method which hasn't yielded any useful data. This is their problem, not yours.

If you complain during the interview, then you're seen as a complainer, regardless of the validity of the complaints. This is true even if they actually listen to the content of the complaint and change their interviewing method. It will benefit the next interviewee, not you.

And that is unlikely, because chances are that whoever is doing the interviewing firmly believes in doing it that way. In other words, "thank you for your valuable opinion about our interview process. Next!"