Which part of java do you know 100%

[D. Rose]

Hi All,
I have gonw through few interviews ( have not landed anywhere yet, bad luck!). I was asked question like ' How do you rate yourself in java?' , this is easier to answer but next question is 'Which part of java do you know 100%?'
I could not answer this confidently as I believe there is nothing like to be 100% sure.
I would appreciate your thoughts on this.

[Manish Hatwalne]

I tend to agree with you. Saying you know something 100% is like saying there's nothing more to learn in it.
However, the correct answer to this question would be - "I believe, I am quite comfortable in XYZ..., but I wouldn't say I know 100% about them."
Then pause for his response, facial expression and give your justification/explanation accordingly.
- Manish

[SJ Adnams]

I think the Object class.
I've been asked this in an interview (was Reuters BTW) & think it's a great question;
"Name all methods of the Object class"
"Describe what each of the methods do"
"Descibe how you would use/override the methods"
Anybody who calls themselves a Java programmer yet cannot do the above is a fraud.

[Manish Hatwalne]

I doubt how many programmers would be able explain equals/hashCode and clone correcly.
- Manish

[Mark Herschberg]

Originally posted by Simon Lee:

"Name all methods of the Object class"
"Describe what each of the methods do"
"Descibe how you would use/override the methods"
Anybody who calls themselves a Java programmer yet cannot do the above is a fraud.

Off the top of my head, I couldn't name all the mehods of the Object class. Maybe I could if I sat there and thought about it, but it's not something I could rattle off in an interview.
--Mark

[SJ Adnams]

hmmn, thats interesting.
Mark, I think if you were in an interview situation you'd be able to get them all (well apart from registerNatives(), I wouldn't expect anyone to get that (including me).
I think hashCode() is a very important concept, along with cloning.
Maybe I spend to long debugging (hence I'm always stepping into these methods)?

[Tim Holloway]

I can't name all the member functions of class java.lang.object. But I'm aware enough of its functionality to be able to know what to look for in the JavaDocs.
Since I lack an eidetic memory, there's absolutely no way I could claim expertise in as many areas as I do based on sheer rote memorization, but I have been accused of the next best thing, because I usually know exactly where to look it up and how, in minimum time, to apply what I've found there.
I don't feel bad about that. Knowing the class details is knowing where you're coming from. What's more important to me is knowing where I'm going to. The world is changing, and it's part of my ambition to be one of those agents of change - or, in other words, to not limit myself to what was or what is, but to look to what can be.

[SJ Adnams]

I think that replying to every question "Well I can hit F1 and find out" or "use Google to find an example" just doesn't fly.
This is not really a question on "has this guy just rote learnt everything or is he smart?". Technical questions are designed to measure the exposure of a person to a technology.
If someone knows the method signatures of HttpServlet there is a chance that its been rote learnt, there is also a chance that it is a measure of the number of hours coding jsp/servlets. (i.e. a CV bullshit filter)
These kinds of questions are part of the interviewers arsenal and will obviously be combined with "going to" questions.

[Mark Herschberg]

Yeah, what Tim said. That's what I was wanted to say but couldn't put into words.

Originally posted by Simon Lee:

Mark, I think if you were in an interview situation you'd be able to get them all (well apart from registerNatives(), I wouldn't expect anyone to get that (including me).

See, I'd very likely forget hashcode (I'd probably remember equals, and maybe I'd remember practical Java that if your override one, you need to override the other--one maybe its a one way requirement, btu I can't remember which way). Of course, this doesn't mean I don't know hashcode, just that I've used it so rarely in my career, that I don't normally think about it. On the other hand, I can't think of a time where I've had to spend a lot of time on a problem only to eventually realize that using hashcode is the right way to do it. When I've needed it, I've remembered to use it.* As Tim pointed out, it's the model more then the details.
*Granted this might be inherently biased, but since I don't remember any code reviews in which hashcode was suggested as a better alternative, I'm thinking its been a fair survey of my code.

--Mark

[Matt Cao]

Originally posted by Tim Holloway:
I can't name all the member functions of class java.lang.object. But I'm aware enough of its functionality to be able to know what to look for in the JavaDocs.
Since I lack an eidetic memory, there's absolutely no way I could claim expertise in as many areas as I do based on sheer rote memorization, but I have been accused of the next best thing, because I usually know exactly where to look it up and how, in minimum time, to apply what I've found there.
I don't feel bad about that. Knowing the class details is knowing where you're coming from. What's more important to me is knowing where I'm going to. The world is changing, and it's part of my ambition to be one of those agents of change - or, in other words, to not limit myself to what was or what is, but to look to what can be.

Hi Tim,
This is the most beautiful post I have seen so far from you.
You know how to turn the interview process scenario from interviewee to interviewer and watch the adversary scratching his behind or whatever convenience at the time.
Have you thinking about switching interview strategy from technical oriented to business problem solver oriented? Did you have any advanced degree?
From different post, I think the reason you have 19 out of 20 items the job description req. But the recruiter still dodging you, probably have to do with age discrimination. The advanced degree would help to justify your reason of being.
Cheers,
MCao

[Tighe Fagan]

Originally posted by Simon Lee:
I think the Object class.
I've been asked this in an interview (was Reuters BTW) & think it's a great question;
"Name all methods of the Object class"
"Describe what each of the methods do"
"Descibe how you would use/override the methods"
Anybody who calls themselves a Java programmer yet cannot do the above is a fraud.

Jeez, I would just flat out say that this is a bad
interview question. Even if someone does get it
100% correct what does that really tell you about
them? They have a very keen memory or are they
so anal retentive that they may be difficult to
work with. My gut response to someone that could
rattle off the answer is "Dude, you need to
get a life."
I am beginning to side with a colleague of mine
that shys away from the minutia type API
questions that seem to be in vogue.
Being able to clearly explain previous work
and pros and cons of various design issues
is much higher on my list of skills. Add
some OO/design pattern concept questions
and I think it's a much better gauge of a
Java developer.
Nerf the J2SE API questions.
[ June 30, 2003: Message edited by: Tighe Fagan ]

[SJ Adnams]

retentive maybe, but this would have been working on a trading platform & that is exactly what these folks like.
Remember also that software design patterns, database schemas, legacy integration are all subject to 'bookish' implementations. Would you also dismiss a guy who could name half a dozen datamodels & draw them on a whiteboard?
Since this thread is starting to become one on more general interview questions, I'd say the best interview is when the interviewee manages to turn the tables & drive the interview. In this case "What part of java do you know 100%" you could have turned it right around and spoke about how fast moving language semantics, APIs, vendor extensions etc are, that you have demonstrated how quickly you can adapt and select particular technologies to solving the business problem at hand yadda yadda yadda.
If you get a gift of a question like this, try and use it to take control.

[Tim Holloway]

You know how to turn the interview process scenario from interviewee to interviewer and watch the adversary scratching his behind or whatever convenience at the time.

Thanks, Matt. Actually what they say is "Who does this annoying little piece of #$#%$!@@! think he is?"
Heck. There are, what, 1500+ basic JDK classes? Plus probably several hundred more J2EE ones - maybe more. java.lang.Object may be their ultimate base, but about the only method I have used regularly in 7+ years of watching Java grow up and yesterday's "must-have" minutiae become today's dangerously obsolete false wisdom is toString(). I was going to add equals(), but for what I do the default action generally serves. So when I need details, I pull them out of the "lumber room" of my library (to misquote Sherlock Holmes). The amount of time I spend looking up classes and methods is so small compared to the time I spend laying out subsystems and validating them in my head that I don't even bother to use an IDE with auto-completion to shorten the process.
One of my personal strengths is the ability to visualize (and to realize) projects of great scope while still being able to drill down all the way to the interrupt service routines, if necessary and thus to ensure that the system is integrated at both the macro and micro levels. But to do that requires way more info than what I can cram into my pointy little head. CD-ROM and Internet documentation are the only things that have kept my house from exploding - it's already crammed with reference books - which I've repeatedly learned to discard at my peril.

Have you thinking about switching interview strategy from technical oriented to business problem solver oriented? Did you have any advanced degree?

While this is a digression, actually I am a business problem solver. However my business is integrated systems. That is to say, that my "customers" are the technology providers within the company.
For example, my last employer had 3 major tech groups. One for the legacy "cash cow" mainframe batch system (mostly COBOL). One for desktop apps (mostly VB) and one for the Internet services (mostly Java). If you needed a system that tapped into two or more of the above and handed it to a member of one of the primary groups, they'd solve it in terms of their own point of view (VB for mainframes!!! ). While I hadn't in-depth knowledge of either the industry or of the actual apps, I knew enough about the architecture of the application systems in question and the platforms upon which they ran to be able to put together an integrated architecture where, for example, the mainframe data feed wouldn't turn the operations staff upside down just to pump data into the desktop and web apps, and that the desktop and web systems didn't end up each with their own private (out-of-sync) database architectures.
It's an underappreciated calling. Finding jobs doing that can be hell in the best of times, but at least the pay's usually worth it.
I've considered degrees, certs and other such trinkets many a time, but except in certain industries, my experience has been that not only will they not be counted for you, they can actually count against you.
Then again, only 3 short years after I demonstrated my complete incompetence in the teaching field by attempting to conduct a course in C (the students all fled in despair), the largest university in the state decided it was time to add C to their curricula. :roll:
[ July 01, 2003: Message edited by: Tim Holloway ]

[Gregg Bolinger]

Originally posted by Tim Holloway:
the largest university in the state decided it was time to add C to their curricula. :roll:

University of Missouri just added C to their curricula for this fall. A friend of mine in a Masters program there will be teaching it.

[Matt Cao]

Hi Gregg,
You are kidding! C has been around for very long time after Basic and Fortran, I think. It's just so difficult not many students like it.
Regards,
MCao

[Mark Herschberg]

Originally posted by Matt Cao:

You are kidding! C has been around for very long time after Basic and Fortran, I think. It's just so difficult not many students like it.

I would be very surprised if that was the case. Many top schools don't teach classes on particular languages because they don't see it as a valuable use of time. If you know one language and are at all competent, you can learn another.
--Mark

[greg norman]

C is just so difficult not many students like it.

C language itself isn't more difficult than Java itself. People tend to use C, not Java, to solve more technically challenge problems.

[Matt Cao]

Hi Mark,
In California, starting from Stanford Univ. all the way down to State Univ. all Engineering and CS freshmen must learn C. It uses as the tool to filter out the wheat from the chaff. The majority freshmen did not do any programming language in high school neither. Could you imagine the horror?
Of course, I agree with you if one know one language competent enough, pick up the others should not be a major problem.
Regards,
MCao

[Mark Herschberg]

Originally posted by Matt Cao:
In California, starting from Stanford Univ. all the way down to State Univ. all Engineering and CS freshmen must learn C.

That's incorrect. I researched Stanford's and UC Berkeley's programs last year for my book and neither required learning C. Stanford's CS site is not available this summer, and I wasn't motivated to remap Berkeley's classes to contents, but check back at your convienence.
--Mark

[Matt Cao]

Hi Mark,
Yep, you are correct. I asked around the offices, they said it depended on the teachers. My knowledge in that realm is out-of- wack.
I also venture too far from the topic too.
Regards,
MCao
[ July 02, 2003: Message edited by: Matt Cao ]

[shay Aluko]

Originally posted by Simon Lee:
I think the Object class.
I've been asked this in an interview (was Reuters BTW) & think it's a great question;
"Name all methods of the Object class"
"Describe what each of the methods do"
"Descibe how you would use/override the methods"
Anybody who calls themselves a Java programmer yet cannot do the above is a fraud.

I disagree, while it is probably useful to know the commonly used methods in the object class or any other class for that matter, it is a pointless exercise and misdirected use of one's gray matter to rote memorising of methods and their uses.As a programmer, you role is that of a problem solver , you may know a few methoda and their uses but more importantly, you need to know how to find the information you need, analyze the available nethods and use them properly. Any employer asking those questions is probably not worth working for. It is impossible to predict in advance what classes you should know in detail; also there are no two java experts that will agree on which classes are the most important for a programmer to know. Just my .02

[Tim Holloway]

One of my favorite definitions of Java is "C++ without the mace and knives". Since I just recently started up a C++ project after spending nearly all my time with Java for the last 2 years, it really hit hard just how much mace and knives are in C++ (and, to a lesser degree, in C).
And mind you, I was one of the first to sublicense C++ from Bell Labs when it first came out commercially, so I've got a lot of experience in C++.
I don't know what they're doing now at the University of Central Florida, but I transferred in from one of the better-known institutions of the Florida State University System quite a few years ago now, and it's a requirement that when you do, you have to take Intro to Computers all over again. Partly because that's where they familiarize you with the campus computing facilities.
At the time, UCF was using Modula-2 as a teaching language, since it supported structured programming and didn't have the kinky features that "real world" languages do. OOP was still something I was helping introduce to the world back then. However, the attitude of the "intro" course I took was kind of "all right you little snots. You've been writing video games and hacking systems since you were 11, but now you're going to learn real programming." Modula you were supposed to pick up on your own. You were on your own in the computer lab. We worked with sorts and searches and other algorithms and design techniques pretty much from Day 1.
Needless to say, I consider UCF's CompSci program to be one of the better ones you're likely to find.

[John Coxey]

Simon Lee states:
Since this thread is starting to become one on more general interview questions, I'd say the best interview is when the interviewee manages to turn the tables & drive the interview.
If you get a gift of a question like this, try and use it to take control.

--------
Simon & Others:
- This is what I have been trying to tell you guys for the past 2 or 3 years.
- Of course, you will occaisonally get the hardball that absolutely has to have the answer for all of the methods in the Object class. Good!!! Now I have weeded this interviewer/company out as one that I do not want to work for.
- It's still amazing to me how few technical questions I get at Java interviews. The tech interviews that I have endured have been with recruiters who knew absolutely nothing about the language.
- Personally, I would take the Object question that Simon mentions, and try to "run with it". I would hope this would be a lead into another question that would eventually lead to the MVC model - which I live and breath every day here at current job.
- Then again, I am not seeking an architect type position. Just a basic JSP/Servlet programmer using VAJ & now WSAD.
---------
- Gotta run. Lunchtime!!!
John Coxey
([e-mail])