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

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.

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.

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.

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

Edit: oh, there they are :-)

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.

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.