

Ask HN: What's it like to work at Oracle? - Maro

.
======
mattlong
I worked at their HQ in Redwood City briefly right out of college as an entry
level programmer. The campus was very nice with a wonderful fitness center
that I used regularly. They also had a pretty good offering of cafeterias. It
was my impression that most of the employees were relaxed and never really
stressed or over-worked. Pretty much everyone worked no more than 40
hours/week. So in terms of "work-life balance" or whatever it's called, I'd
rate it pretty high.

Turning to the technical side, I quickly found myself feeling very under-
challenged/inspired. The tasks I was assigned were mainly fixing bugs in a
huge code base (granted this is probably expected and a decent way to get new
hires up to speed on the project). They weren't very involved bugs and never
took more than a day or two to correct. So I was constantly asking for more
tasks to work on. Frankly, I got bored. I realized the environment wasn't for
me. Having come from a very rigorous undergrad program, the difference was
like night and day. So I found a startup to work for (something I always knew
I wanted to do at some point) and tendered my resignation 10 weeks after
starting.

However, I got the impression that each division/group/project at Oracle have
fairly different cultures. Perhaps I would have had a different/better
experience had I been on a different project. Though for what it's worth, a
friend of mine who graduated a year later from the same school had the exact
same experience at Oracle as I had.

~~~
IotaSchizo
It's interesting hearing about people from other groups. You're definitely
right in that there are very different cultures depending on division. I was
asigned relatively important tasks within a month or so of joining my team as
I showed relatively high promise. Just a year after joining I'm essentially
leading my own feature for the 12g release (a feature I proposed, no less).

My biggest surprise is that there is still really interesting (at least to me)
work to be done in the 30 year old RDBMS kernel. There's always places to
innovate and my manager has always been encouraging of thinking of new ways to
do it.

But then again, I've never had the itch to work for a startup, so maybe I'm
just suited for a rank-and-file job :)

~~~
redoxide
data/transaction/space?

------
cobralibre
Developer career tracks end in management, for better or worse. Frequent
telephone calls. Frequent meetings. Much of the conferencing software assumes
a Windows desktop. Development occurs on hosted VMs so that works in progress
aren't lost. Many of the development tools were built in-house, including the
bug tracker and the source control system, the latter of which bears some
resemblance to Rational ClearCase.

My time at the company was brief. Though I did meet a few people who clearly
loved their work, the feeling I had was of a vast, top-heavy organization with
a culture of micromanagement, and I was glad to leave. I don't know if any of
the above is applicable outside of the division that I worked in.

------
IotaSchizo
I enjoy my job. I work in a group in the RDBMS kernel. I'm very passionate
about low systems-level C programming, so I think I'd be able to thrive in any
environment that'd let me do it.

Development Environment: Everything is an "Eating our own dog food" type
thing. Bug Database was built in-house and backed by an Oracle Database. Same
story for the source control system (which, to my pleasant surprise, was a
DVCS). Conferencing software and e-mail infrastructure is based on Oracle
beehive

On the logistics side, quite a bit of bureacracy; Functional Specs, then
design specs by certain deadlines. Significant changes need to get approval
from maybe two levels of management. I only have about one meeting every two
weeks, so that's a plus. The stress level is extremely low as releases are
very very far apart, so unless we're dealing with a high priority customer
bug, there's not much urgency to anything.

~~~
shortlived
Any downsides to having your own in-house source control system? Got any
horror stories of bugs in it?

------
swombat
Clearly, it's like not having access to HN...

Edit: oh, there they are :-)

~~~
nathanb
This is telling in and of itself...

------
redoxide
If you work on the RDBMS kernel, your debugging and reverse engineering skills
will certainly be put to the test. The deeper knowledge is somewhat silo'd, so
in addition to comfort in system level C, you should be comfortable walking up
to people's desks to get answers rather than expecting things to make sense
over email. The RBDMS kernel is pretty deep so people spend time in specific
areas. I can still regurgitate function names and acronyms and code paths for
the areas I worked in. I spend some time there after college and learned quite
a bit. The single biggest take away was that it removed any fear I ever had of
looking at someone else's code. Lots of good people I still keep in touch
with.

------
orblivion
I was working for a small to medium sized company that was acquired by Oracle
about a year into my employment, and I stayed there for another few years. The
internal culture of the office didn't change much, and neither did the
direction of our development (as far as I could tell), so I don't know much
about working on what you might think of as Oracle software.

But anything dealing with the Oracle at large started looking a lot more
bureaucratic. We had to get rid of our toaster because it was a fire hazard.
And I wasn't a big fan of their development tools, or internal website. It
wasn't a big deal though.

~~~
dmharrison
I was the same (although got to see the acquisition from the inside which was
pretty interesting), we were in Aus though which meant we had comparatively
high degree of independence, ie all our dev platforms, code tools were hosted
locally. So our team stayed pretty much the same, nerf guns, christmas trees,
boardies in the office and all. Releases slowed but revenue went up which
meant we could take time to really think through releases etc. Learnt heaps
about the business of software as opposed to just engineering. So good and bad
like most things.

Generally I think it depends on the group; as with any large group there's the
excellent and below average, you just see more of it. Different to a
startup/small company though where you can't really suffer poor performance
for long.

As a engineer I went into dev management. Anything above IC5/6 (high level
engineer) in Aus seems not really to happen, but more a function of less
product dev as opposed to service delivery in Aus. This is generally true of
Aus. Good product management and strategic releases, so was interesting
experience. I found your M _/IC_ level matters dealing internally within the
org, ie trying to make stuff happen with people you've never met before means
you prioritise based on looking at ARIA, but what you'd expect in a large
distributed org.

I've got friends still there, still fighting the good fight. As with all
things it's really about what you make of it and want to do.

