Get live statistics and analysis of Abhimanyu Shekhawat's profile on X / Twitter

This is the follow up of my Big Tech job advice series. I've already talked about the high level framework in my last post. This one is a deep dive into the most important pillar of your preparation; Data Structures & Algorithms CAUTION: > DSA is not trivial. Abandon this thought that it should feel easy. You are training your analytical thinking. It won't improve in 1 week. But I promise you, it'll get better. >Be moldable & persistent. Cliches are true, you'll be able to get really good at this. Be disciplined, carve out time for the practice like an athlete. There is no secret but strategic practice. > This is a highly personal strategy that I recommend & follow. There may be other ways but this works for sure. Strategic plan: > You need to learn 3 things to be successful: - Command over a programming language. -DSA theory. - Ability to convert your abstract solution to working code. > For programming language, choose WHATEVER resource you like, doesn't matter. Make sure you are able to implement all the C++ STL equivalent features. > DSA theory is where you will spend a lot of time. Again, use any resource. Whatever video, book, tutorial. I've used a lot of Codeforces tutorials, college notes, reference books over the years. Your resource stack may differ. Check out Tech interview handbook & CP Algorithms websites, I love them! > Now for the rest of the guide, I'll focus on how to practice & get better. At this point, I am assuming that you have a decent command over language of your choice & DSA theory. > I recommend choosing Leetcode. Most interviewers themselves study from this. Companies use this. The aim is to NOT hope for a familiar question but you need to practice as close as your actual battleground. I love Codeforces a lot. But if your goal is interviews, be laser focused on Leetcode. It is a faster way. > List down all the 10-15 topics that DSA has. Not the variations, just the topics. Ex: Monotonic stack is a variation on Stack. Just note down Stack. You should have a small, cute list of all the topics. > Listing topics is important for the fact that problems are infinite but the topics aren't. You need a stopping condition for your preparation. This way you will feel less anxious when you know that you have practiced say, 5 problems on all these buckets. > Once you know the basic/intermediate level for all the buckets, start applying for jobs. You will have a decent chance of clearing the screening. For rest, you'll get some time. > When you practice, keep a note of the problems, what you did, the misses, if possible, time to solve. THIS STEP WILL SAVE YOUR LIFE LATER. > There is a lot of nuance into thinking about a new problem, I'll cover it in a dedicated post. But in short, make sure that you ONLY mark a problem done, when you implement its MOST optimized solution. In the current market, 2nd best solution is rejected. > Unless you want to work on a topic, ALWAYS solve without seeing the problem tag. This is EXTREMELY important. Half the battle is problem modeling. Practice accordingly. > DON'T neglect implementation. You may think that you undertand Dijkstra but you'll choke when I ask you to apply it in the interview. ALWAYS, ALWAYS implement. > Once you start implementing you'll see that each problem has parts that are redundant. Ex: Binary Search will have a peculiar implementation always. Your another goal for practice is to NEVER think twice during these known implementation blocks. Your time in interview is to apply these known algorithms NOT to get confused between L You'll forget the problems that you've done. Don't shy away from solving tricky problems when you come across them again. > Standardize your algorithms. That is, when you have understood Dijkstra, save the code to your personal code files. Always implement in the same way. This will save time in coding & debugging. > Practice like you are in an interview. Keep talking about the solution as if you are explaining it to someone. Train this muscle. It'll be your second nature during the actual interview. > MOCKS! If you don't do this. YOU WILL FAIL. Try to find a peer group for Mocks, ask help with seniors, use damn AI, but practice Mocks. > When solving, ensure that you understand why other approaches don't work. WHY GREEDY DIDN'T WORK? WHY DID WE CHOOSE DP? Yes it is time consuming. But you'll understand the fundamentals & will be able to apply it to newer problems. > How much you have to practice? Don't aim to do 1000 problems before you apply to your dream role. Apply imperfectly, improvise along the way. I have 100% faith into this methodology. No matter who you are, you can get better at Data Structures & Algorithms. It is just a skill & it can be learnt. If I can become okay at it, you can surely become great. Do not believe anything else. Let me know if you have specific questions, will answer them. Happy learning! 🚀

Kamaal ke admi ho yaar 2 roti ke liye database banane jaate ho.

My first programming language was Java. C was my second due to college curriculum. I really hated C for like a solid 1 semester. Later, I took my Data Structure Course & opted for C++. It was really popular in the competitive coding ecosystem. Wrote a proposal for my Google Summer of Code in C++ & architected the system in Java. Had worked my share of Python too. C++ gave me an opportunity to peek below the surface level. Easily my recommendation for anyone who wants to learn the fundamentals. If you want to just get the job done, maybe steer away from it. But sooner or later, the dues will have to be paid. So, pay them sooner.

This one is for all the Tier-3 college students. I am mentoring a close family member who just started with her college. Below are the steps we are taking to ensure that she has better leverage over time. If you are a Tier-3 college students, pick & choose some of this: Background: Average marks in 12th. Graduation WITHOUT Maths. No specific inclination. Plan for her 1st semester: > Left forensic sciences for Bioinformatics, hence closer to Computer Science. > List down CS courses she can take in 4 years of her BTech. Figure out a plan to cover C & C++ in 1st semester. > Start with DSA asap. Preferably todays the end of the Sem-1 > She had no background of Math & CS so started her with a CS50 course. > Will be providing her the BITS course for C. I learnt from this 10 years back. > Will guide her to translate C to C++. Basic OOP concepts at this time. Geared towards Data Structures. > Making sure that her advanced CS knowledge covers her basic course requirements. (beating the JEE-Boards fallacy) > She need to cover rest of her non CS subjects on her own. Only tutoring her on time management on this. I am sure, if she follows even 80% of this, she will beat 80% of global peers easily.

🥵

I was talking to a seasoned software engineer today. He started in tech in 1985 so he has about 40 years of experience. We chatted a lot about serendipity, working on outages & whether AI is a bubble. One of his comments distinctly stood out for me: The most subtle downside of LLMs are they can't admit that they don't know something, like humans can. Just made me think.

I just completed 4 months at Google. Time for some retrospective. Writing this mostly for my future self. But maybe this will be interesting to some of you. NOTE: This is my personal experience & views are mine alone. Your experience may differ. Don't generalize. A small memo of the last 4 months: > Decent onboarding experience. There are detailed guides for everything. You may feel overwhelmed. But then there are guides to manage that too. Haha! > Great set of peers! The team is super collaborative. They encouraged discussions & gave enough room to explore stuff. Their diverse experience & working styles gave me so much to learn from. > Worked exclusively from the office. It really helped me foster good working relationships with my peers. You gain so much of humane context once you chat about things outside of work areas. We went on outings, dinner etc. Felt the pros of team bonding activities. > Google Spanner is one of the largest databases in the world. If you have a mobile phone, chances are that you are actively querying out DB. The scale is more than 3 Billion queries/sec. Learning so much by deep diving into the system design of it. Extremely relevant to me as I love distributed systems. So win-win getting to work on it. > Got a chance to spearhead some of the impactful initiatives that are at the heart of Google Spanner & distributed systems. The culture of writing a thorough proposal to pilot your design is coming along great for me. > Yeah! Food is great, but then after 14 days you'll be like: Chaand agar mil jaaye toh chaand khaan lagta hai 🤣 > Caught up with so many colleagues & friends working in the office to learn more about their work areas & life stories. This part is one of the crucial segment. Found the people really good at what they do. > Have devised a comprehensive note taking system for my work & learning areas. Loving it! This twitter brain dump is an extension of that. > Enjoying getting the front row seat of all the AI applications & work being done at Google. Keeping myself updated on this. There is so much to learn. I'll get there! The journey of a 1000 commits, begins with a single init. 🚀

This was in 2017 when I was sitting for campus placements. Interviewing for Directi, the former parent company of Codechef. Gaurav Sen used to work there & he too came to our college. The company had a reputation of hiring competitive programmers & being heavy DSA based. The interviewers were just competitive programmers kids, asked some DP on trees kind of problems. These kind of topics were not super popular back then. I was able to make through all the DSA rounds somehow. Was super happy. At one point HR even joked about buying 2 pair of shorts because that is what they wear in their "cool" office. I just had some director round left. Mentally I was already in, this seemed formality. Until... He started grilling me on lower level networking concepts in C. Super anomalous for company famous for asking only DSA. I somehow was in the unlucky lot. This is an age old story. Countless (wo)men, before you have come here & failed. There is no great lesson here. Just pick yourself back up. If they want you to be invincible. Become Invincible.

There are so many people who are claiming that the glorious days of tech are over. Mass layoffs are truly disheartening. I am open to helping in my capacity, those affected. However, I believe that the "Unaccountable, coast in tech" days are over. As problem solvers, we shall adjust to this. Tech still remains a central interest to me. If you are starting in tech, it may be a bit more difficult to find your footing in all this noise. But don't trust anyone who says, tech is done. Layoffs aren't a reflection of your calibre. Most times, there is nothing that you could have done. There is, and will always be a huge demand for people who are good at their craft. If you fall into that bucket, you'll find your way back sooner than later. More power to you. 🚀

The most important hack is to use your brain as a compute & not storage. Write things down. Clear them up sequentially. Also no threading.

Negotiating higher (rightful) salary is a difficult conversation. A little conversation got me 4x of the original stock grant I was offered, in one of my previous companies. Since then, I've always seen this as a crucial part of job hunting. You will be shocked to know how much money you leave on the table by not asking for it. Each word you speak in a negotiation can potentially make you so much of $$$ in a few minutes. I am documenting my thinking on this topic below. My mentees, friends & I have extensively used this for 8 years. We have been satisfied with the outcome. Hope these pointers below help you to multiply your offers too! NOTE: > Only in the rarest of rare cases, a negotiation will harm your position. In almost all of these cases, you'll be able to still join on the starting terms, if the talks don't work out. > Asking for more is NOT evil. Don't feel small about it. Reject anyone who says otherwise. Framework: > Find out what you are worth, what do they pay in that company, years of experience, role. Ask friends, it is okay! You need to find out what is the average & the aspirational range. > Search sites like Glassdoor, Levels & Ambition box for the data. Ask AI infact. Try to gather as many data points as you can. If any of your friend is working in the same company, it is great. Ask for the salary bracket. > Negotiation are won by leverage. The best one is the power to leave. Try to have competing offers. This is often outside your control. But do apply to companies you think you can convert. Use them as your leverage. There is a slight slippery slope of leaving a bad taste for offers you use as stepping stones. Be upfront & professional about it, don't manipulate people, proactively convey your decision to the recruiter, use your discretion. > Don't leave a job to prepare, unless you ABSOLUTELY have to. It'll weaken your position. > Don't lie, but speculate. If you are interviewing somewhere else, you can still use that to signal your worth. In some cases this works. But just put out info you can't substantiate. > If you have no leverage, you still have atleast 1 round of negotiations, where you pitch your desired number. The worst is that they'll say NO. The best is you 4xing your amount. > Don't buy in the crap of fast promotions. Rarely happens. It is far easier to get the money today THAN that hike tomorrow. > Don't believe their lies. > Communicate your expected figure from the start. Don't let them anchor you to some arbitrary figure. Ex: They may quote a lowball figure & portray being gracious by giving 10% increase on that. Why would you accept 10% on the number quoted by them? Why are they starting from that number? Set your own starting point & negotiate from that. Read about Anchoring Effect. > Don't wait for them to get a lowball offer first & then set your expectations. The offer generation takes a lot of approvals, sometimes this entire exercise is tedious & they might not want to do it again. Set your expectations early. > Always be POLITE but FIRM. The money is not coming from the recruiter's pocket (hope not!). Be professional about it. No point in feel bad after a month when you realize that you have been lowballed. > Don't be rash in your dealings. Don't agree to new figures on the spot. Don't reject on the spot. Take time to think. They don't expect an answer directly on the call. You can always say that you need to discuss the offer with your parents. Think about the offer from all the angles. > If you have done some great work in the current company, due for hike or promotion, mention that. Use that. Help your recruiter to sell yourself properly. > Sometimes you'll be told that you are offered this low amount because you didn't perform well in the interviews. Oh really? Then why are they still trying to lock you in. Don't buy into this judgement. You've cleared the bar. The world never negotiates with the runner ups anyway, so you must be the winner. Believe that! > All negotiation is not monetary. See if you can negotiate better work life balance or a better team altogether. After everything is said & done, remember that for most people & in most cases, 1 > 0. You may not always win the negotiation, but the regret of never asking for more is worse. Promise me, you gonna ask for what you are worth. No matter what the market is, no matter what anyone says, you are worth more than you think. So negotiate like it!🚀

Reflections Ep6 I noticed something interesting recently on YouTube. It introduced the 4x speed playback feature. Couldn't understand most of it. But when I bought it down to 2x, I could understand it. This used to happen to 1.5x after reaching 2x. A similar thing happens to our bodies as we lift weight. Once we lift the heavier load, the light ones, feels lighter. Part of the reason is our cognitive adaptation. This is a good news for someone like me who relies on repetitions to get good. If a concepts seems difficult today, I will persist, till it comes naturally to me. When I tried difficult, abstract problems in Math & Computer Science, a lot of earlier problems became easier for me. There is definitely a merit in engaging into activities which makes us think. Tomorrow AI can synthesise best possible sources for you, but if you are the final decision maker, you still need a good amount of thinking. I think, therefore I am.

Typical travel influencer monologue dissing tech: > Hates working 9-5 but loves pleasing algorithm 24x7. > Stops working on boring, hard problems because can't make a reel out of it. > Chooses to chase out trends & talk about shallow repetitive slop. Too many people out there sabotaging their careers without knowing the actual reality. The survivorship bias is insane.

Back in 2021 my friend from Microsoft was dating this girl from PayTM. She used to give him so much of flak for being bullish about Microsoft. Wanted him to sell it off & manage money like how she was doing (insert random Clubhouse gyaan) Since then my friend’s portfolio has doubled along with his take home salary. There is no lesson in this. But I hope, she learnt some.

I was talking to a seasoned software engineer today. He started in tech in 1985 so he has about 40 years of experience. We chatted a lot about serendipity, working on outages & whether AI is a bubble. One of his comments distinctly stood out for me: The most subtle downside of LLMs are they can't admit that they don't know something, like humans can. Just made me think.

I just completed 4 months at Google. Time for some retrospective. Writing this mostly for my future self. But maybe this will be interesting to some of you. NOTE: This is my personal experience & views are mine alone. Your experience may differ. Don't generalize. A small memo of the last 4 months: > Decent onboarding experience. There are detailed guides for everything. You may feel overwhelmed. But then there are guides to manage that too. Haha! > Great set of peers! The team is super collaborative. They encouraged discussions & gave enough room to explore stuff. Their diverse experience & working styles gave me so much to learn from. > Worked exclusively from the office. It really helped me foster good working relationships with my peers. You gain so much of humane context once you chat about things outside of work areas. We went on outings, dinner etc. Felt the pros of team bonding activities. > Google Spanner is one of the largest databases in the world. If you have a mobile phone, chances are that you are actively querying out DB. The scale is more than 3 Billion queries/sec. Learning so much by deep diving into the system design of it. Extremely relevant to me as I love distributed systems. So win-win getting to work on it. > Got a chance to spearhead some of the impactful initiatives that are at the heart of Google Spanner & distributed systems. The culture of writing a thorough proposal to pilot your design is coming along great for me. > Yeah! Food is great, but then after 14 days you'll be like: Chaand agar mil jaaye toh chaand khaan lagta hai 🤣 > Caught up with so many colleagues & friends working in the office to learn more about their work areas & life stories. This part is one of the crucial segment. Found the people really good at what they do. > Have devised a comprehensive note taking system for my work & learning areas. Loving it! This twitter brain dump is an extension of that. > Enjoying getting the front row seat of all the AI applications & work being done at Google. Keeping myself updated on this. There is so much to learn. I'll get there! The journey of a 1000 commits, begins with a single init. 🚀

My first programming language was Java. C was my second due to college curriculum. I really hated C for like a solid 1 semester. Later, I took my Data Structure Course & opted for C++. It was really popular in the competitive coding ecosystem. Wrote a proposal for my Google Summer of Code in C++ & architected the system in Java. Had worked my share of Python too. C++ gave me an opportunity to peek below the surface level. Easily my recommendation for anyone who wants to learn the fundamentals. If you want to just get the job done, maybe steer away from it. But sooner or later, the dues will have to be paid. So, pay them sooner.

This one is for all the Tier-3 college students. I am mentoring a close family member who just started with her college. Below are the steps we are taking to ensure that she has better leverage over time. If you are a Tier-3 college students, pick & choose some of this: Background: Average marks in 12th. Graduation WITHOUT Maths. No specific inclination. Plan for her 1st semester: > Left forensic sciences for Bioinformatics, hence closer to Computer Science. > List down CS courses she can take in 4 years of her BTech. Figure out a plan to cover C & C++ in 1st semester. > Start with DSA asap. Preferably todays the end of the Sem-1 > She had no background of Math & CS so started her with a CS50 course. > Will be providing her the BITS course for C. I learnt from this 10 years back. > Will guide her to translate C to C++. Basic OOP concepts at this time. Geared towards Data Structures. > Making sure that her advanced CS knowledge covers her basic course requirements. (beating the JEE-Boards fallacy) > She need to cover rest of her non CS subjects on her own. Only tutoring her on time management on this. I am sure, if she follows even 80% of this, she will beat 80% of global peers easily.

This is the follow up of my Big Tech job advice series. I've already talked about the high level framework in my last post. This one is a deep dive into the most important pillar of your preparation; Data Structures & Algorithms CAUTION: > DSA is not trivial. Abandon this thought that it should feel easy. You are training your analytical thinking. It won't improve in 1 week. But I promise you, it'll get better. >Be moldable & persistent. Cliches are true, you'll be able to get really good at this. Be disciplined, carve out time for the practice like an athlete. There is no secret but strategic practice. > This is a highly personal strategy that I recommend & follow. There may be other ways but this works for sure. Strategic plan: > You need to learn 3 things to be successful: - Command over a programming language. -DSA theory. - Ability to convert your abstract solution to working code. > For programming language, choose WHATEVER resource you like, doesn't matter. Make sure you are able to implement all the C++ STL equivalent features. > DSA theory is where you will spend a lot of time. Again, use any resource. Whatever video, book, tutorial. I've used a lot of Codeforces tutorials, college notes, reference books over the years. Your resource stack may differ. Check out Tech interview handbook & CP Algorithms websites, I love them! > Now for the rest of the guide, I'll focus on how to practice & get better. At this point, I am assuming that you have a decent command over language of your choice & DSA theory. > I recommend choosing Leetcode. Most interviewers themselves study from this. Companies use this. The aim is to NOT hope for a familiar question but you need to practice as close as your actual battleground. I love Codeforces a lot. But if your goal is interviews, be laser focused on Leetcode. It is a faster way. > List down all the 10-15 topics that DSA has. Not the variations, just the topics. Ex: Monotonic stack is a variation on Stack. Just note down Stack. You should have a small, cute list of all the topics. > Listing topics is important for the fact that problems are infinite but the topics aren't. You need a stopping condition for your preparation. This way you will feel less anxious when you know that you have practiced say, 5 problems on all these buckets. > Once you know the basic/intermediate level for all the buckets, start applying for jobs. You will have a decent chance of clearing the screening. For rest, you'll get some time. > When you practice, keep a note of the problems, what you did, the misses, if possible, time to solve. THIS STEP WILL SAVE YOUR LIFE LATER. > There is a lot of nuance into thinking about a new problem, I'll cover it in a dedicated post. But in short, make sure that you ONLY mark a problem done, when you implement its MOST optimized solution. In the current market, 2nd best solution is rejected. > Unless you want to work on a topic, ALWAYS solve without seeing the problem tag. This is EXTREMELY important. Half the battle is problem modeling. Practice accordingly. > DON'T neglect implementation. You may think that you undertand Dijkstra but you'll choke when I ask you to apply it in the interview. ALWAYS, ALWAYS implement. > Once you start implementing you'll see that each problem has parts that are redundant. Ex: Binary Search will have a peculiar implementation always. Your another goal for practice is to NEVER think twice during these known implementation blocks. Your time in interview is to apply these known algorithms NOT to get confused between L You'll forget the problems that you've done. Don't shy away from solving tricky problems when you come across them again. > Standardize your algorithms. That is, when you have understood Dijkstra, save the code to your personal code files. Always implement in the same way. This will save time in coding & debugging. > Practice like you are in an interview. Keep talking about the solution as if you are explaining it to someone. Train this muscle. It'll be your second nature during the actual interview. > MOCKS! If you don't do this. YOU WILL FAIL. Try to find a peer group for Mocks, ask help with seniors, use damn AI, but practice Mocks. > When solving, ensure that you understand why other approaches don't work. WHY GREEDY DIDN'T WORK? WHY DID WE CHOOSE DP? Yes it is time consuming. But you'll understand the fundamentals & will be able to apply it to newer problems. > How much you have to practice? Don't aim to do 1000 problems before you apply to your dream role. Apply imperfectly, improvise along the way. I have 100% faith into this methodology. No matter who you are, you can get better at Data Structures & Algorithms. It is just a skill & it can be learnt. If I can become okay at it, you can surely become great. Do not believe anything else. Let me know if you have specific questions, will answer them. Happy learning! 🚀

🥵

Typical travel influencer monologue dissing tech: > Hates working 9-5 but loves pleasing algorithm 24x7. > Stops working on boring, hard problems because can't make a reel out of it. > Chooses to chase out trends & talk about shallow repetitive slop. Too many people out there sabotaging their careers without knowing the actual reality. The survivorship bias is insane.

Kamaal ke admi ho yaar 2 roti ke liye database banane jaate ho.

It was never about developers vs competitive coders. It had always been about engaging into things that can actively make you think.

Crazy how most of us never wanted to become a teacher & now look at us sharing things we have learnt 🥰

The joy of learning something new, to be a beginner at something. >>>>

The most important hack is to use your brain as a compute & not storage. Write things down. Clear them up sequentially. Also no threading.

Most of the profitable businesses I see around weren’t ideas that were novel. Just better iterations. Add more to these: > Facebook over Orkut > Chrome over IE

Reflections Ep6 I noticed something interesting recently on YouTube. It introduced the 4x speed playback feature. Couldn't understand most of it. But when I bought it down to 2x, I could understand it. This used to happen to 1.5x after reaching 2x. A similar thing happens to our bodies as we lift weight. Once we lift the heavier load, the light ones, feels lighter. Part of the reason is our cognitive adaptation. This is a good news for someone like me who relies on repetitions to get good. If a concepts seems difficult today, I will persist, till it comes naturally to me. When I tried difficult, abstract problems in Math & Computer Science, a lot of earlier problems became easier for me. There is definitely a merit in engaging into activities which makes us think. Tomorrow AI can synthesise best possible sources for you, but if you are the final decision maker, you still need a good amount of thinking. I think, therefore I am.