Do you actually remember all of the different ways to progam via many API's

Question

I ask because I simply cant and when I go to a job interview I feel like a idiot. I simply cannot remember how to program in all of these different languages, let alone even one. I can remember the general idea of how to format a given program or how to do basic stuff, but I need access to the api whether it be from the Internet, a book or included documentation. Can you?

Answer 1

What do you mean by "all of these different languages"? If I am going to an interview for a job in a particular language that I haven't used in a while, I do some preparation ahead of time -- read up on the standard reference books for that language, code up a few small programs in that language that might appear in an interview (e.g. hello world, fizzbuzz, fibonacci both recursively and iteratively, etc).

There's actually a lot less language-specific knowledge than what you might think. Every language has its own frameworks and best practices for doing things, but programming is more about taking a really big problem and breaking it down into a series of small, easily-digestable tasks, each of which can be recursively broken down into smaller and smaller statements. When you've acquired this expertise in one (or a few) languages, those skills carry to new languages and new language frameworks.

Answer 2

APIs have grown so large and complex that it's fairly hard to keep up with them. And modern IDEs with code completion have made it less necessary to know the specifics of these APIs. So I (and I think many others) tend to rely more and more on IDEs to handle the details. I'm not so sure that's a bad thing.

Answer 3

Everyday stuff and language basics: Yes. Everything else - APIs, the syntax of less-used functions, and so on, I look up every day.

Answer 4

When you're in a job interview it is best to write pseudocode. It is more valuable to demonstrate your ability to solve the problem, than your ability to remember some specific API's nomenclature. Of course you should be able to recite the actual syntax if you are requested to, but usually your technique is more important than a language's implementation.

Answer 5

I see people (including myself) using IDEs with code completion. Remembering particular functions or methods is not the problem any more. Also, you can and have to refer to documentation for particular APIs.

The main challenge remains to conceptually understand the process of some higher level tasks, and to know, that there are methods for that and the order necessary to achieve some goal - not the particular name of a method.

Answer 6

I agree with all the above, with one caveat: if the employer is asking about a specific platform, you should probably know some of the buzzwords for that platform: MySQL geek-speak is slightly different from MS-SQL Server geek-speak (I'm always running into that when I search for something). And Mac is different from Linux, and so on.

But, do I know the API's off the top of my head? I don't think so!

Good luck!

Answer 7

this is what google is for

the main interview skill in this area is being able to know that this (the problem you are presented with) is something that there should be existing code for - in the OS, in the language runtime, for sale etc.

Then you should be able to formulate a reasonable search and make sense of the answers

Also saying 'ask stackoverflow' would , for me at least, be a reasonable response provided you told me (as the interviewer) what the question would be

Answer 8

I know that it is hard to remember all of the details.

This is why when I give a technical interview and I want to ask some specific programming questions, I give the candidate my laptop and ask him to write a small program that requires him to use a few tricky bits of the language (like a C++ template or a Perl list of hash references). I tell him that he can look up anything in the IDE help or on the web or even ask for a reference book.

I just want to see if he really can write Perl or PHP or C++ or if he is just good at talking.

Something that may have happened in an interview is miscommunication between who talked to the candidate and whoever talked to the interviewer. I've had to skip the Perl questions because the candidate didn't know it. He was good at C though. He just said he'd never done any Perl and that was okay with me. It's easy enough to learn. It did make my part of the interview shorter because I wasn't told he didn't know Perl.

But if you've got a language on your résumé then I think it's reasonable to expect you can turn out some code in 10 or 15 minutes if you've got access to references.

Answer 9

I'm completley with you on that.

I just blank out on interviews.

But I can program blindfoldedly when it is just for fun :)

Answer 10

Like mentioned in previous answers: it is not a good interviewing practice. However, sometimes it is sadly happening.

If you have the option, go for positions that value more on your general skills. If you do not, try to reload as much as you can to your memory, or try to impress the interviewers with you strength, make them understand what they really need.