Getting hired in Big Tech as a software engineer

Hemant describes a hybrid week at Meta split among meetings, coding, design work, reviews, and mentoring. A senior engineer may spend roughly a third of the time aligning people and another substantial block implementing or reviewing code. The job is not simply uninterrupted programming; coordination becomes part of delivering reliable software across a large organization.

The biggest change from junior to senior engineering is ownership. A junior engineer can be evaluated mainly on a well-scoped implementation. A senior engineer must help define the scope, delegate pieces, unblock others, and remain accountable for the final outcome. Writing less code on a project can still represent greater technical responsibility.

He describes an 'uber tech lead' archetype: an engineer who can lead a project across architecture, execution, product tradeoffs, and team boundaries. Other engineers may grow as deep coding specialists. Hemant does not claim everyone must become a manager-shaped generalist; strong organizations need both technical leadership and exceptional implementation depth.

A technical lead often overlaps with product managers, data scientists, designers, and program managers because system choices affect each function. The engineer still needs to protect technical quality, but must translate constraints into language other teams can act on. Communication is therefore part of engineering performance, not a soft extra added after the code works.

Hemant studied at Indraprastha University in Delhi, completed a computer-science master's at Stony Brook, and entered US technology work through an Amazon internship. His path into big tech accumulated through education, internships, and repeated switches rather than one decisive credential that guaranteed the rest of the career.

At Tesla in 2018, he worked during the Model 3 production push and was then laid off. Severance gave him only a few months of runway, while immigration status increased the urgency of finding another employer. The experience taught him that an admired company name does not remove career risk and that workers need savings, preparation, and options.

He next worked on multicloud technology at SAP and later moved to Salesforce, partly for stronger compensation and growth. The sequence shows how adjacent platform experience can transfer: backend systems, cloud infrastructure, APIs, and distributed services appear under different product names, but the underlying engineering decisions recur.

During the pandemic, Hemant advanced from member of technical staff to senior member of technical staff at Salesforce. He attributes the promotion to delivering beyond assigned tickets, understanding the larger system, and helping the team execute. Promotion evidence came from sustained scope and impact, not simply tenure or solving more interview problems.

The 2021 hiring market produced offers from TikTok, LinkedIn, Square, Splunk, and Meta. He chose Meta and entered at E5, a senior level above his prior title. That outcome belongs to an unusually hot market and his accumulated experience; it should not be read as a promise that the same application strategy produces identical results today.

His first year at Meta required ten-to-twelve-hour days while he learned unfamiliar systems, expectations, and internal tools. The pace later stabilized as he built context. Hemant shares the ramp honestly because joining a prestigious company at a higher level can increase pressure: the title arrives before the employee possesses the organization's local knowledge.

Hemant's stack changed repeatedly. Tesla involved C#, SQL, jQuery, and an MVP-style architecture; SAP brought Python, Go, and cloud systems; later teams used other languages and internal frameworks. He argues that languages transfer when engineers understand data structures, APIs, debugging, architecture, and how to learn a codebase.

For beginners, he recommends mastering arrays, strings, hash maps, stacks, queues, trees, and graphs before chasing obscure problems. Those structures recur in interviews and production code. The goal is not to repeat definitions, but to recognize the cost of operations and choose a representation that makes the required behavior simpler.

Thousands of LeetCode questions create the illusion that preparation has no finish line. Hemant suggests learning patterns from a bounded list, then practicing enough variants to recognize them under pressure. Candidates should explain assumptions and tradeoffs aloud, because interviewers evaluate communication and reasoning in addition to whether the final code passes.

System-design preparation becomes more important with experience. A senior candidate should clarify requirements, estimate scale, define components and data flows, identify bottlenecks, and explain tradeoffs such as consistency, latency, durability, and cost. Memorizing one architecture is brittle; the interview changes when the constraints change.

He advises engineers to understand the business and user behavior surrounding a service. A technically elegant change can fail if it does not solve the actual problem or cannot be operated by the team. Strong engineers connect code quality to reliability, developer speed, customer impact, and the risks the company is trying to manage.

Mentorship accelerated Hemant because experienced colleagues could point out what a team valued before he discovered it through failed cycles. He recommends asking for specific feedback on designs, reviews, and promotion gaps. A vague request to 'mentor me' is harder to answer than bringing a concrete decision or artifact for critique.

Hemant's definition of a ten-times engineer is not someone who types ten times faster. The multiplier comes from choosing the right problem, creating reusable systems, preventing failures, improving other engineers, and communicating early enough to avoid wasted work. Individual brilliance that leaves the team confused can reduce total output rather than multiply it.

He started a software-engineering newsletter to organize what he was learning and make it useful outside his immediate team. Writing forced him to turn intuition into an argument another engineer could inspect. It also created public proof of expertise that was independent of any single employer or social platform.

An email list gives a creator a direct relationship with readers, while a social feed can change distribution without warning. Hemant still uses platforms for discovery, but treats the newsletter and associated resources as durable infrastructure. The broader career lesson is to build some reputation and audience that can travel with you.

Regular publishing improved his structured writing, which then helped with design documents, technical proposals, and cross-team communication. The benefit was not only followers. Explaining a concept to outsiders exposed gaps in his own thinking and made him more precise when advocating for an engineering decision at work.

Hemant uses generative-AI tools for code pointers, drafting, calculations, and navigating internal knowledge. He treats the result as a starting point that still requires review. Productivity gains are useful only when the engineer can detect incorrect code, missing context, privacy concerns, and assumptions that do not fit the production system.

He is skeptical of publishing generic AI-written material under a person's name. A tool can help organize or revise, but readers respond to experience, examples, and a recognizable point of view. The same principle applies to career portfolios: generated polish cannot replace evidence that the candidate understood and made the decisions described.

At Meta, Hemant worked on youth-integrity problems involving safer experiences for younger users. The work required policy, product, data, and engineering collaboration because safety rules must become enforceable system behavior. He discusses the area at a high level rather than disclosing internal implementation details.

One example is a family-center experience through which parents can manage consent or time-related controls across products such as Facebook, Instagram, Messenger, or Oculus. Hemant uses it to illustrate large-company complexity: a user-facing control can require identity, policy, privacy, and infrastructure work across several organizations.

For students facing a weak market, Hemant says not to interpret rejection as a complete verdict on ability. His practical routine is broad daily applications combined with preparation in coding, system design, resume evidence, and projects. Visa status, location, timing, and role fit all affect outcomes, so candidates should preserve multiple paths.

He shares a historical funnel of roughly two hundred applications leading to about ten recruiter conversations, three or four onsite processes, and one or two offers. The numbers are not a universal benchmark. Their value is emotional and operational: a low response rate can be normal, so applicants need enough volume without abandoning targeted preparation.

Naman closes the conversation after tracing Hemant's path through layoffs, promotions, company switches, senior-engineering scope, interview preparation, writing, and AI-assisted work. The episode's company and hiring observations reflect Hemant's experience at the time of recording and should be checked against current roles and policies.