Bloomberg is an excellent company and, before I had first-hand experience, I was inclined to think that people who write negative reviews on glassdoor about the interview process were somehow resentful for not receiving an offer. Unfortunately, it turns out that the quality of the interview process varies dramatically depending on who the interviewers are. In my case, the whole process was quite uneven, ranging from enjoyable (who would think that being interviewed can be fun) to absurd. Their HR department is very professional and prompt in their communication with the candidates. More specifically about the interviews. I had a phone interview with a team leader who was quite sharp and in control of the interviewing process in the sense that he was adapting quickly to my responses and moved swiftly from very basic warm-up questions (e.g., what is a pointer) to relatively advanced ones that allowed him to identify where the limits of my knowledge on C++ lie (e.g, virtual functions in constructors, resuming execution after catching an exception). I was subsequently invited for an in-hourse interview that was a complete disappointment. I cannot know with certainty, but probably one of the two interviewers was leading the interview and he was unable to clearly articulate his questions. When I was trying to elicit more information, after spelling out what first thoughts I already had on the question in hand, he seemed to interpret the request for clarification as evasion on my part. I believe that the interview was actually cut short since the only algorithmic question I was asked (besides other questions) was to find the character that is *consecutively* repeated most times in a string of arbitrary length. I did that, however I was explicitly asked not to rush into writing code and to discuss the problem first. So it seemed that such a simple task was taking a while, and I know that many people use speed as an important indicator especially when the question is a simple one, however it was the interviewers who set the pace in this case. The atmosphere was friendly and we chatted quite a bit, however, as far as the technical aspects are concerned, it is not possible to tell what they were looking for and why they were not satisfied. Unfortunately, I have this bad habit of claiming ignorance if I do not really know a topic in depth, instead of waving my hands and dropping a few buzzwords. For example, when asked about mutli-threading, I simply state that I do not know multi-threaded programming because I appreciate the myriad of complexities that I have not spent time thinking about. I have written simple number crunching programs with multiple threads, but, in my mind, this is not what *knowing* concurrency means. In an interview it is probably advantageous to act like a salesman.