The offer letter said “software engineer.” It didn’t say which half of Tuesday you’d spend in Slack threads about a broken staging environment while your actual Jira tickets aged like cheese. That gap – between the job title and the job – is what this post is about.<\/p>\n
The BLS projects around 129,200 software developer openings per year through 2034<\/a>, with 15% employment growth over the decade. More engineers are entering the field every year. But what those engineers actually do from 9 to 6 varies more than any job description admits.<\/p>\n Most engineers I’ve talked to start the same way: Slack messages from overnight deploys, a daily standup at 9:30, and a pull request or two waiting for review. If you’re lucky, that takes 45 minutes. If the deploy broke something, that takes until noon.<\/p>\n Standups sound quick on paper – 15 minutes, three questions, done. The reality is that standups are information collection meetings disguised as coordination meetings. You’re reporting what you did, yes. But you’re also figuring out who’s blocked, who needs context you have, and whether that one backend ticket is actually going to slip the sprint. That takes longer than 15 minutes when the team is seven people and the codebase is five years old.<\/p>\n Senior engineers get less of this, not more. The better you get, the more people pull you into conversations about decisions that haven’t been made yet. Design reviews, architecture discussions, “quick calls” about the Q3 roadmap. The code-writing window gets shorter as seniority goes up, which surprises a lot of people who join big tech expecting to write code all day.<\/p>\n There’s a widely cited GitHub internal study that puts focused coding time at 4 to 5 hours per day for the average engineer. That number is real, but “focused” is doing a lot of work in that sentence. Focused means headphones on, context loaded, IDE open. It doesn’t mean 4-5 hours of actual output.<\/p>\n Deep work is front-loaded. Most engineers do their best coding between 10am and 1pm, then again from 4 to 6pm after the afternoon meeting block clears out. The middle of the day is a graveyard for concentration. This isn’t a discipline problem – it’s the meeting calendar.<\/p>\n AI tools are reshaping this a bit. The 2024 Stack Overflow Developer Survey<\/a> found that 62% of professional developers now use AI tools in their development process, with 85% of those using AI specifically to write code. 81% said increased productivity was the biggest perceived benefit. The practical effect is that autocomplete and AI-assisted search handle more of the mechanical work, which means engineers spend more cognitive effort on the parts AI can’t do: understanding business requirements, navigating tradeoffs, deciding what not to build.<\/p>\n What we see on LastRoundAI mock interviews<\/p>\n When candidates practice system design and behavioral rounds on LastRoundAI, the questions that trip people up most aren’t the algorithm problems. They’re the “walk me through a production incident” questions and the “tell me about a time you pushed back on a product decision” questions. Interviewers care about how you think through ambiguity. Whether you can write a binary search is table stakes. That’s consistent with what engineers actually face day to day.<\/p>\n<\/div>\n<\/div>\n This is where it gets genuinely interesting, and where the job title becomes almost meaningless as a descriptor.<\/p>\n At a seed-stage startup (say, 8 to 20 engineers), you’re writing code, yes, but you’re also debugging your own infrastructure, talking directly to users who filed support tickets, and making product decisions because nobody else is available. The velocity is high. The context-switching is brutal. Engineers who come from big tech and join a seed company in their first month often find that the hardest adjustment isn’t the technical work – it’s that nobody has approved the decision-making framework yet, so you have to develop one on your own.<\/p>\n At a large tech company (Google, Meta, Amazon, Microsoft), the job looks different in almost every way. The codebase is massive and old. Your change touches 4 systems and requires sign-off from 3 teams. You might spend two weeks on a feature that, at a startup, would take two days – because the testing requirements, the rollout process, and the code review pipeline are all real overhead, not bureaucracy for its own sake. You learn to write code that other people can read in three years without you around. That’s a real skill. It’s not the same skill as shipping fast.<\/p>\n The mid-size range – Series B through pre-IPO, roughly 100 to 1,500 engineers – is its own category. You have some process but not ossified process. You can still talk to the person who wrote the original version of the system. The on-call rotations actually page you at 2am, but there’s someone to escalate to. This is where I think a lot of engineers underestimate what they’ll learn; the volume of context you absorb in that environment is high because the decisions are still being made by people you can walk up to.<\/p>\n I want to be honest: I don’t know whether cycling deliberately through company stages (two years here, three years there) actually produces better engineers than going deep at one company for a decade. The evidence is anecdotal. There are exceptional engineers who’ve spent 12 years at Google and have breadth I don’t see in people who’ve job-hopped every 18 months. The cycling argument is probably more valuable for career optionality than for raw technical skill.<\/p>\n Every engineering role above a certain level includes on-call rotation. The frequency depends on team size and system criticality – some teams do one week on-call every 8 weeks, others do it monthly. What nobody tells you before your first week on-call: the pager going off at 3am is not the worst part. The worst part is spending the next morning in a postmortem writing up what happened, while also trying to stay current on your sprint commitments.<\/p>\n On-call is, genuinely, one of the best ways to learn a system. You don’t understand a codebase until it’s broken in production and you have 20 minutes to figure out why. But it’s also a real cost – sleep, cognitive load, the ambient anxiety of a week where your phone might vibrate at any moment. Teams that handle on-call well have runbooks, clear escalation paths, and a culture where a 3am page that you escalated immediately is not held against you. Teams that handle it poorly have all three of those things missing.<\/p>\n When you get the behavioral question “describe a typical day in your current role,” it’s not a calendar question. Interviewers use it to calibrate your ownership instincts, your cross-functional awareness, and whether you think about the job beyond the ticket queue. An answer that’s only about coding reads as junior. An answer that includes mentoring, code review, stakeholder communication, and yes, coding, reads as someone who understands what the job actually is.<\/p>\n This matters for interviews at all levels. A principal engineer who only talks about algorithms in their day-to-day sounds like they haven’t done the job. A junior engineer who can articulate why they asked questions before starting a task sounds like they’ve thought carefully about the work.<\/p>\n If you’re prepping for a software engineering interview, practice this question. Practice for the behavioral questions<\/a> as hard as you practice for the coding round<\/a>. Both matter. Most candidates spend 90% of their prep time on the coding side and wonder why the behavioral feedback is “didn’t demonstrate sufficient leadership.” The interviews are a two-part test and the two parts aren’t weighted equally at most companies.<\/p>\n The day-to-day of a software engineer is a mix of writing code, reviewing code, reading code you didn’t write, sitting in meetings about code that doesn’t exist yet, and fixing code that broke at the worst possible time. The ratio of each depends heavily on company size, team, and seniority level. What stays constant is this: the engineers who progress fastest figure out which of those activities moves the most weight for their team, and then do more of that, even when nobody asked them to.<\/p>\n Whether that instinct is something you can teach in an interview prep session, I genuinely don’t know. But you can at least practice articulating it. Use mock interviews<\/a> to get reps in before the real thing.<\/p>\nThe morning is rarely about code<\/h2>\n
What the actual coding window looks like<\/h2>\n
How the day differs by company stage<\/h2>\n
The on-call shift nobody talks about in interviews<\/h2>\n
What interviewers are actually testing when they ask about your day<\/h2>\n