4 ms·

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

39 points by Maro 16y ago

swombat 16y ago
Clearly, it's like not having access to HN... Edit: oh, there they are :-)
- nathanb 16y ago
  This is telling in and of itself...
cobralibre 16y ago
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.
- deleted 16y ago
  [deleted]
IotaSchizo 16y ago
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.
- redoxide 16y ago
  "Eating our own dog food" seems to be a popular phrase. Especially when Bug Database has a bug :)
- shortlived 16y ago
  Any downsides to having your own in-house source control system? Got any horror stories of bugs in it?
mattlong 16y ago
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 16y ago
  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 16y ago
    data/transaction/space?
orblivion 16y ago
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 16y ago
  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.
redoxide 16y ago
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.

39 points by Maro 16y ago

swombat 16y ago

Clearly, it's like not having access to HN... Edit: oh, there they are :-)

nathanb 16y ago
This is telling in and of itself...

cobralibre 16y ago

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.

deleted 16y ago
[deleted]

IotaSchizo 16y ago

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.

redoxide 16y ago
"Eating our own dog food" seems to be a popular phrase. Especially when Bug Database has a bug :)
shortlived 16y ago
Any downsides to having your own in-house source control system? Got any horror stories of bugs in it?

mattlong 16y ago

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 16y ago
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 16y ago
  data/transaction/space?

orblivion 16y ago

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 16y ago
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.

redoxide 16y ago

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.