6 ms·

Former bloomberg employee here. While the bloomberg service usually runs very well, its built mostley on spaghetti code that has been copy pasta'ed since the 80

by 7sigma 11y ago

Former bloomberg employee here. While the bloomberg service usually runs very well, its built mostley on spaghetti code that has been copy pasta'ed since the 80s and 90s. It might have improved since I worked there, but there were some serious deficiencies in development methodology.

blub 11y ago
Heh, interesting tidbit. I've seen them advertising for positions in London on HN and they gave a good impression.
jacquesm 11y ago
In light of your nickname it's not surprising then that you write 'former'.
apaprocki 11y ago
I don't know when you worked there, but that is not how things are run. Source: I work there.
- bbgtoreuters 11y ago
  This is the same BBG where the huge hairball of C++ wrapped around C wrapped around Fortran makes up the crustry codebase? Where the interview process is still shitty pointer and char array questions? Where they implement their own borked version of the STL? Does anyone internally follow Lakos's books there? (if so or if not, why?)
  - tptacek 11y ago
    My interview at BB involved zero shitty pointer and character array questions. It was challenging but included virtually no trivia whatsoever. And that was in 2004.
    - kenan_warren 11y ago
      I agree, the interviews I did with them recently didn't involve pointer/char array questions. Most of the questions were a lot more interesting compared to interviews I had with other companies at the time. Disclosure: I start at BBG in June.
      - vdnkh 11y ago
        Do you remember any questions? I'm going to be applying there soon and I'd like to know.
    - benstein 11y ago
      My interview at BB actually was 90% about pointers and character arrays, 10% about the keyword static in C. I got the job worked a great 3-4 years there. Also, that was 13 (!) years ago.
    - raldi 11y ago
      My interview in 2003 was mostly legit, though one senior manager's 30-minute segment was all BS of exactly this nature. (His initials were GJ and in the four and a half years I worked there, I discovered he was the closest real-world embodiment of the Dilbert pointy-haired boss I've ever encountered) The most memorable part was: GJ: Name three examples of defensive programming. Me: I'm sorry, I'm not familiar with the term; could you define it? GJ: You know, defensive programming. Me: I've not heard the term, but maybe I know it by a different name; could you describe it? GJ: No, let's move on. Later, I looked it up. He just meant things like `if (p == NULL) return False;`. I knew the concept well, and could've spoken about it intelligently and effortlessly, except I had never heard that particular name for it. Oh, I just remembered another exchange between us: GJ: What's the difference between a segmentation fault and a bus error? Me: [perfect explanation] GJ, seeming disappointed that he hadn't stumped me: Oh, someone already asked you this, huh? Me: No, I know this, because once when I was in college-- GJ: Come on, you looked this up before, didn't you? I wasn't sure how to respond -- I mean, yes, technically I did look it up, once upon a time. How the hell else would I know, derivation from basic axioms? Anyway, I got the job, but I wouldn't be surprised if this other person was interviewed by the same guy and it left a bad taste in their mouth, too. As a senior manager, he probably interviewed 500 candidates a year.
- 7sigma 11y ago
  2005 to 2007, but things might have changed since then. One of the "fond" memories was during our training where the guy basically said that when you compile your function (or app) the first time, you run the command and then get a cup of coffee cause it gonna take at least 20 mins, due to cyclic dependencies in the codebase.
- raldi 11y ago
  Hi Andrew! What I remember from my time there (2003-2007) was how quickly everyone was able to ship code despite (or perhaps because of) no global style guide, unit test mandates, or even rules about copy-pasting code. Each team was able to do things the way they thought best, thanks to an incredibly resilient, flexible production infrastructure that could tolerate, isolate, route around, and quickly repair any newly-introduced bug. The code path (Bloomberg four-letter function, to those familiar with the service) running through the bug could nearly instantly, and if I'm not mistaken, in a totally automated way, be flipped over to a hot backup instance running the previous week's code, and a patch or rollback could be released to the live code almost as soon as it was written. Most tech companies see the problems caused by coding too fast and respond by doing things to slow people down. Bloomberg cured the ills of excess programming velocity by turning the speed up even further. Like Facebook's "Move fast and break things", but with an extra, "...and then move even faster to fix them", and in a way that (mostly) insulated customers from being exposed to the breakage. The fact that it's front-page news when there's a hiccup shows that it's a man-bites-dog event. You'd be in trouble if it wasn't major news when there was a service incident.
  - tomp 11y ago
    That's very interesting, and definitely an infrastructure many companies should strive for and could learn from. I'm wondering, however, not how problems were handled, but how were they detected - code throwing exceptions is the easy case, the real problem is code running almost correctly, but with slightly wrong outputs. I imagine there could be many different "sensibility" checks implemented, (e.g. no negative prices, no huge jumps price jumps), but in general it appears to be a very interesting and complex problem.
- throwawaykf05 11y ago
  It probably depends on what group you work with. I interviewed there a few years ago following a who's hiring post by you (thanks!), and the interviewers seemed to know what they were doing. Didn't work out for me, but it was the group owning the feed, IIRC. However, since then I've interviewed many candidates from Bloomberg, and while they were all very smart, their description of the work they did indicated systems that were at varying levels of WTF. In their defense this was most likely due to legacy reasons. Also, it's funny how Bloomberg candidates inevitably use multicast in their system design interviews, which throws most "web company" interviewers off balance :-)
- digler990 11y ago
  as recently as 2013 there were still libraries that had Fortran dependencies.

by 7sigma 11y ago

blub 11y ago

Heh, interesting tidbit. I've seen them advertising for positions in London on HN and they gave a good impression.

jacquesm 11y ago

In light of your nickname it's not surprising then that you write 'former'.

apaprocki 11y ago

I don't know when you worked there, but that is not how things are run. Source: I work there.

bbgtoreuters 11y ago
This is the same BBG where the huge hairball of C++ wrapped around C wrapped around Fortran makes up the crustry codebase? Where the interview process is still shitty pointer and char array questions? Where they implement their own borked version of the STL? Does anyone internally follow Lakos's books there? (if so or if not, why?)
- tptacek 11y ago
  My interview at BB involved zero shitty pointer and character array questions. It was challenging but included virtually no trivia whatsoever. And that was in 2004.
  - kenan_warren 11y ago
    I agree, the interviews I did with them recently didn't involve pointer/char array questions. Most of the questions were a lot more interesting compared to interviews I had with other companies at the time. Disclosure: I start at BBG in June.
    - vdnkh 11y ago
      Do you remember any questions? I'm going to be applying there soon and I'd like to know.
  - benstein 11y ago
    My interview at BB actually was 90% about pointers and character arrays, 10% about the keyword static in C. I got the job worked a great 3-4 years there. Also, that was 13 (!) years ago.
  - raldi 11y ago
    My interview in 2003 was mostly legit, though one senior manager's 30-minute segment was all BS of exactly this nature. (His initials were GJ and in the four and a half years I worked there, I discovered he was the closest real-world embodiment of the Dilbert pointy-haired boss I've ever encountered) The most memorable part was: GJ: Name three examples of defensive programming. Me: I'm sorry, I'm not familiar with the term; could you define it? GJ: You know, defensive programming. Me: I've not heard the term, but maybe I know it by a different name; could you describe it? GJ: No, let's move on. Later, I looked it up. He just meant things like `if (p == NULL) return False;`. I knew the concept well, and could've spoken about it intelligently and effortlessly, except I had never heard that particular name for it. Oh, I just remembered another exchange between us: GJ: What's the difference between a segmentation fault and a bus error? Me: [perfect explanation] GJ, seeming disappointed that he hadn't stumped me: Oh, someone already asked you this, huh? Me: No, I know this, because once when I was in college-- GJ: Come on, you looked this up before, didn't you? I wasn't sure how to respond -- I mean, yes, technically I did look it up, once upon a time. How the hell else would I know, derivation from basic axioms? Anyway, I got the job, but I wouldn't be surprised if this other person was interviewed by the same guy and it left a bad taste in their mouth, too. As a senior manager, he probably interviewed 500 candidates a year.
7sigma 11y ago
2005 to 2007, but things might have changed since then. One of the "fond" memories was during our training where the guy basically said that when you compile your function (or app) the first time, you run the command and then get a cup of coffee cause it gonna take at least 20 mins, due to cyclic dependencies in the codebase.
raldi 11y ago
Hi Andrew! What I remember from my time there (2003-2007) was how quickly everyone was able to ship code despite (or perhaps because of) no global style guide, unit test mandates, or even rules about copy-pasting code. Each team was able to do things the way they thought best, thanks to an incredibly resilient, flexible production infrastructure that could tolerate, isolate, route around, and quickly repair any newly-introduced bug. The code path (Bloomberg four-letter function, to those familiar with the service) running through the bug could nearly instantly, and if I'm not mistaken, in a totally automated way, be flipped over to a hot backup instance running the previous week's code, and a patch or rollback could be released to the live code almost as soon as it was written. Most tech companies see the problems caused by coding too fast and respond by doing things to slow people down. Bloomberg cured the ills of excess programming velocity by turning the speed up even further. Like Facebook's "Move fast and break things", but with an extra, "...and then move even faster to fix them", and in a way that (mostly) insulated customers from being exposed to the breakage. The fact that it's front-page news when there's a hiccup shows that it's a man-bites-dog event. You'd be in trouble if it wasn't major news when there was a service incident.
- tomp 11y ago
  That's very interesting, and definitely an infrastructure many companies should strive for and could learn from. I'm wondering, however, not how problems were handled, but how were they detected - code throwing exceptions is the easy case, the real problem is code running almost correctly, but with slightly wrong outputs. I imagine there could be many different "sensibility" checks implemented, (e.g. no negative prices, no huge jumps price jumps), but in general it appears to be a very interesting and complex problem.
throwawaykf05 11y ago
It probably depends on what group you work with. I interviewed there a few years ago following a who's hiring post by you (thanks!), and the interviewers seemed to know what they were doing. Didn't work out for me, but it was the group owning the feed, IIRC. However, since then I've interviewed many candidates from Bloomberg, and while they were all very smart, their description of the work they did indicated systems that were at varying levels of WTF. In their defense this was most likely due to legacy reasons. Also, it's funny how Bloomberg candidates inevitably use multicast in their system design interviews, which throws most "web company" interviewers off balance :-)
digler990 11y ago
as recently as 2013 there were still libraries that had Fortran dependencies.