52

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?
  • 37
    For the benefit of non-technical readers: APIs are application programming interfaces, which are the methods used for software developers to use the tools in their toolboxes. The collective documentation for these can run into many thousands of pages. IDEs are integrated development environments, which are tools used for doing programming. Many IDEs have facilities to look up information in the documentation automatically and prompt the programmer so they don't have to dig through all of the documentation manually. – Blrfl Apr 2 '13 at 20:40
  • 14
    I hope you had much more discussion about actual development too. I have zero interest ever working for a company which bases their developer's development skills on trivia tests. – enderland Apr 2 '13 at 22:34

11 Answers 11

31
  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.

  • 3
    Agreed; these questions are often tests. I like to see if people know where to look things up & what their balance is for keeping details in their head versus reclaiming that space (and whether they're aware of that). I would add that a good strategy for an answer would not be to say "I don't attempt to memorize all of them" but instead to say why that is the case, and to counter the question with something like "The intricacies of that method are tricky; I don't try to memorize them all. What specific issue with it would you like me to talk about?" (But an hour of this is a bit much.) – jcmeloni Apr 2 '13 at 19:40
33

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.

  • 5
    You make a good point about the size of APIs exploding. If I was interviewing someone for a C developer position 20 years ago, I'd expect them to have solid knowledge of the C standard library's API because it's not that big and it's hard to imagine someone with solid experience who didn't know it well through usage. Nowadays, though, you could easily work solidly with Java (or whatever) for years and not have cause to use the random selection of API classes and methods that an interview chooses to hit you with trivia questions about. – Carson63000 Apr 2 '13 at 23:15
  • 1
    @Carson63000 And yet, if it's a Java position and one claims to have some decent amount of experience with it, it would be pretty reasonable to expect, e.g., having the List interface memorized. – TC1 Apr 3 '13 at 21:09
  • 4
    @TC1 maybe when you use only one or two programming languages, but if you have to use about 10 on a daily basis, I don't think it's "reasonable". Personally, I rely on code completion for those kind of things, I trust I will be able to tell what E get(int index) is for when I see it. – yms Apr 3 '13 at 21:32
  • 1
    @TC1: How arcane the questions were would have a bearing on this, too. The acceptability of not knowing the details of the methods in List depends on what you're looking for. A good interviewer can work around a candidate being rusty because he's context switched a lot and ferret out whether or not he understands what a list is, how it's used and the kinds of methods implementations have. Clueful candidates can look that stuff up and get up to speed in under a minute. – Blrfl Apr 3 '13 at 22:07
  • 4
    @TC1 - I guess it depends how arcane the trivia is. I'm not a Java guy, but in .NET for instance, the IList interface has methods that I wouldn't be able to answer trivia questions on because I've seldom if ever had cause to use them, despite .NET having been the main platform I've worked with for quite a few years now. – Carson63000 Apr 3 '13 at 22:13
8

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.

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.

  • Well, personally I think if they are going to ask specific questions like this they really should ask a lot of different questions, otherwise it won't have a broad enough sample to mean anything significant. – Muhd May 7 '14 at 23:51
3

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.

3

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.

  • I think you misread the OP's opening sentence. The interviewer didn't ask "What do you consider to be overly technical questions?" The interviewer asked questions that the OP considered to be overly technical. – kevin cline Apr 3 '13 at 3:35
  • @kevincline, maybe I did. I was responding more to the body of OP's question, the part where he was asked several overly technical questions. Think my answer doesn't address that bit? – kolossus Apr 3 '13 at 3:43
2

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.

  • actually that is funny, I was asked how an iterator is coded. And yes it does give me a very bad feeling about the position. – Quinma Apr 2 '13 at 22:53
  • @Quinma - If you are not able to answer how to code an iterator then I am not sure I would want you on my team. That is a very basic and general question. And definitely does not fit the "overly specific technical question" you are asking about. – IDrinkandIKnowThings Apr 4 '13 at 12:49
  • @Chad, Your comment really shows what is so terrible about these sort of questions -- people think something is easy and basic when they know it and think it is hard when they don't. Life is more complex than that -- some people learn about A on the job, others learn about B and others C. I would bet the vast majority of Java developers do not know how to code their own iterator, though some might be able to guess if they remember the method names. – Muhd May 7 '14 at 2:00
  • ...and of course it's another thing that's trivial if you have access to a computer with an internet connection. – Muhd May 7 '14 at 2:15
1

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.

  • This answer explains less than several other answers that say the same thing but explain more. What information do you have that is different than the other answers? – IDrinkandIKnowThings Apr 4 '13 at 12:47
1

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.

-1

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.

-3

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!"

  • 3
    This is not how it works in the real world sir. – kolossus Apr 3 '13 at 3:23
  • 3
    @kolossus This is not how what works in the real world? Could you reformulate your comment to make it more effective? And what world am I in, if not the real one? – Kaz Apr 3 '13 at 3:38
  • 4
    OK I will. I'm not aware of any reasonable place of work in this business that will punish or fire one outrightly for not being a know-it-all. It's impractical and wasteful, IMO, to commit an entire body of knowledge to memory for the purposes of regurgitation. It's like trying to memorize the logarithmic tables. Why do it? – kolossus Apr 3 '13 at 3:58
  • 3
    @kolossus How many places of work are you "aware" of in this business and in what way? And, okay, so reasonable ones aren't like that but how about the UN-reasonable ones? In which category do you suppose is the workplace where OP interviewed? Reasonable or unreasonable? It does look like that place "punishes" interviewees for not being walking API reference manuals. You flunk the questions if you aren't! – Kaz Apr 3 '13 at 4:04
  • 4
    Complaining is likely to get you nowhere, at best. Offering a solution that perhaps doesn't answer the exact question asked during the interview is a very different matter. I for one doubt I'd want to work for a company which is so focused on one single way of doing something that the managers won't even stop to consider an alternative approach. ("How do you use exactly Facility X to perform Task Y in Language Z?" and "how would you approach Task Y using Facility X in Language Z?" are very different. The latter allows for using Facility ABC or even Language IJK if it is a better tool.) – a CVn Apr 3 '13 at 8:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.