A Java Developer's Quiz: Part Two

By Janice J. Heiss, May 2009  

For this quiz, SDN staff author Janice J. Heiss surveyed past interviews with leading Java developers in search of questions that might challenge, inform, entertain, amuse, and provoke you. The questions aspire to reflect both the intellectual curiosity and spirit of fun to be found in the Java community. We hope you enjoy taking this quiz.

Choose the best answer for each question, then click Submit to see how you scored.


  1. True or false: This loop iterates over each int value exactly once:  
      for (int i = Integer.MIN_VALUE; i <= Integer.MAX_VALUE; i++)
     A. True
     B. False
  2. Which of the following is not advice offered on java.sun.com to beginning Java developers?
     A. "Random tinkering rarely gets you anywhere."
     B. "Write lots of code. Have fun with it! Collaborate with people who are more experienced than you and learn from them."
     C. "Don't forget that billions of dollars of revenue have been generated and millions of people have been employed because someone at Sun Microsystems invented Java, and a group of dedicated engineers kept producing innovations around it. So contribute to the goodness."
     D. "Google, Google, and more Google!"
     E. "In NetBeans, try typing newo and hit Tab. Go ahead. Try it."
  3. Cloud computing expert Alan Williamson believes that cloud computing problems include the following:
     A. Too high expectations.
     B. Moving software from the desktop and datacenter onto the network cloud means that source code availability will become less important and open-source software will lose out.
     C. Problems of privacy, ownership issues, and data control have not been sufficiently resolved.
     D. The need to constantly monitor the cloud and your application in it present difficult challenges.
     E. A and C.
     F. C and D.
     G. A and D.
     H. All of the above.
     I. None of the above.
  4. Which of the following is not a tip from renowned bug fixer Brian Harry about how to fix bugs and be a good bug fixer?
     A. Always acquire the test that's attached to the bug report.
     B. Ask yourself if it's really a bug.
     C. Write down your thoughts as you seek a solution.
     D. Consider writing multiple solutions.
     E. Focus your attention on the technical cause of the bug.
     F. Surf the bug database for areas that interest you.
     G. Look at what the patched code interacts with.
     H. Keep in mind that the place where you find bugs may not be the right place to put a fix in.
  5. Although Joshua Bloch, Brian Goetz, Cay Horstmann, and Kirk Pepperdine agree that premature code optimization is a serious problem for Java developers, they offer different formulations of the problem. Match the name with the quote.
    1. "Developers love to optimize code and with good reason. It is so satisfying and fun. But knowing when to optimize is far more important. Unfortunately, developers generally have horrible intuition about where the performance problems in an application will actually be."
    2. "It's easy to feel like the general warnings about premature optimization don't apply to you, because you just know which code is time-critical and how to make it fast. But no one can determine this without measuring before and after each attempted optimization."
    3. "I learned over the years that it never pays to optimize code until after you profile. We all fret over caching values rather than re-computing them, eliminating layers, and so on. More often than not, it makes little difference in performance but introduces a huge headache in debugging."
    4. "Another reason to write dumb code is that most of the complexities are due to some optimization that everyone thinks is needed. In many cases, these optimizations are premature. While I'm all for performance planning, I'm dead set against premature optimizations. When is a plan a plan, and when is it premature? I guess it's a little like the difference between art and porn: You'll know it when you see it."
     A. 1.Goetz 2.Horstmann 3.Bloch 4.Pepperdine
     B. 1.Bloch 2.Horstmann 3.Pepperdine 4.Goetz
     C. 1.Goetz 2.Bloch 3.Horstmann 4.Pepperdine
  6. According to Joshua Bloch, what is the style of thinking that most gets Java developers in trouble?
     A. Unwarranted optimism
     B. Treating complexity as an end in itself
     C. Generating too many potential solutions
     D. Excessive fear and cautiousness in anticipating bugs
     E. Failing to trust your initial intuition
     F. All of the above
     G. None of the above
  7. Who said the following: "Large-scale IT projects are inherently inefficient. It's a misconception to even talk about a large-scale project. The trick is to divide a huge project into small, two- to five-member developer teams that can act independently and be responsible for particular parts of the project. This is a challenge, but it's worth a try. Only then will developers identify with the code and feel responsible for it. This is the key to success."
     A. Adam Bien
     B. James Gosling
     C. Bill Joy
     D. Kirk Pepperdine
     E. Jonathan Schwartz
  8. Who said, "I think we're going to beat spam... If everyone paid a penny per email sent, the cost would be very small, but the cost to spammers would be great, and spam would stop. That's my proposal."
     A. James Gosling
     B. Tim Bray
     C. Bill Joy
     D. Jaron Lanier
     E. Scott McNealy
  9. Who believes that open-source communities are proving to be the greatest source of radical creativity among developers?
     A. Masood Mortazavi
     B. Alan Williamson
     C. Jaron Lanier
     D. All of the above
     E. None of the above
     F. A and B
     G. B and C
     H. A and C
  10. In assessing the value of Java EE, Masood Mortazavi points to the following:
     A. Scalability
     B. Separation of business logic and system concerns
     C. Portability
     D. Long-term maintenance
     E. All of the above
     F. None of the above
  11. Which of the following is not advice that Adam Bien offered about writing Javadoc comments?
     A. Document the non-obvious background knowledge, the intention and not the result.
     B. Try to capture the concepts in a central place -- for example, a wiki -- and only reference the contents.
     C. "Escape" obvious facts with marker tags -- don't describe them over and over again. Be DRY.
     D. Include samples, how-to's, and so on in your documentation.
     E. Err on the side of describing more than merely key concepts in writing documentation -- some concepts are more important than you think.
     F. Don't allow default Javadoc comments generated by the IDE.
  12. Which statement(s) is or are not true of Java Card 3 technology?
     A. Java Card 3 runs on the recent high-end smart cards, which have more memory -- approximately 24K of volatile and 128K of non-volatile memory -- and a fast 32-bit processor.
     B. Java Card 3 uses MIDlets, along with Java Card applets and servlets.
     C. WAR file format is supported with Java Card 3.0-specific information, like the Java Card Runtime Descriptor.
     D. Class file verification is the same as in CLDC.
     E. Java Card 3 offers full Java language support, including support for all data types except float and double.
     F. Java Card 3 does not provide automatic garbage collection.
  13. Game expert Jeff Kesselman, speaking in 2007, said that it usually costs how much in U.S. dollars to create an online multiplayer game?
     A. $3 million
     B. $6 million
     C. $10 million
     D. $12 million
     E. $15 million
  14. Who wrote the following three poems?
    1. Unnormalized Models
      This is the recipe for this.
      Random fields,
      exponential models,
      motivated from (turn
      your head
      and say natural language
      ). Segmenting and
      labeling sequences. A
      based on
      conditional random fields
      offering several
      advantages over
      hidden Markov models and
      stochastic grammar.
      (she was thin
      I thought
      not normal I
      liked her segments....
    2. Untitled
      Tiger, Tiger burning bright
      Like a geek who works all night
      What new-fangled bit or byte
      Could ease the hacker's weary plight?
      To the most despised collections' cast
      We'll bid a fond farewell at last
      With generics' burning spear
      The need for cast will disappear
      While Iterators have their uses
      They sometimes strangle us like nooses
      With enhanced-for's deadly ray
      Iterator's kept at bay
      When from the collections ints are drawn
      Wrapper classes make us mourn
      When Tiger comes, we'll shed no tears
      We'll autobox them in the ears
      The int-enum will soon be gone
      Like a foe we've known too long.
      With type safe-enum's mighty power
      Our foe will bother us no more
      And from the constant interface
      We shall inherit no disgrace
      With static import at our side
      Our joy will be unqualified
      As for noble metadata
      I'll have to sing its praises later
      Its uses are so numerous
      To give their due, I'd miss the bus
      O joyless nights, o joyless days
      Our programs cluttered with arrays
      With varargs here, we needn't whine;
      We'll simply put the args inline
      Tiger, Tiger burning bright
      Like a geek who works all night
      What new-fangled bit or byte
      Could ease the hacker's weary plight?
    3. Oh Java Code
      Oh Java code that strikes the page
      Like wisdom siphoned from a Sage
      Like random models fierce with light
      That make the darkened worlds grow bright
      Now opened to the world's great gifts
      Now powered by the minds' new lift
      May generics bloom as geeks grow wise
      While the Source traps bugs within a vise.
     A. Joshua Bloch, James Gosling, Jonathan Schwartz
     B. James Gosling, Joshua Bloch, Simon Phipps
     C. Richard Gabriel, Joshua Bloch, Joshua Bloch
     D. Richard Gabriel, James Gosling, Joshua Bloch
     E. Richard Gabriel, Joshua Bloch, John Gage
     F. None of the above

Left Curve
Java SDKs and Tools
Right Curve
Left Curve
Java Resources
Right Curve
Java 8 banner (182)