Thursday, March 22, 2012
Google question
Thursday, November 17, 2011
interview questions
2. SQL;
employee, dept
find departid which has duplicate employee name
SELECT name, departid COUNT(name) AS NumOccurrences FROM employee GROUP BY name,departid HAVING ( COUNT(name) > 1 )find the person who has the highest salary in one dept
3. List
sort the list
(calling Collection.sort)
4.tapestry design
5.java jdbc calls what is the common mistakes
6. http protocol
7. WAR config
8. webservices structure
(ST)
Sunday, November 13, 2011
final array
final int[] number = {1,2,3};
numbers[1] = 50; // is this legal?
}
legal, the final is on the array, so you can not change the length of array, but you can change the element
Saturday, March 26, 2011
recursion to iterative
powerSet -- binary approach
A - 00000001
B - 00000010
C - 00000100
D - 00001000
The size of a power set is calculated by 2^N of the original set. So in this case the size of the power set will be 2^4 or 16. This means that you must create sixteen elements for your power set with binary values starting at 0 and ending at 15 in binary. For each binary value you would add the elements of the original set which have similar bits.
Example:
00000000 - (O) - {Empty Set}
00000001 - (1) - {A}
00000010 - (2) - {B}
00000011 - (3) - {A, B}
00000100 - (4) - {C}
00000101 - (5) - {A,C}
00000111 - (6) - {A,B,C}
Wednesday, March 2, 2011
How to reduce the number of bugs when coding?
Avoid fancy coding. The more complicated the code, the more likely there's bugs. Usually on modern systems, clearly written code will be fast and small enough.
Use available libraries. The easiest way to not have bugs writing a utility routine is to not write it.
Learn a few formal techniques for the more complicated stuff. If there's complicated conditions, nail them down with pen and paper. Ideally, know some proof techniques. If I can prove code correct, it's almost always good except for big, dumb, obvious bugs that are easy to fix. Obviously, this only goes so far, but sometimes you can formally reason about small but complicated things.
Beyond that, set the highest warning level your compiler offers, and make sure warnings are treated as errors. Bugs often hide in those "erroneous" errors.- Don't ignore error codes - e.g. don't assume that you got a valid result, that a file has been successfully created, etc... Because some day, something will happen.
- Don't assume that your code will never enter some condition and that therefore "it's safe to ignore that condition".
- Test your code, then have it tested by someone else. I find I'm the worst person to test my own code.
- Take a break, then re-read your code and see if you "missed the obvious". Often happens to me.
I found that if I pass all of the context to a function (or method) that that function needs to do its job, and return the meaningful data that I'm looking for, that my code has become much more robust.
Implicit state is the enemy and in my experience is the #1 source of bugs. This state can be global variables or member variables, but if results are dependent on something that's not passed to the function you're asking for trouble. Clearly it is not feasible to eliminate state, but minimizing it has huge positive effects on program reliability.
Involve your testers as early as you can
http://programmers.stackexchange.com/questions/7927/how-to-reduce-the-number-of-bugs-when-coding
Thursday, February 24, 2011
Java interview questions
http://www.javabeat.net/articles/33-generics-in-java-50-1.html
what is the common practice you do to reduce bugs?
what do you do to write thread safe code?
WildCard
Sunday, February 6, 2011
interview questions : distributed sorting
Monday, January 31, 2011
Saturday, January 29, 2011
interview questions
BST
join - outer join
ACID
level of isolation DB provides.
deadlocks, how to avoid them
concurrentmodification exception java - what code will you look at
command to list open files for a process
command to list processes which have opened a specific file
commands related to find and grep