Career Growth

A recurring early question was how to avoid committing to a number too early. The synthesized advice from the industry:

• Don't try to dodge outright - recruiters ask this early precisely because they want to filter for budget fit. Instead, flip the question back: ask about the role's scope, seniority expectations, location, and responsibilities first - this implicitly signals "I don't have enough information yet" without bluntly refusing to answer.
• Pre-research your range. Before any call, build a personal salary band using public data (levels.fyi, Blind, Glassdoor, H1B disclosure data, etc.) across multiple comparable companies. Ask for the top of your realistic band, which leaves room to negotiate down if needed.
• Filter recruiters by budget fit early. If a company's band clearly doesn't reach your range, it's fine to respectfully decline early rather than go through a full loop for nothing.
• Build a justification for asking for top-of-band pay. This could be: your current salary, years of experience, hard-to-find industry connections, or an imminent promotion/raise that you want "baked in" to a new offer.

Core framework shared in interview-prep:

• You need leverage. In descending order of strength: (1) a competing/counter offer (hardest to get but strongest), (2) a credible willingness to walk away (e.g., cost-of-living or family constraints that genuinely require a higher number), (3) your current trajectory (e.g., "I'm on a promotion track that hits $X in 6 months - I need that reflected now").
• Negotiate beyond base salary when the recruiter says they're capped on salary: more PTO, larger sign-on bonus, more equity are all common levers.
• Don't be afraid to "offend" with a big ask. Companies have already sunk real cost (often estimated in the industry at $10K+ in recruiter/engineering time) into getting a candidate to offer stage - restarting that process is expensive for them, so they'll usually still come to the table even after an ambitious ask.
• Never accept a verbal offer. Recruiters may lowball verbally while you're emotionally invested ("peak excitement phase"). Always insist on a full written offer (base, bonus, equity, healthcare, 401(k) match, everything) before negotiating or accepting.

expert-led framework for where to focus study time, based on the standard big-tech interview funnel:

1. OA (Online Assessment) - usually LeetCode-style
2. Coding round - could be DSA, or "practical" prompts like "design a parking lot," chess, battleship
3. System design - essentially always present for mid-level+, sometimes even at entry-level now
4. Panel / "super day" - hiring manager + multiple engineers, mixing system design and DSA

Diagnostic rule: study whichever stage you're actually failing at, in order - if you're not getting OAs, the problem is resume/projects, not LeetCode; if you're failing OAs, it's LeetCode; if you're failing coding rounds, it's LeetCode + communication; if you're failing system design, study system design specifically. Of all the rounds, system design was called out as the most useful for the actual job, not just for passing interviews - a signal that industry interviews are shifting weight toward it (echoed later by multiple experienced professionals noting new-grad interviews are trending more system-design-heavy, even relative to raw LeetCode).

Recurring advice across experienced perspectives:

• Solve a real (even small/personal) problem rather than picking a "resume-shaped" project. illustrative example: he was personally interested in learning system design, noticed everyone else had the same problem (no fast way to practice it daily), and built this guide to solve it for himself and others. The generalizable pattern: find something annoying in your own life -> assume many other people share that annoyance -> build the smallest version of a fix.
• "Solving a problem with impact" and "building something you're personally interested in" were explicitly reconciled as the same underlying strategy done well - impact naturally follows from a real, felt problem, rather than being a separate axis you need to separately optimize for.
• For depth-focused portfolio building (e.g., wanting more "distributed systems" or "low-level" credibility while your day job is AI-heavy), the advice was to find a domain-specific angle (e.g., a finance-adjacent high-performance analytics system, or a distributed data platform for a specific vertical) rather than a generic CRUD app.

On the question of whether a fully remote manager during an internship is a red flag: the industry consensus was mostly downsides - internships derive a lot of value from in-person relationship-building, mentorship, and organic networking that's harder remotely. Mitigation strategy offered:

• Be deliberate about relationship-building in every 1:1 - spend the first ~10 minutes on non-work topics (where they live, hobbies, what they like about the company).
• The relationships you build during an internship can matter as much or more than the actual project work for your long-term trajectory. A practical example: a "mediocre" project performance at Amazon still led to a return offer and a fast promotion, credited specifically to strong relationship-building during the internship.

A widely-endorsed practice across multiple threads (also echoed independently by different experienced professionals without prompting, suggesting it's a broadly useful habit):

• Keep a running "brag sheet" logging accomplishments at the time they happen, not reconstructed later. Use a simple formula: "Accomplished [X], as measured by [Y], by doing [Z]."
• For each entry, save supporting evidence immediately: screenshots of praise/feedback (e.g., from senior engineers from experienced colleagues), links to the PR/commit, and adoption/usage metrics over the following weeks.
• This turns promo packets and resume updates from "trying to remember what I did 6 months ago" into "copy from my doc." One experienced professional described using this exact method to assemble evidence for a bar-raiser review at Amazon in minutes instead of hours.
• Several experienced professionals independently confirmed feeding this kind of raw documentation (notes, Jira summaries, standup notes, playbooks, scripts) into an LLM (specifically Claude) alongside target job descriptions to help extract and reframe the most relevant accomplishments into resume bullets, then iterating based on interview outcomes.
• For behavioral-interview prep specifically: documenting work as it happens also solves the common problem of "I've done a lot but can't think of a specific story on the spot" - go back through your notes and match real events to common behavioral question categories.

• Cloud infra / DevOps / SRE path (Germany-based student): choice between a specialized applied-tech school (heavy on Kubernetes/DevOps/Linux) versus a more general, code-heavy, autonomous-learning-style school. An experienced professional with hands-on French engineering/DevOps experience recommended favoring the specialized/engineering-school route for an infra-focused path (a heavily code-centric, "pure software engineer" school was seen as a detour for that goal), and specifically recommended:
  • A dual work-study program ("alternance" in France) - working part-time in a real company while studying - as a way to get hands-on cloud experience that schools often can't afford to provide (real AWS/Azure environments are expensive to run for students).
  • Focus areas for a lean, "what's actually needed" cloud/infra track: Kubernetes, Terraform (IaC), and deep competence in one major cloud provider - the reasoning being that cloud concepts transfer across providers once you deeply know one.
  • DevOps was framed as a team-wide mindset, not just an isolated job title.
• Choosing a track/rotation inside a large company (e.g., a big-company internship with lots of latitude): the advice was to evaluate culture and investment level per org/department, not just the company brand. Rule of thumb: gravitate toward parts of the business the company is currently investing heavily in and growing - new/expanding teams mean less tech debt, more greenfield building, and typically faster promotion cycles, since expanding orgs need more leadership slots.
• Infra/security -> engineering pivot (from a GRC/security background wanting to do "real" engineering): the suggested path was to self-study the relevant infra skills, then explicitly ask to take on some of that work informally to build a track record, or pursue an internal team transfer, which often has a more lenient interview bar for internal candidates than an external hire would face.
• DevSecOps pivot (from full-stack, mid-career): one an experienced professional's stated reasoning for moving toward infra/security work: disliking front-end work (compounded by AI increasingly automating a lot of front-end implementation), wanting more hands-on autonomy and architecture-level impact, and viewing infra-adjacent skills as more insulated from AI-driven headcount pressure than pure front-end implementation work.
• General observation on senior/staff-level responsibility: system design and architecture decisions were described as commonly falling to staff/principal engineers - sometimes as the original author of a design, more often as a reviewer/consultant poking holes in a design before or during implementation. One senior/staff experienced professionals described their current day-to-day as: most raw coding is now done by AI agents, so design sessions and code review consume the majority of an experienced engineer's time.