Campbell Ritchie wrote:If you submitted code that badly formatted for an interview question, you are lucky that they even read it
Campbell Ritchie wrote:<> [/tt]and other features introduced in Java7 in 2009.
Campbell Ritchie wrote:Sorry, I misunderstood your last question. Anybody reading your code would expect you to be up to speed with the very newest features, as well as <> and other features introduced in Java7 in 2009.
salvin francis wrote:Adding to what campbell said...
I would be very angry to see a method called "printMap" that modifies the map I pass to it. Even angrier if it deletes something from my map.
Campbell Ritchie wrote:Yes. It also obviates an opportunity for spelling errors and compiler errors. It works in 90+% of cases.
I do mean any kind of modification. If a method says print, it should ... print !! But of all the modification sins the method can commit, deletion ranks the highestMonica Shiralkar wrote:
I will correct it. By 'modifies' do you mean the delete line ?salvin francis wrote:...
Campbell Ritchie wrote:Remember every keystroke you use is an opportunity to gett it wrong. The whole point is, the smart thing is not to get stung with compiler errors because it really hurts to have to correct them.
Mike Simmons wrote:
If I were the interviewer, I'd be looking first for, what questions does the candidate ask? Some that come to mind are:
Do uppercase and lowercase characters count the same?
Is the input restricted to standard US-ASCII characters? Or are others possible? Do we need full Unicode support?
Are we looking to optimize speed? Or maintainability? I would really prefer the latter, but some interviewers may have something else on their minds.
.
I hope you wouldn't go for speed above anything else.Mike Simmons wrote:The "not the optimal way of doing it" comment makes me think the interviewer is looking for the old-school fastest possible implementation.
It might do in the old Hashtable, but not necessarily in HashMap, which allows null both as a K or as a V.. . . get(), and checking if the result was null. Null means it wasn't there. . . .
Campbell Ritchie wrote:
I hope you wouldn't go for speed above anything else.Mike Simmons wrote:The "not the optimal way of doing it" comment makes me think the interviewer is looking for the old-school fastest possible implementation.
Campbell Ritchie wrote:
It might do in the old Hashtable, but not necessarily in HashMap, which allows null both as a K or as a V.. . . get(), and checking if the result was null. Null means it wasn't there. . . .
Salvin and I had a private conversation about this question and we would both have used that approach. It has the advantage that the memory footprint of the app makes some attempt to match the memory actually used.Zachary Griggs wrote:. . . create a Set of Character. For each Character in the String, attempt to add the Character being iterated through to the Set. If it returns false . . . you found a duplicate . . .
Some of those would be good reasons for the interviewer to reject the applicant and some would be good reasons for the applicant to reject the interviewer.. . . . It could mean too slow, or has too much code, or the code is unreadable, or that the interviewer simply would not have done it that way and didn't like it.
Campbell Ritchie wrote:
Salvin and I had a private conversation about this question and we would both have used that approach. It has the advantage that the memory footprint of the app makes some attempt to match the memory actually used.Zachary Griggs wrote:. . . create a Set of Character. For each Character in the String, attempt to add the Character being iterated through to the Set. If it returns false . . . you found a duplicate . . .
(or add it to a Set of Character which tracks duplicates and print it out at the end).
That is what we all three did.Mike Simmons wrote:. . . if a character occurs ten times, we want to report it as a duplicate once . . . . That requires the second set . . .
I should know better than to mention memory, since memory is cheap. If you use simple chars, you might want an array to accommodate 64Ki different values. Or 1110111 if you use all code points, a number 1000 too few In C, a char might be 8 bits, but not in Java®. The memory footprint of each set/map will depend far more on the length of the input text rather than the potential range of values.I don't see memory savings here. Am I missing something?
Mike Simmons wrote:The "not the optimal way of doing it" comment makes me think the interviewer is looking for the old-school fastest possible implementation .
Monica Shiralkar wrote:...He was talking something about O(n)/ O(1)/O(2) something.