Rohan Bhide

Unpopular Opinion: DSA style interviews are the best way to hire. "I’d never use graphs, trees, or dynamic programming at my job, so why is it asked in interviews?" Over the years, there's been increasing criticism and (unnecessary) hate for data structures and algorithms (DSA) style interviews for FAANG jobs. Critics argue that these interviews focus too much on abstract problems that rarely reflect the actual work engineers do. They claim that this approach filters out candidates who excel in development and specific technologies but may struggle with DSA-heavy interviews. However, here’s why I believe DSA interviews are the best way to hire : 1. Tech Skills Evolve, Problem-Solving Is Timeless: Technology changes rapidly. What’s in demand today might be obsolete tomorrow. Specific language or tech stack skills are fleeting. But problem-solving? That’s the essence of engineering, and it remains constant. DSA interviews assess how well you can solve problems under pressure, which is a core part of what it means to be an engineer. 2. Engineering Is About More Than Just Tools: Knowing Java or having DevOps skills is great, but engineering isn’t just about using tools—it’s about understanding problems deeply and crafting solutions. DSA provides a standardized way to evaluate a candidate’s problem-solving abilities, independent of their familiarity with a particular tool or technology. 3. DSA Is a Medium, Not the Goal: The goal of these interviews isn’t to see if you can regurgitate algorithms from memory. It’s to gauge your ability to think critically, adapt, and apply fundamental concepts to novel situations. These are the skills that will make you a valuable engineer, no matter how the tech landscape evolves. 4. Adaptability Matters: If you're smart, you can quickly pick up new technologies and adapt. This ability to learn and evolve is more valuable than existing experience with a particular skill, especially in an industry that’s always changing. 5. Hard to Fake, Harder to Cheat: It’s challenging to directly assess someone’s technical skills, especially in a short interview. Projects can be exaggerated, faked, or too complex to evaluate quickly. Asking knowledge-based questions is also insufficient. DSA interviews, however, offer a fair and rigorous way to measure a candidate’s true problem-solving abilities. In the end, DSA interviews test more than just your knowledge—they test your engineering mindset. And in a field that’s constantly evolving, that mindset is your greatest asset. What do you think? Let’s keep the conversation going! #TechInterviews #SoftwareEngineering #ProblemSolving #DSA #CareerGrowth #TechSkills #EngineeringMindset #TechIndustry #CodingInterviews #FAANG

131

30 Comments

Top learnings from my discussion with Kishore Gopalakrishna - Language choice for system development should balance team expertise, hiring potential, and ecosystem maturity. A well-implemented system in a familiar language often outperforms a poorly implemented one in a "faster" language. - Distributed systems are complex - they can fail in unexpected ways, making your own computer useless. This challenge is often underestimated. Understand the failure modes. - When building new systems, design for the long-term (10 years) but plan for the near-term (2-3 years). Implement for current needs while keeping the architecture flexible for future growth. Design for long term, plan for short-medium term. - Testing distributed systems requires going beyond known test cases. Develop test frameworks that generate new scenarios automatically to uncover unforeseen issues. - Cost optimization in data systems often involves trade-offs. Kafka, for example, sacrificed transactionality and exact-once delivery for higher throughput and lower cost per log. Its all about the Trade-offs. You get some, you lose some. - When approaching problems, start with first principles. Understand why something is expensive or inefficient before trying to optimize it. Don't jump on a solution. Understand the real problem first. - Open-source success relies heavily on community building. Foster respectful communication, clear processes for resolving conflicts, and a culture of helpfulness to grow a strong contributor base. There are many communities, but only the ones with good culture thrive. - Real-time analytics can significantly boost user engagement. Even small reductions in data latency can lead to measurable improvements in user experience and product value. - When considering real-time analytics, focus on how it can improve your users' lives rather than just technical capabilities. Many support issues can be eliminated by giving users direct access to real-time data. Product isn't useful if it making users' lives better. - Innovation in data products often comes from changing perspective - instead of asking "Do we need this?", ask "How can this improve our users' experience?" This shift can uncover valuable use cases for real-time analytics. Asking the right questions will help you reach the right answers. - When building data products, consider the long-term evolution of technology. Design choices should anticipate future developments, such as improvements in network speed or storage capabilities. Keep your design extensible. - As users become more data-savvy, there's increasing demand for self-serve analytics tools. Empowering users with direct access to data can reduce support overhead and enable more informed decision-making. Empower users to do more with data quickly. ———————————————————————— In case you haven't watched the episode yet, you can watch it here: youtu.be/SmLlJmU9Daw Also subscribe if you like such discussions.

41

3 Comments

Had an interesting interview. The format seemed intentionally averse to DSA, which I found refreshing (although an earlier round was a DSA-style problem, so maybe not super relevant). The interview was set up in 2 main parts: a system design exercise and a code review. In the system design exercise, I was asked to come up with both functional and technical requirements. I am not a product manager, so I wasn’t sure how to come up with the relevant functional requirements with no business stakeholders. If I really had a product manager role, I would identify a need or gap, make a case about the business value with stakeholders, interview users/customers, gather analytics & other usage data, come up with an MVP scope, then build and iterate on the feedback and data. In this exercise, it felt like as a software engineer, I should be asking my interviewers what features it needed, but it didn’t seem like they wanted me asking them for that. They did provide user and scope info but not knowing what the app was supposed to do was a curveball I wasn’t expecting. Since the technical design built off of my incomplete functional design, it ended up chaotic. Interviewers brought up additional functional requirements that I hadn’t included but were apparently important and considered missed. Similarly, in the code review exercise, it wasn’t how I would normally approach a code review. The code was essentially a PR but I could only see one file. I was told to look at it like a very junior developer wrote it and given a list of topics to review like formatting and performance. Normally in a work environment, I would review all the files, have a ticket explaining what the original task was, and have the developer as a resource to answer questions. In retrospect, I regret not clarifying roles, asking what role I was playing and what role the interviewers were filling. Theoretically, if I am designing my own product with few guidelines and no other stakeholders, I should be able to come up with whatever functional requirements I want and there should be no wrong answers unless they explicitly don’t address the scant problem description given. In reality, they were probably looking to emulate an existing product in the market and I should have started there. In the code review, I should have asked if someone could act as the junior developer and I could ask clarifying questions around the purpose of the code. There was one method call in particular that was apparently doing a loop but I don’t recall the method implementation being included and I must not have picked up on the naming. I think that method call was supposed to be refactored outside of a for loop so that it only ran once across the data set, but I didn’t catch that at the time. I should have asked what that method did much earlier, even if I got dinged for it. Good experience though. I enjoyed it overall even if I didn’t perform my best.

4

3 Comments

Amazon-to-Google-to-Amazon #a2g2a thought of the day: Swimming lanes (aka Ownership).  An Amazon SDE is a jack-of-all-trades. You write code, of course. But also, you wear your QA hat and test your stuff. And you wear your SRE hat and carry a pager and respond to tickets. And you wear your TPM and PMT hats too, talk to customers, decide the shape of your product, and track your progress. There’s no such thing as “staying in your lane” when you’re an Amazon SDE. You do what you need to do to make your business successful. After all, one of our Leadership Principles, Ownership, is defined as: “Leaders are owners […] beyond just their own team. They never say ‘that’s not my job.’”   I’ve always felt comfortable operating in that environment, focusing a lot more on helping my business be successful and impactful than on what is or isn’t part of my role doc.   When I joined Google in 2020, I noticed there were very clear swimming lanes for each role. Google had a massive army of thousands of Engineering Productivity engineers dedicated to creating test tools and infrastructure, although in reality they ended up doing a lot of the testing that SDEs really should have done. Google also had an army of thousands of SREs who handled operations and carried pagers. One day, one of my SDEs said he didn’t know what the customer painpoints were for our product because he didn’t have a TPM. “Why don’t you talk to customers yourself???” I asked both puzzled and frustrated. Our customers were other Google engineers. It wasn’t rocket-science to find them and ask them. But it wasn’t an SDE task.   Amazon does have all these other roles. They just don’t have the massive armies of them that Google has. They are more leveraged (eg 100:1 dev:test ratio).   If you just want to write code and not be bothered by “all the other crap” associated with software engineering, Google is paradise. Other people are hired to deal with all that crap you don’t want to deal with it. I would be willing to bet googlers spent a lot more of their day writing code.   There’s also something to be said about the benefits of specializing in a role. EngProdders were masters of test infra, SREs were masters of operations, etc. When you have a narrow job, you go deep; when you have a broad job, you don’t. For example, as an Amazon engineer, I’ve worn TPM and PMT hats a thousand times, but I’m willing to bet I’m a pretty mediocre one.   And so here lies the tension. Specialization is a Good Thing because it brings deep expertise and craftsmanship, but it creates swimming lanes and things fall between the cracks. There’s an overall lack of end-to-end Ownership. I saw that, over, and over, and over again, in my four years at Google. So much "not my problem."   That did not jive with me. I WANT to do "all the other crap." I enjoy it. It empowers me and my team to fully own our destiny and what we deliver to customers. My product sucks? It’s mine to fix. I don’t get to pass the buck. Simple as that.

621

45 Comments

Engineers hate Mondays. That's why I'm giving away free food: 0. How Uber Tracks Billions of Trips: https://lnkd.in/da-c_aKc Author: Arpan G. 1. UML Class Diagram Explained with Examples: https://lnkd.in/dcN--x_8 Author: Ashish Pratap Singh 2. How to Approach Scaling Your Database: https://lnkd.in/degTqAxi Author: Nikki Siapno 3. How to Choose Between Batch, Micro-Batch, and Streaming when Building a Data Pipeline: https://lnkd.in/dQWkXVHq Author: Zach Wilson 4. How Deep is your DOM?: https://lnkd.in/dBcPMz8m Author: Maxi Ferreira 5. How Stripe’s Document Databases Supported 99.999% Uptime With Zero-Downtime Data Migrations: https://lnkd.in/dkpd-A4Y 6. Load Balancing Crash Course: https://lnkd.in/dqvGA65U 7. How Uber Developed a System to Manage Flaky Tests at Scale: https://lnkd.in/dcZ_ExhY Still hungry? I am packaging the other deep dives and trends in today's issue of Hungry Minds. Join 18,001+ software engineers from big tech to startups here: https://lnkd.in/dkJiiBnf What are you reading this week? #softwareengineering #coding #programming

214

51 Comments

Having cleared interviews at Google, Twitter and Intuit I want to share 1 advice on how to crack such companies✅ 👉🏻 Besides learning and practicing DSA, focus on your debugging skills, too! Here are some strategies that I’ve personally used for debugging effectively: ➤ Reproduce the problem: Isolate the issue and create a minimal test case to consistently trigger it. ➤ Don't just blindly try solutions: Analyze the code, hypothesize the cause, and test your theories. ➤ Use tools effectively: Debuggers, logs, and print statements are your best friends. Early in my interview journey, I believed tech interviews were all about coding. But after a few rounds, I realized they actually test your overall approach to problem-solving. This is where many SDEs get stuck. If you find yourself in the same boat, I highly recommend connecting with experienced engineers who can help sharpen your skills. 💪🏻 Just book a FREE session with them at Preplaced: https://lnkd.in/g38QWg85. They’ll guide you in building a strong problem-solving mindset, teach you how to code under pressure and provide active feedback through 1:1 mock coding sessions. Don’t miss out—connect with them today! #debugging #tech #interview #techinterview #collab #preplacedcollab #google

460

10 Comments

Engineers who aren’t using LLMs and have no willingness either are the ones who will find themselves struggling soon. Cause people who do and evolve their coding practices with LLMs will become 10x engineers. LLMs has made programming truly stack independent. All you need to think of is logic and programming fundamentals and don’t need to worry about understanding the syntactical complexity. As long as you know the basics like asynchronous programming, multi threading and memory management, LLMs can help you write any kind of code in any language. Not only that, but they can help you optimize over your current code base. Truly remarkable.

144

4 Comments

Most software engineers don't appreciate the need for writing great mathematical proofs. I am not referring to proofs involving analytics algebra or calculus etc. but proofs that will hold your program correct. Often I have encountered problems in software engineering and ML that I implemented with a "gut feeling". Few such common practices: 1. Implementing a greedy algorithm to a random problem at work when you cannot prove that greedy actually works but have seen correct results with few examples. 2. Using polynomial time dynamic programming to a random problem at work when the problem is in-fact NP-hard and your approach works for a handful of examples and you cannot find or prove that it is infact NP-hard. 3. Using a random cost function in ML and optimization problems or a random activation function in neural networks without understanding its continuity, differentiability etc. 4. Not understanding whether a cost function is a convex or a non-convex and using less-performant algorithms like SGD on convex problems. #artificialintelligence #machinelearning #datascience #dataengineering #mlops #problemsolving

6

Own your promo doc, part 2 out of 2 Part 2 is the story of writing my Senior Engineer to Principal Engineer promo (2013-2014). (Part 1, the story of writing my SDE-II to Senior Engineer promo, is at https://lnkd.in/gMHMzFR4) One thing I wanted to do differently was that the doc should be Forward-Looking (“here’s what I’m going to do” - proactive) rather than the standard “here’s what I did” (reactive). Amazon tends to follow a process called "Working Backwards" in a lot of docs - and I figured it would apply well to promos. I wrote the Forward Looking doc well before I thought I was ready. It didn’t just list the things I had accomplished, but the things I felt I could/should accomplish in the next 12 months. I then shared the doc with a selected group of Directors and Principals around me to seek feedback. The basic question was, “if this document was being discussed a year from now and everything in it was then true, would you be Inclined or Not Inclined? Does it ballpark describe the body of work of a Principal?” It was not a comfortable experiment: I certainly put myself out there and felt very vulnerable. The people I sought feedback from were also very direct and candid and challenged me in uncomfortable ways, but I knew they cared about my growth. Their advice helped me to be focused and deliberate on where I spent my time in the next year. When I felt the doc was good enough, I shared it with my manager. I didn’t get promoted the first time around, but I did get promoted six months after my first failed attempt. That was roughly a year after I initially wrote the doc. This is pretty standard for PE promos - if you get promoted the first time around chances are your manager waited too long! Years later, I was having coffee and catching up with the manager that promoted me to Principal. He said something curious: “You know, I was planning on promoting you, but your doc helped me do this six months earlier!” I had spent about 30 hours of my life writing, revising, incorporating feedback, and thinking about it. I don’t remember what kind of financial benefit getting promoted half a year earlier had for me specifically at the time, but let's use the following thought experiment: just using today’s public numbers from levelsfyi, Amazon L6 averages $405k, Amazon L7 averages 680k, so the difference is $275k/yr. Having L7 compensation six months earlier would mean an additional 138k. Given 30 hours of additional work, that’s an ROI of $5000/hr. I'd say that's a pretty decent ROI for that investment of time! (there were many other benefits to being promoted earlier, but that one is easy to quantify and articulate)

361

21 Comments

When I was a mid senior engineer, one of the senior engineers that I had, used to nitpick a lot in my code reviews. - unnecessary variable name change - comment related to 10 year long vision on something very rudimentary - formatting beyond linters, suggesting against code consistency - blocking reviews for not having time to review - making suggestions without context or without asking clarification questions I talked to him 1:1 to understand what’s the issue or why he does what he does? He said he is just following guidelines of ‘clean code’ book. 😅 (I also had read the book before). Well, to my surprise, he wasn’t following the essence of the book. Instead, he was doing counter productive things: - doing more of personal attacks and sarcasm in code review comments - not finding any real bugs - slowing down delivery of the code - showing false sense of seniority When I talked to others peers Engineers about it, they were also the victims of his rude and nitpicky behavior. The result? He lost trust and respect among his peers and juniors. It was escalated to his manager and he got joint feedback. But he was saved because he was good at buttering up his manager. But that was the day I realized: - I should never be like him once I become senior or staff engineer - A code review is about finding the balance between identifying improvements and fostering a collaborative learning environment. My suggestion to you: Never be like him. —— Follow Gourav Khanijoe for interesting stories helping you become true leader #BeASeniorYouAlwaysWantedToHave

276

32 Comments

Some LLMs are good at writing scripts, some are good at code, some are good at emails, and some are good at teaching you things. But where do you get all of them in one place? Introducing Poe. In Poe, you can choose from an array of LLMs and select whichever LLM you want for your particular use case. You want to understand inflation? You can summon ChatGPT by writing @ChatGPT You need help writing a script or an email? Mention @Claude Just like this, you have multiple LLMs at your fingertips. Some LLMs will very clearly be good at very particular things, and tools like Poe are going to become more relevant because you want one place to access everything. Interestingly, Poe is founded by Adam D'Angelo, who's the founder of Quora and who's also a board member at OpenAI. Access Poe here: https://poe.com/ #llm #poe #chatgpt #openai

48

2 Comments

This is a great article by Rohit Krishnan (https://lnkd.in/g4xjdzMS) about what LLMs are currently capable of doing and it mirrors some of my own observations on the subject. However, it is a bit of a longer read and uses a fair amount of AI and computer science related vocabulary. Here are some of the highlights (pulled directly from the article including the conclusions): --- It might be best to say that LLMs demonstrate incredible intuition but limited intelligence. It can answer almost any question that can be answered in one intuitive pass. And given sufficient training data and enough iterations, it can work up to a facsimile of reasoned intelligence. --- But it is also an excellent example of the distinction between Kuhn's paradigms. Humans are ridiculously bad at judging the impacts of scale. They have been trained on more information than a human being can hope to even see in a lifetime. Assuming a human can read 300 words a min and 8 hours of reading time a day, they would read over a 30,000 to 50,000 books in their lifetime. Most people would manage perhaps a meagre subset of that, at best 1% of it. That’s at best 1 GB of data. LLMs on the other hand, have imbibed everything on the internet and much else besides, hundreds of billions of words across all domains and disciplines. GPT-3 was trained on 45 terabytes of data. Doing the same math of 2MB per book that’s around 22.5 million books. — Conclusions: So, here’s what we have learnt. 1. There exists certain classes of problems which can’t be solved by LLMs as they are today, the ones which require longer series of reasoning steps, especially if they’re dependent on previous states or predicting future ones. Playing Wordle or predicting CA are examples of this. 2. With larger LLMs, we can teach it reasoning, somewhat, by giving it step by step information about the problem and multiple examples to follow. This, however, abstracts the actual problem and puts the way to think about the answer into the prompt. 3. This gets better with a) better prompting, b) intermediate access to memory and compute and tools. But it will not be able to reach generalisable sentience the way we use that word w.r.t humans. Any information we’ve fed the LLM can probably be elicited given the right prompt. 4. Therefore, an enormous part of using the models properly is the prompt them properly per the task at hand. This might require carefully constructing long sequences of right and wrong answers for computational problems, to prime the model to reply appropriately, with external guardrails. 5. This, because ‘attention’ suffers from goal drift, is really hard to make reliable without significant external scaffolding. The mistakes LLMs make are far more instructive than their successes. — https://lnkd.in/gQm-ZPPh

5

2 Comments

If you fudge the numbers on your "AI" product, the more engineering oriented folks in the industry WILL figure it out. People will decompile your benchmark code and see what your language's optimizer is doing. People will compare your batch sizes with the SOTAs you showed in your benchmarks. And the list of engineering sanity checks go on. Of course, plenty will still fudge their numbers and plenty will fall for it. And of course, plenty will be surprised when the hype bubble pops. #fudge #hype #machinelearning #engineering

3

I've led 100+ System Design Interviews in my career. Here's how I'd crack the SDI at a place like Microsoft if I had to do it again today: 👇 𝗦𝘁𝗮𝗿𝘁 𝘄𝗶𝘁𝗵 𝗮 𝗯𝗼𝗶𝗹𝗲𝗿𝗽𝗹𝗮𝘁𝗲 𝗦𝘆𝘀𝘁𝗲𝗺 𝗗𝗲𝘀𝗶𝗴𝗻 𝗳𝗿𝗮𝗺𝗲𝘄𝗼𝗿𝗸: The RESHADED framework is a handy way to quickly break down the key elements of any design problem. 𝗗𝗼𝗻’𝘁 𝘂𝗻𝗱𝗲𝗿𝗲𝘀𝘁𝗶𝗺𝗮𝘁𝗲 𝘀𝗼𝗳𝘁 𝘀𝗸𝗶𝗹𝗹𝘀: Define the scope of the problem, don't be afraid to ask your interviewer plenty of questions… and then be prepared to communicate and rationalize the tradeoffs you make. 𝗧𝗮𝗸𝗲 𝗮𝗱𝘃𝗮𝗻𝘁𝗮𝗴𝗲 𝗼𝗳 𝗯𝗮𝘁𝘁𝗹𝗲-𝘁𝗲𝘀𝘁𝗲𝗱 𝗶𝗻𝘁𝗲𝗿𝘃𝗶𝗲𝘄 𝗽𝗿𝗲𝗽 𝗿𝗲𝘀𝗼𝘂𝗿𝗰𝗲𝘀: I recently wrote a completely free course where I captured all my best insights from interviewing candidates at Meta and Microsoft. You can check it out here: https://educat.tv/4cydH2b Good luck — and happy learning! #systemdesign #softwareengineer #interviewprep

30

1 Comment

Google recently admitted that 25% of all their codes are written by AI. It is a stark reminder for all aspiring software engineers/ AI engineers to become exceptionally good at math and logic to stay relevant in their field. It is not going to be so easy to become a software engineer for every other B.E / B.Tech passouts. Think beyond software development / A.I. Development. There will be a small select pool of highly intelligent and talented people who will develop these. The rest should focus more on leveraging the tech stack to make value / purpose out of it. #google #genai #ai

44

https://lnkd.in/gqUkq3BM is an excellent overview of major topics in LLMs. If you are getting started in this space, this video which is also generated by another LLM 😂 , is a great place to begin your journey in this exciting area of AI. It covers topics like pre-training, evolution of GPTs and other popular LLMs, fine tuning (SFT, PEFT like LORA, RLHF), inference optimizations (quantization, speculative decoding, distillation, flash attention), output sampling techniques, multimodal capabilities and finally some real world applications like math, coding, medicine etc. Loved their analogies even for core complex concepts like flash attention - "it's like finetuning the engine of a car, to make it more fuel efficient, without changing how the car drives"

24

So in a recent interaction I realised that people working on code gen / analysis tool are heavily skeptical of mere embedding based retrieval system based on LLMs for code correction. I mean prediction next token might get me as far suggesting code which I don't mind if it's vaguely incorrect. Heck I use cody and just reject useless code suggestions sometimes. syntactically correct, symantically makes zero sense. Pretty confident as context length increases and models get faster for tracking larger codebase these issues should go away. But you flip the problem into code correction and understanding what the code does 🤔 I doubt how far most LLMs would go. even the ones trained around a large repository of only source code. Kinda make sense being able to train/finetune on AST inputs to actually understand code than trying to shove text and hope that the system understand some structure. #llms #codegen

13

What people think Software Engineering is V/S What it actually is What People Think: — browsing Stack Overflow for answers — copying code from ChatGPT — developing buggy softwares — infinite money printing machine What it actually is: — saying "No updates from my side" in daily stand ups — not sleeping thinking about a random bug — always blaming the code author but never fixing — becoming the go-to person for all tech issues in your family — testing in production because YOLO #softwareengineering

87

9 Comments

Back at Meta, I worked with a 10x engineer who grew from senior to staff in just 1 year, 5x faster than average. Here was his secret for insane growth: Embrace looking like an idiot. This engineer joined my team, which entirely did Android. However, he came from an iOS background and had never written Android code before. Instead of spending months doing tutorials and reading docs, he just started hacking code together, putting out a PR within his 1st week. It was literally some of the worst Android code I had ever seen. So I left a lot of feedback. And several other engineers left a lot of feedback. His mountain of mistakes didn't phase him at all, quite the opposite. He happily took all the feedback and asked follow-up questions, eager for more. He repeated this process constantly, and after ~2 months, he was writing more code than 95% of the team, including me. You couldn't even tell that he was new to Android. If you want to grow fast, completely let go of your fear and ego. To learn the other tactics this engineer used to learn so quickly, check out my in-depth explainer here: https://lnkd.in/giW8N4FP #techcareergrowth #softwareengineering #staffengineer #growthtips #meta

15,289

455 Comments