OCP 819 - is it worth it ? Thoughts after failing for 2nd time

[Luke Moloney]

hi,

I've just failed the test for a 2nd time. And thought I'd share my thoughts (positive and negative).

This is a very hard exam for 2 reasons:
1) speed  ( 90 minutes for 50 questions so about 1 min and 3/4 per question - about 105 seconds per question )
2) alot of API memorisation

I'm an experienced developer and thought I'd do the cert earlier in the year (because of the 25 years of Java discount, I rushed it somewhat and failed).

This time I took more time to prepare, and my mark was much better that last time ( its really practicing so you know the API inside out and can answer the questions in very fast speed). This is just practice (but it takes alot of practice to get to the required speed, I'm 47 ). Last time I ran out of time, this time I finished in time ( with 5 minutes to review questions ).

I should also mention I did the exam at home this time with the exam software ( it was somewhat distracting, I was told off for mumbling, and for moving about too much when I scratched my leg ).

Good things

1. It gives you a good knowledge of core Java
2. Get good at new features in the language that might be useful such as Lambdas ( I really have a good knowledge of Lambdas now that I think I wouldn't have otherwise).

Bad points (in my opinion )

1. Speed - I'm not sure, this is a good thing.
And I think this is teaching young programmers a bad trait, by teaching them to wack through code as quickly as possible is ok.

2. loads of API memorisation - not sure how much value there is in this ( at work, I'd just quickly look up the API if needed )

3. Learn alot of stuff that is not used in industry ( Modules , Serialisation )


So those are my thoughts, hopefully I'm not too negative (bit disappointed at the moment, but trying to be balanced ).

I will probably study for it again because I'm stubborn ( but probably not for awhile , I will practice questions maybe couple a day , so I can answer them in a lightning fast speed ).

[Jesse Silverman]

Thanks for your feedback!

I haven't taken the test yet because I knew I wasn't prepared for it (I got a mostly Python/C++ job for a while in-between which pulled me away from the preparation and caused me to miss the 25th anniversary deep discount window).

I've been thinking about the Time Factor, how much it is intentional or sadistic versus how much it is testing for things employers want (and sometimes get).

I don't disagree with any of your Cons, but have also thought of them in a different light.

So the non-intentional part of the Speed Factor.
Earlier tests didn't have so much of a Race the Clock Factor.
The scope of the exam is wider than ever before (except for the AWT stuff that used to be on it in the old days) and combining the two tests into one either meant a Very Long Test (which I would have preferred) or such a hit-and-miss go at throwing random questions at you that many important topics would be missed.  So two things come out of that, multiple topics in play on many/most questions, and super-tight time limit.  I traditionally have been an Extremely Fast test-taker, on material I knew I'd get more right than most taking the test could even complete/guess at, and I find that very hard.  So it could be a semi-unintentional side effect.

Oracle also has a perception of a value of the test to the industry versus difficulty.  If a test is perceived to be a push-over, employers won't care much whether people passed  the easy test or not.  I've seen other cert exam prep providers talking about how easy the tests they were preparing people for were going to be, casually guaranteeing that "finish this easy course and you will ace it!!  Now relax and have fun, you are well on your way to an easy certification to add to your resume!" -- that is NOT what they are going for on the 819.

I've had recent interviews for Senior Developer/Team Lead where code review was a big part of the job.  The technical parts consisted of showing me one piece of sloppily-written code after another, or more precisely that which would be written by a Junior Developer that would certainly compile and run, but had Problems.  I had to quickly describe how it would behave, what sorts of inadequate testing would have made them falsely feel "Nailed it!" and what sorts of tests could be quickly added that would make them say "Oh, Snap!" and go fix the code, probably after I explained to them what they missed, misunderstood or got wrong.  Some of them were things like hash code equals contract, storing mutable object as keys in a Map or elements in a Set, and others were subtly missing things that (like these) are also in the Javadocs but many people who are rushing ignore.  They wanted all this FAST, to demonstrate I can just look at bad code for a minute and see the API misusages etc. like someone had highlighted them with a marker, and then explain in a way that someone who had just made those errors will understand and know how to go fix.

I can barely even describe how extremely useful participating on this site has been for me in that regard.  Even though there were parts of the tech stack that I had no experience with, they weren't concerned with whether or not I could learn that (presumption is that I could), apparently the hard thing for them to find is what I had just described, someone who can quickly look at code and say "This is almost good, BUT..." in a way that will cause the more Junior Devs to subsequently check in the corrected code along with additional tests that would have failed had they been present for their first code.  I feel the OCJP prep also makes me better at that (at least the way that I prep for it).  I watch tutorial videos to get this stuff burned into my brain (API's etc.) and regularly see these kinds of problems in the examples the presenters are showing.

Still on the subject of speed, I came up with an analogy while sleeping of the Alphabet Song.  We (almost) all know the alphabet.  Some people really do need to sing the Alphabet Song (A B C D E F G, H, I, J, K, L, M, N, O P...Q, R, S, T, U, V...W, X, Y and Z...Now I know my AB...") when you ask them alphabetical order questions (not a joke, I've seen this) and there is a lot of Java that I know at this level.  Given enough time, I will sing the relevant "Alphabet Song" governing that aspect of Java API or Behavior and will get the right answer.  But you need to be able to look at two code snippets and say "The first one will give you 7 T c" because it is straight alphabetical order, the second one will yield 7 c T" because they are using case-insensitive comparison.  In Real Life I've seen people do Streams where they first do a distinct, then sort, THEN uppercase, not realizing that this will yield two entries for "doh!" and "DOH!" that won't even be next to each other in the output.  That could be what you meant to do, but, it wasn't.

So to breeze thru the 819, you need to not only know the material but to know it so well that you can apply it really FAST, without singing ABC songs in your head.  This seems likely to be intentional.
You also need to read a bunch of code that you've never seen before fast, often written in a weird, odd way you would never write it, and quickly apply the rules you know by heart to this weird code you wouldn't have written and say what it can do.  This corresponds to stuff I've been hit with on interviews except I had to explain exactly what the code would do (in a way that a just recently confused person would quickly become clear on it) and recognize both the fix and the tests corresponding to it.

I guess what I am saying is that "Encouraging Junior Devs to Move Fast and Break Things" might be an unintentional side effect, where "Encouraging Senior Devs to See That Fast and Explain How to Fix It and Test the Fix" might be where they are going with all this.  I think that covered two of the three "Cons" in your list, because of the "Rush to the Bottom Effect" where material is taught (and learned) ignoring a lot of the basic usage guidelines described at the beginning of any JavaDocs page in favor of racing down to the list of methods, and people quickly glancing at those as well and missing subtle but essential usage guidelines contained in the actual entry for the method itself.  So yes, we make heavy use of the JavaDocs, but they want to make sure we can recognize and address flaws in code written by those who consulted them hastily or without enough attention.  I still 100% agree on the "this is frustrating" part but can more easily imagine having done so being useful in certain job positions.  In my professional career, Senior Devs needing to do too many code reviews in too little time was a HUGE, HUGE problem.  They felt it was pretty much impossible for them to be considering language/library usage problems and evaluating the business logic for correctness in the time that was allocated for them to do it.  Some solved it by working 11 and 12 hour days, others had family obligations that precluded that and had to just scramble to do whatever they could.  "This code had BETTER NOT HAVE ANY C USAGE PROBLEMS IN IT!!" was something I would hear them grumble, because they only had time to evaluate the business logic.

So yeah, I am leaning towards the tests helping to test some skills that would be less important in an Ideal Environment but that would be quite useful indeed for my co-workers who were constantly struggling to do too many code reviews in too little time.  At least they will spot the Java mistakes almost instantly.  Similar with the ability to quickly look at some Weird Code written in a way you'd never write it, notice what it is actually doing and seeing if that is probably the intended behavior.

That leaves the "Learn lots of stuff that is not used in Industry" (Examples: Modules, Serialization)...I am currently studying the modules stuff THIS WEEK.  I've been asking how much this gets used, but there have been huge changes to Java here and at least awareness of them seems to be important.  Is it not the case that many/most of the most popular and heavily used frameworks have seen changes in their packaging to be made available as modules?  There is a lot of "stuff" here and I am in the throes of learning it all pretty well so I resent it at the moment, but the changes do seem to be important in practice and even more in the "Dang, I wish they had done this 20 years ago!" ways.
For Serialization, the goofy Magic Methods are daft, but there are parts of even the classical stuff that is still relevant when using modern persistence technologies, I thought.  Maybe not so much.

All in all, I feel I could likely repeat your experience, and am currently gearing up not to, just some reflections on how that practice may not wind up being "Wasted Time Just For the Dubious Benefit of Receiving a Stupid Cert", tho I may eventually feel that way down the road.