Post

More from @championswimmer

Arnav Gupta

@championswimmer

Sep 27

Exactly one year back I made the fateful decision to try dipping my toes in a part of the tech industry I have not remotely been close to - datacenters.

Last 10 years I have built startups and led engineering teams largely around two things - edtech and consumer mobile apps.

A wonderful thing about bigtech hiring process is that often the hiring is generic to a role, and then you get to pick among various teams that have open headcount. (no other way hiring would scale to this size).

Felt like a great opportunity to explore something new.

Every time I have jumped into something new, I love how seeing an industry from the inside leads to insights that are not exactly 'secret' (because there is enough data in papers/blogs/quarterly earnings), but still not common knowledge across the rest of the tech.

Read 24 tweets

Arnav Gupta

@championswimmer

Oct 23, 2024

This post is written by someone who is IIT+IIM, ex CIO (Chief Information Officer, equivalent to CTO in some orgs) and multiple leadership roles.

A lot of business leaders have this level of technical understanding. Hard to build technical things under them.

The problem is not only that they wouldn't have the understanding that the "special laptop" is just having Wifi 6 or higher throughput network card, they won't even have the patience for this to be explained to them, and shout at you thinking you're trying to hoodwink them.

Whenever you hear about "MBA suit types came and destroyed a technical product" (eg: the Boeing story), it is always people like this who are the culprits.

Read 5 tweets

Arnav Gupta

@championswimmer

Jul 27, 2024

How to build an efficient engineering team

1. Instead of paying at 90th percentile, pay at 50th percentile. In this job market you’ll still be able to hire

2. You’ll get SDE2 at 20L instead of 30L, Seniors at 30L instead of 45L and Staff at 50L instead of 70L

3. Hire EMs because the cheaper SDEs are both less productive and less motivated and don’t take ownership. So you need EMs to “drive” and “coach” them

4. Instead of hiring senior PMs, hire APMs from altMBA bootcamps. You’ll easily get APMs at 15L

5. The 7-8 YoE EMs won’t like working with 1-2 YoE APMs and neither of them like to write well structured PRDs or engineering docs, so hire a Director/VP for each team. Obviously the only possible source for getting good Directors/VPs is big tech companies

Read 13 tweets

Arnav Gupta

@championswimmer

Jun 26, 2024

I keep reading about Indian tourists causing a scene (like the Kenya safari tweet thread recently), and got to experience it first hand today

Went to an Indian restaurant in Vienna today after 10+ days of no Indian food, and it looked beautiful from the outside

So it is a Mughal-themed restaurant (Moghul was literally in the name) and had some really nice large paintings of Mughal kings inside

Was talking to the owner - a 30 yr old Punjabi chap, born and brought up in Vienna. His parents running this place since 37 years (now he does)

As we were eating another group of Indians had also come in (mostly all guests were other European folks, this city doesn’t have that many Indians actually)

These were 50-60yr old people, some 3-4 elderly couples.

And they made a whole scene about the Mughal paintings 🤦‍♂️

Read 8 tweets

Arnav Gupta

@championswimmer

May 11, 2024

Forget the typical “roadmaps” and other drivel the “get into tech” cottage industry on YouTube by a bunch of FAANG SDE1s has generated.

If you want to be an SDE2/SDE3 at a typical growth stage product engineering team (eg: Zepto, Upstox, Purplle, LivSpace) would love to get…

…here’s a few well articulated little assignments that’s gonna get you right there in the sweet spot of “highly desirable growth stage engineer” zone

The main pillars are
- structuring code neatly
- strong concurrency fundamentals
- can model non-trivial db schema
- utils 😜

**Structuring Code Neatly**

Rather than mugging up a bunch of theory about 99 types of design patterns and do a bunch of “LLD Courses” it is better to start off with tightly scoped little command line programs, play with the code, implement the same thing 2-3 times and start seeing the mess in your code and looking at ways it can be more “neatly” arranged so you don’t write the same lines multiple times and extending/changing the logic becomes “easy”.

Here’s some examples -

- parsing URLs into scheme, host, port,path,query etc (read the RFC that defines the URL standards)
- create a command line tic tac toe game, then try to write the “bot” that can play against a human
- create a command line “PC builder” - you need to provide a mobo, CPU, GPU, RAM,HDD to build, CPU & mobo socket must match, RAM & CPU speed must match etc

build them twice, or even better thrice (each time starting from scratch)
Makes you understand how rewrites happen
Gives you perspective when building again that you can pre-empt some issues you ran into first time

Once you’ve done this, then parallely reading up a bit of theory doesn’t hurt. Knowing the formal names of Builder pattern or using a visitor class is good. But first write some shitty code, then rewrite it, get to realise why it was shitty first, then learn all these design pattern “labels”

Read 6 tweets

Arnav Gupta

@championswimmer

Mar 7, 2024

1. All engineering teams need some "slack time" (not the chatting app)

2. All engineering teams should be slightly understaffed and perennially non-empty list of things to do

The biggest Engineering Management learning is to reconcile these two truths of work.

There is this famous book by Tom Demarco called "Slack" which is great read on why teams need some 'slack time' - i.e. if the team's capacity is to produce 200 units of work per week, then only plan for 175 units of tasks every week, and kee 25 units free to pick up tasks that come along the way.

Things break.
Suddenly things get re-prioritized.
You encounter weird corner cases working on something, and it takes more time to close.
Shit happens.

Always have some spare time to keep bandwidth for that.

https://x.com/mipsytipsy/status/1620693675293691907?s=20

That said, teams should always be a little understaffed.

Why?

Read this whole thread by @mipsytipsy (on @GergelyOrosz's reportage of Apple hiring policy through COVID)

https://x.com/mipsytipsy/status/1620693675293691907?s=20

Read 9 tweets

Share this page!

Enter URL or ID to Unroll

Arnav Gupta

Try unrolling a thread yourself!

More from @championswimmer

Arnav Gupta

Arnav Gupta

Arnav Gupta

Arnav Gupta

Arnav Gupta

Arnav Gupta

Did Thread Reader help you today?

Don't want to be a Premium member but still want to support us?

Send Email!