First was the dress code. Everyone was in suits or dresses, even the developers. Some more relaxed, but everyone looked as if they were from Wall Street. I remember being the least dressed person there interviewing with my khakis and red dress shirt (no tie).
Every hiring manager except one(I interviewed for 5 teams) gave off a holier than thou vibe. One dude was super chill but everyone else had a stick up you know where.
The environments were small open rooms where developers had computers lined next to each other. You would bump elbows with each other. It was very messy and part of me wondered how anything got done being so close to meeting rooms and sales pits with all the noise. Cubicles looked appealing compared to this and that’s saying something. I did not aspire to be a code monkey.
The interviews had ridiculous questions like “why is a manhole cover round?” or “why does a tennis ball have felt?”. The joke of an answer I gave to the first was that it’s so the TMNT can throw them like frisbees. That was not well received.
I got offers from 3 of the teams ultimately. The pay was really terrible and the hours were long for intern work. I took a job working remotely for a local company instead that paid me 70k/yr while I finished my studies.
I’m glad the author had a positive experience and things have changed over the last 10 years.
The men were dressed casually, in jeans and t-shirts, but seeing her able to feel comfortable as herself made me excited to join. This was at a time that Starbucks made baristas cover up visible tattoos, and many professional tech roles at large companies still required "business casual" of khakis & polos.
The idiot that I had the displeasure to talk to was proud of the hellish environment, hero culture and seemed to think that they had some kind of bleeding edge tech there. I needed just a couple of questions to realize that it was crap.
The recruiter had driven me there. He asked if I thought I passed. "I surely hope I didn't!!"
I have to wonder if I worked with some of the managers you interviewed with--that sounds like a familiar phenomenon. A few relaxed people, but lots of folks who brought a NYC investment banking attitude with them to SLC.
That was always one of the worst standard brain-teaser questions because so many people who asked it didn't know the correct answer.
Hint: If your answer was that a circular cover is the only shape that can't fall down the matching hole, everything you think you know about the world is wrong and the term you're looking for is "curve of constant width".
The real answer is because manhole covers are mass produced and manufacturing circular ones is usually easier and cheaper than the alternatives.
https://duckduckgo.com/?q=rectangular+manhole+cover&t=brave&...
https://duckduckgo.com/?q=triangular+manhole+cover&t=brave&i...
https://duckduckgo.com/?q=hexagonal+manhole+cover&t=brave&ia...
https://duckduckgo.com/?q=oval+manhole+cover&t=brave&iar=ima...
And so on... Now a great - though a bit unfair - question would be to ask about circular ones, listen to the standard pitch, and then show these photos and ask - so what's going on here? Are all these people idiots?
A good software engineer knows there are rules, and there are reasons for the rules, and there are reasons why sometimes rules need to be different because the situation is different. If you just learn one single "right" answer, you'd end up trying to fit a round manhole cover into a triangular opening.
My understanding is the primary reason is because circular covers cannot fall into the hole itself, whereas that problem exists with other shapes like squares.
The environments were small open rooms where developers
had computers lined next to each other. You would bump
elbows with each other.
“why does a tennis ball have felt?”
I do like open-ended, "I just want to learn more about the interviewee's thought process" questions in general; I just prefer them to be a little more relevant. Such as,
- how would you troubleshoot particular problem XYZ?
- how would you design the database schema given the following set of requirements?
- what's a controversial/unpopular software development opinion you have?
- what's the best project you ever worked on, and why?
- what's one thing you'd change about $TECHNOLOGY_RELEVANT_TO_THE_ROLE_THEYRE_APPLYING_FOR ?
- etc.
The reason must have to do with either judging or playing the game (otherwise, why bother?). I'm no physicist or aeronautics engineer but I presume the fuzz is relatively negligible on ball speed over short distances, so it's probably not related to how the ball flies. It also doesn't seem realistic that it interacts with the racket or the court. One not so serious thought is perhaps it's got to do with net dynamics but that seems like an edge case I professional play. I haven't really watched tennis but I imagine most volleys end in balls bouncing out of bounds or a player not being able to return a hit. A little excessive to add fuzz for that. I also considered that maybe it's a means of having something adhere to the ball (like if it bounces on the line) but they have high speed cameras and line judges for those sorts of things. Guessing it's not that.
If it doesn't affect the dynamics of the ball or the adjucation of a play, it seems to me that it's instead a more general indicator. You touch the fuzzy ball before every serve and feel the fuzziness. You have a finger sense for a good ball and worn one. If the ball is fuzzy enough, it's good enough. Therefore, it seems to me it's a quality indicator for players to know when to switch out.
And I looked it up, it turns out I'm quite bad at physics! Won't spoil it any further for others trying to guess.
My approach would be to take what I assume the properties of felt are in terms of how they relate to a tennis game and assume that those properties are selected for. So, felt is probably a little cushion, giving the ball a little more durability as it gets whacked by rackets or off the ground. The felt provides grip, without which, a tennis ball may bounce off the ground in ways that are impossible to return. The color of the felt makes the ball easier to see (though of course you could color a nude call too).
Something like that.
The ass?
And that is a key to success which then enables numbers to come into play!
It works for every organisation.
But even if I wasn’t as involved, it’s still easy to see who’s always stepping up to help others and who’s struggling to deliver on their own with nearly any tiny amount of communication with the team.
It’s also really easy to see who’s developing a “not my job, not my problem” attitude. When a team gets to a point where individuals are delivering what they consider “their work” but the team as a whole struggles to deliver anything because everyone avoids the loose ends or refuses to help others, the entire team is getting poor performance reviews.
I’m guessing a “thank you, good job” isn’t what you mean by “gets the reward”.
Truly I've never had trouble getting recognition for extraordinary work, and I've worked at a lot of questionable organizations.
My recent experience (past 5 years) had been with remote teams, where this problem is exaggerated even more. Some people see remote as an excuse to minimize their own workload so they can finish their tickets early and log off as quick as possible.
It takes some mentoring to get employees, remote or otherwise, to understand that the team’s deliverables are what counts rather than just closing the tickets they claimed. As hard as we try, tickets will never account for 100% of the work that needs to be done, especially when it comes to things like sharing knowledge with newer team members and helping with loose ends. Someone who wants to isolate and avoid helping others can’t really be effective in a collaborative team environment.
I remember somebody explaining to me that culture isn't based on what an organization or manager says is rewarded—or even on what's "officially" evaluated—but on what people feel is rewarded and punished. If you're constantly tracking individual tickets, that's what people are going to perceive as important just because the organization's actions place such an emphasis on it.
People aren't "using remote as an excuse", they're responding to the system as it's designed! Frankly, seeing the situation as people "making excuses" is fundamentally counterproductive as a manager—it sounds like you're blaming individual team members for the problem. Starting from that perspective, how can you meaningfully work with the team to improve the system and the culture?
Listen to yourself, you are viewing a way people want to work as a problem.
The way they get the job done ?quickly? and then log off sounds ideal for a change of contract where a basic wage + performance pay could be used to incentivise parts of the workforce which in turn could improve customer satisfaction.
So I wonder if you have spotted an opportunity for change whilst viewing it as a problem?
Where I've noticed more of a breakdown is between teams. Not necessarily in the form of "not my job", but rather a refusal to collaborate. So more "not your turf" fiefdoms.
> It takes some mentoring to get employees, remote or otherwise, to understand that the team’s deliverables are what counts rather than just closing the tickets they claimed. As hard as we try, tickets will never account for 100% of the work that needs to be done, especially when it comes to things like sharing knowledge with newer team members and helping with loose ends. Someone who wants to isolate and avoid helping others can’t really be effective in a collaborative team environment.
This scales out to the inter-team level as well. the organization's success is ultimately paramount. If the company goes out of business, everyone's out looking for a new job.
Loose ends get lost and should be in a ticket.
Team objectives sit with the team leader. Project objectives with the project owner.
Great post! I've been at GS for ~8 years and I can say this is a pretty accurate description of what a GS internship is like nowadays. These 2 points ring out as the most true to me:
1. Lots of red tape. You need to get approvals for any and all access. You're 100% right, its all regulation stuff, but its still annoying as fuck. And since there are so many approvals being requested left and right, managers tend to get swarmed and not really care too much about 99% of requests so its just a matter of chasing to get things approved. To add an annoying cherry on top one of the main systems that you request access through is a bit of a legacy system, so propagation of approvals takes a few hours, which sometimes leaves you sitting on your hands and just waiting. Its not too bad though, and in the last few years a lot of effort has been put into reducing these waiting times.
2. Inhouse building. GS suffered from this a lot, as did all the big banks in the past. All of our legacy is inhouse and it slows us down today. The good news (which you also alluded too) is that for the last ~5 of so years there have been monumental shifts in pushing us towards open-source ways (shameless plug, we even have open source roles we are hiring for: https://bit.ly/3GkJGCM ), so modern development in GS is getting much better.
My only question here which you didn't address in the blog post is: if GS offered you a permanent role, would you take it?
I'm not sure. I got a return offer to intern again for summer 2022. But I ended up taking an internship at Amazon instead. Mostly because I want to try new things and see what it's like to develop at a big company without all the red tape and just in a new environment.
But I can't say that it's completely out of the realm of possibility for me to come back. I think it would largely depend on the team. If I did come back, it'd be cool to work with one of the Cloud teams.
Digging into a particular thread in your post:
> Later I came to realize that they have a culture of building things inhouse and it shows.
> [...]
> The first I noticed was the old tech, as I mentioned before there is a lot of internally maintained technology and that's good for a few reasons like the fact that you're just a message away from contacting the world wide expert for the technology you're using. But it can also have it's downsides, you don't fully benefit from the fruits of Open Source and it could lead to stagnation and slow development.
You've shown some great observations about what might be simplified as "build versus buy", with buy having options like "actually buy" and "adopt FOSS".
As you grow in your career, I encourage you continue to dig even deeper into the ripple effects of this sort of tech decision. Yes, it might have been better tech than the alternatives at one point in time and there are internal experts for that tech one message away. Long term, that can become a form of institutional knowledge (risk) and sunk cost fallacy (we built it, we should continue investing in it).
In other words, remain curious and be willing to question decisions as the context, culture, and challenge evolve!
This is a bit of a tangent but it's something I find surprising in tech (at least the megacorp I work in): institutional knowledge is kept inside people's heads and when they leave, the knowledge is lost and not much is done to stop it.
"That's obvious" you might think but in the US Army for example, there's an organisation [0] that debriefs soldiers returned from deployment and collects their experiences and lessons to disseminate them to the rest of the military (and there are sister organisations in other countries e.g. Australia [1]).
There's an entire field of study dedicated to knowledge management [2] and I know it's present in some large companies but I'm really surprised you never really see it in tech.
[0]: https://en.wikipedia.org/wiki/U.S._Army_Center_for_Army_Less...
[1]: https://cove.army.gov.au/bio/army-knowledge-centre
[2]: https://www.kmworld.com/About/What_is_Knowledge_Management
In your post you mention working around the browser’s maximum URL length. Assuming this is due to the size of the URL parameters containing “data items”, did you consider POSTing the data instead? Also, could you elaborate more on how your solution is able to reconstruct the query on the backend after reducing the URL length by 50%?
Seems like it’s for readability on either end so maybe a dictionary is a solution for when it’s actually used
QIS - quant investment management services is more asset management using data science.
they dont do hft, thats more Millenium or point72, maybe citidel.
end of day they use tech to drive reduced cogs and keep in clients. the front office folks bake off against Morgan Stanley, UBS, et all to offer bespoke products that are ' new and sexy omg wow '
slang is neat insofar as access is concerned, but as one former CFO once said WHY TF U STILL USING SECDB?
I’m so used to the relentless negativity (much of it, unfortunately, justified) that comes from posts that start with “My experience at …”.
I have always been very enthusiastic about tech, and have striven to be positive in my own discussions (which has sometimes been a challenge).
I have often felt as if people consider my attitude a naive anachronism. It’s nice to read enthusiasm from someone at the start of their career. I very much believe in tech, and refuse to treat it as a gladiatorial arena.
I sincerely wish the OP luck.
I’ve helped with some mentoring programs on and off over the years. Most students and grads actually have very positive experiences in their internships and first jobs.
There are exceptions, of course, but they’re more rare than you’d think from reading Reddit CS career advice forums and trending stories on HN.
One recent quirk I’ve been seeing is occasionally a junior person will have a good job but for some reason or another become convinced that they’re working for an abusive company under terrible conditions. It sounds strange if you’ve never seen it, but some young people come into the working world with a lot of weird misconceptions they pick up from Reddit and other social media. For example, I’ve seen multiple young developers have near crises because their companies have code review and their seniors have a lot of feedback and changes in their code reviews. We spend a lot of time mentoring about what’s normal and why getting feedback at work is actually a good thing.
I can believe that they were all friendly and supportive (one reason being that an intern doesn't pose a threat at all), but I am fairly sure they had their own interests firmly above his.
It was explained to me by people who work there that Facebook desperately wants to be as evil as Microsoft or Google, but just can't come close yet.
Consider not bringing up “drama” if you don’t want to share it with the readers. That may have been one of the most interesting leads and it didn’t go anywhere. That sounded like you, while the rest sounded mostly political.
Whether the friendships end up lasting forever or not, what I can tell you is that you'll never forget how you felt on that 7am zoom call or when you got the invite to return later. That excitement is palpable to me as a reader, in the same way that it will be to you as you advance in your career and look back.
I read "surreal" as "it was surreal how whole-heartedly they welcomed us" as opposed to "hiking with your coworkers is a totally surreal, bizarre experience." The surrounding context doesn't support your interpretation at all: the blog post is about how well he was treated, not how strange the experience was.
That didn’t sound like you, it sounded like something you heard e.g.
“open source is good, closed source is bad”
Your criticisms and defenses of Goldman Sachs feel inauthentic
because you haven’t experienced much outside of Goldman Sachs.
It would be an entirely different story if the author was misrepresenting himself, but considering the post is entire
Consider not bringing up “drama” if you don’t want to share it
with the readers.
But you worked for the fucking devil, and karma will take its piece. Please care a little more about who you help.
"I was just doing my job" is why the planet is so fucked, and it's better to realise that at the outset of your career than the end.
I think I tend to automatically think of Goldman as being relatively small and full of bankers coming up with crazy ideas for weird trades or products, but I think that description wouldn’t have been accurate 20 year’s ago (they were then and are now a big company) and certainly isn’t now the company has been public for a while and has business ranging from traditional IB and trading to retail/private banking. This post shows some ‘big corporate’ things like the two weeks of zoom sessions or satellite offices and it seems to me that it is an impressive achievement to be a large company where people seem to take responsibility and get things done.
Certainly the author of this post seemed to get a lot done (even if they seemed a bit overworked). When I compare this to my own employer where we give interns two short projects with different teams, it seems our system may get a better read (two independent opinions instead of one) which can be good for evaluation, but it is hard to come up with good projects that will result in good, reasonably complete things running in production by the time the time is up. And everyone like getting things done and complete.
I didn’t see much written about mentorship but maybe that was left unsaid or maybe it is hard for an intern to write about.
[1] It’s obvious in the sense that most people will agree with the statement (at least in tech) but actions don’t always line up with the statement (e.g. when all Google internships became remote, they decided to pay interns based on where they were rather than where they were going to intern, which was pretty bad for European interns headed for mountain view and led to some silly situations like a bunch of interns travelling across Europe in the middle of 2020 lockdown to make it to Switzerland). And if you look at IB internships, there seems to be a culture of proving oneself by surviving gruelling and unpleasant working conditions.
I think that was the case in the 80s maybe. Alongside obviously traditional investment banking. Emanuel Derman is a legendary quant who was at Goldman for quite a few years and has a great autobiography 'My Life As A Quant' which describes Goldman at the time as quite a small company, relatively speaking.
There is also infamous internal resistance to doing anything too related to consumer banking, which is only just being overcome. People at GS wanted to focus on the glamorous stuff like structured products or mergers and acquisitions, and worried that moving into e.g. retail saving accounts would cause a drop in prestige.
Always be shipping.
Seems like you had a neat opportunity to tackle several different problems across the stack - nice work coming up with solutions to those!
They had you over a barrel mate.
Pretty wild stuff.
However this was great to read.
One, it's nice simply to read about a person having a positive experience. Two, great writing skills! (They will serve you well in your career)
Three, this was useful for me. As a senior dev it's wonderful to have data points like this to learn and reaffirm what kinds of things make positive experiences for interns and junior SWE's.
Ended up getting the job coming from a no name school with minimal experience. The reason why I got it, and why I seem to obtain most of my jobs, is because people say I'm "likeable". To this day, I have no idea what that means in the context of software development, investment banking, or technology in general as I work strictly behind the scenes and never in a client-facing capacity.
I will say, it was the best job I ever had; albeit, our dress code was always full business suits and printers and fax machines were still used. My boss ended up becoming a phenomenal role-model and mentor and taught me how to think critically about my work.
This is a well written summary as well. Reading it brought back memories from my internship at GS 3 years ago. :)
I also wrote a blog post about my experience going from an intern to FTE if you’re interested in checking it out: https://www.goldmansachs.com/what-we-do/transaction-banking/...
Good luck!