Silly Questons

[Abdul Kader]

Some time in interview when they ask some basic (silly) question, i was unable to remember answer.Because most of the time we work in areas like Springs and Hibernate where creating connections are abstracted.

However some non mature interviewer was still asking to write a code for creating a JDBC connections...

In another interview a guy is asking what is the input param for the String.replace() is that a char or String.

I said,If that is a String then we can pass the input as String or if its a char then we need convert that input as char.

But he interested to know is that String or char, if that is what they expect then why we Need IDE ???. i don't believe in mug up all the java API's in your memory ....

How can we manage if this type of things happens.

[Mark Herschberg]

It's not silly to know fundamentals.

It's important to remember that there may be projects for which JDBC is more appropriate than Spring (e.g. spending a day fixing or update some JDBC based application that is not worth the time to convert into spring).

Why do we need to know math when we have calculators?

It's especially not silly to know the underlying operations upon which might order functions are built. Java may take care of memory management, file access and connection pooling for you, but you better know how it does that if you want to be a strong developer. If a candidate ever said to me, "I don't need to know this, the IDE does it for me," I'd write him off right there as someone who will only do the minimum amount of work and not try to gain a deeper understanding of a problem.

--Mark

[Deepak Bala]

Well the first question is quite ok. I would expect some one to know how you can access a DB using JDBC from a JVM.

It is ok if you cannot remember the exact method signature of methods. Some key methods require that their signatures be memorized but otherwise the IDE can help you there.

[Bear Bibeault]

Originally posted by Mark Herschberg:
It's not silly to know fundamentals.

Indeed. These types of questions on the fundamentals are completely relevant and fair (memorizing API, not so much).

A candidate who interviews with me better be able to speak eloquently about fundamentals or it will be a very short interview.

why we Need IDE ?

IDEs help us write our code faster and supply tools that make development easier. They are not meant to be used to avoid learning the fundamentals.
[ May 11, 2008: Message edited by: Bear Bibeault ]

[Ilja Preuss]

In my opinion, a question that requires you to memorize the API isn't unfair either. In my opinion "I don't fully remember - I think it's A, but to be sure, I had to look it up in the JavaDoc" would be a quite good answer. It tells me that the candidate is able and willing to communicate when he isn't sure about something (and doesn't simply make up answers to hide that he might miss some knowledge), and that he knows how and where to look up things.

[Bear Bibeault]

I don't know if I'd construe that as memorization as much as familiarization. The former I feel is not useful, but the latter is.

For example, I'd never ask "what's the second parameter to the Xyz.doWhatever() method", but might ask "What classes and packages would you consider using to fetch the content of a web page?"

[Nicholas Jordan]

I agree with all four respondents, though I have developed a style that looks for mastery of the basics over recital skills. I have never been in one of these interview situations - and go to great lengths to avoid them. Some issues in computer science have resolution in the exact details of an implementation. If an interviewer shred my hopes with a difficult issue, my intrinsic response is asking what the context of the issue is.

If no context can be provided as easily as the issue was set down, then that is not the place for me to work. Trying to convey that to an interviewer is not attainable by any skills I have.
[ May 11, 2008: Message edited by: Nicholas Jordan ]

[Andrew Monkhouse]

Originally posted by Abdul Kader:
[...] Because most of the time we work in areas like Springs and Hibernate where creating connections are abstracted.

Highlighting mine.

Since you seem to acknowledge that it is not 100% all of the time that other frameworks are used, then surely you must acknowledge that there are times when knowledge of JDBC can be useful.

Originally posted by Abdul Kader:
However some non mature interviewer was still asking to write a code for creating a JDBC connections...

It is hard, if not impossible, to avoid making snap judgments of people. I would caution you though to try and avoid thinking another person is immature just because they are using a technology that you have discarded. Your reasons for discarding it in your scenarios may be valid, but so might their reasons for keeping it in their scenarios. Usually if someone is suggesting a technology that you feel is inappropriate then there is a chance for learning - either you learning more about their solution or them learning more about the other technology.

To take this out of a computer scenario, an airplane could arguably be described as a more powerful solution than an car: it is able to travel longer distances faster and with more passengers than a car can. But of course there are still reasons for using a car - there are places a car can go where an plane cannot.

Similarly there are times when a JDBC solution may trump a Hibernate solution.

I would expect to be able to hire a Java programmer today, and put them immediately to work on an application that uses JDBC. However it is not always possible to hire a "Java" programmer and put them to work on a project that uses half a dozen additional technologies.

The more components you add to the mix, the harder it is to get developers who know all the components and can therefore be productive earlier. This has to be traded off against the gains in productivity that will come from using a particular technology.

Given that scenario, it can make sense in today's business environment to create a holistic application, whereby each component uses only the technology it needs to get it's job done (this is not a new concept, but it seems to be re-gaining an acceptance that it seemed to loose in the 80's and 90's). In such an environment, you might have one stand-alone component who's whole purpose is to get data from (for example) a web service, and put it in a local table in your database where it can later be consumed by a different component. This component probably does not need Hibernate - creating a simple JDBC solution could easy to create and maintain.

Regards, Andrew

[Abdul Kader]

Thanks a lot for your comments. I do agree that JDBC is very important and the Basic Knowledge is also VERY VERY important when you are working in abstract areas.

However what i mean to say is i also know how the drivers are loaded and how the connections are created. However i was wrote this type of code 2 years back. With the interviewer, I explained how the drivers are loaded and how connections are created in detail @ concepts level . However he ask me to write a code , where i really don't remember what the method signature is .......


Some people are quite interested in knowing the method signature of some commands which i really disagree with that, however i still agree basic Knowledge i very very important where ever you code.... when we grow up we will have strong concept level knowledge of how things will work, but if they ask me to write a code with exact signature ???
[ May 11, 2008: Message edited by: Abdul Kader ]

[Mark Herschberg]

Originally posted by Abdul Kader:
However he ask me to write a code , where i really don't remember what the method signature is .......

I'm still not seeing the problem.

--> Someone asking you to write code during an interview for a software engineering role is very reasonable and quite common.

--> If you don't remember the code signatures, that's your problem not the interviewer's.

--> Most good interviewers I know (as prior posters suggested) won't care if you remember some specific signature or canRememberTheExactWordingOfAReallyLongMethodName() but rather will look at your psuedo-code and see if your logic is valid.


--Mark

[arulk pillai]

Some time in interview when they ask some basic (silly) question, i was unable to remember answer.Because most of the time we work in areas like Springs and Hibernate where creating connections are abstracted.

-- That is why it is worth brushing up prior to an interview

-- Even if you do not know the exact answer, at least show how you would go about with some snippets of code.

-- Some silly questions are asked to see your reaction and see how confident you are.

-- The candidates are short listed relatively based on perfoprmance of all the candidates. So even if you do not know the exact answer, thinking a bit loud can help.

In my opinion, a question that requires you to memorize the API isn't unfair either. In my opinion "I don't fully remember - I think it's A, but to be sure, I had to look it up in the JavaDoc" would be a quite good answer. It tells me that the candidate is able and willing to communicate when he isn't sure about something (and doesn't simply make up answers to hide that he might miss some knowledge), and that he knows how and where to look up things.

Good point.
[ May 12, 2008: Message edited by: arulk pillai ]

[Edvins Reisons]

Take a look at how you present yourself on your CV, cover letter, to your professional contacts etc. Say that you are a quick programmer and these are the sort of questions that you are likely to get for it . Other options, with possibly no less "silly", but different questions, could be to emphasize your domain knowledge, or system architecture experience, or a feeling for usability...

[Nicholas Jordan]

I remember the advice of our instructor thitry - fourty years ago. The instructor had actually worked at several very significant commercial concerns doing actual programming - back when the mark of the master was being able to cram the entire program into what we now view as one page of an editor - no imports or library calls.

It was common practice to have a portfolio in which there was an actual program, one of your own design, that could be exposed in the interview for the purposes of the interview.

Rushing code onto paper ( ok, crt ) is a security flaw, one that the interviewer should not encourage. I would agree that the counter-claim of productivity { as a legitimate metric of the interview } is totally appropriate. I would expect that any company that would not allow an overnight express code-job is not sufficiently anchored with their planning for survival. I do agree that the ability to hammer out working code in short order is a valid metric of something, probably time actually writing code.
[ May 12, 2008: Message edited by: Nicholas Jordan ]

[Jeanne Boyarsky]

Originally posted by Mark Herschberg:
--> Most good interviewers I know (as prior posters suggested) won't care if you remember some specific signature or canRememberTheExactWordingOfAReallyLongMethodName() but rather will look at your pseudo-code and see if your logic is valid.

And some will let you use and IDE and/or the internet to look them up so you CAN create compilable code.