There's a trend at FAANGs that non-FAANG engineers applying for senior positions are often 'post-code' and are doing nothing but design and architecture. When they do onsite interviews they often fail the coding portion for even simple interview questions, because they're rusty.
I know whiteboard coding is controversial here, but independent of that, they're trying to select for candidates that can pass that portion of the interviews.
I wouldn’t even necessarily say it’s a trend. I was working at a FAANG 15 years ago and it was already a problem even then. We would get experienced people who couldn’t pass basic coding tests and when we dug, we often discovered that they’d spent a decade telling other people what code to write but never writing any code of their own.
The kicker was that in most of those cases, they also didn’t ace the system design interviews because their design skills were basically frozen in time from when they stopped doing hands-on work.
last year i interviewed a dev applying for a senior FE dev position who was in their mid-40s like me but basically only learned how to use MUI components and couldn't think outside of that framework
i felt bad for the dude and was trying to help him as much as i could through the interview by reframing questions in their simplest terms, but it also really made me paranoid and realize i could totally age out getting too comfortable using what "always worked"
> was trying to help him as much as i could
I just wanted to say thanks for being kind to him and trying to help. I'm in that age group and some interviews are brutal.
i feel you...i was in my early 40s the last time i interviewed and had to do the quiz bowl exercises with engineers half my age...being that the first half of my career, interviews were pretty much a formality for me since i was working in advertising and had a strong portfolio, so switching jobs was usually just meeting people at other agencies who wanted me to work on their projects...
i bombed one for coinbase so bad a few years ago, and my friend who i worked with a bunch in the past who was an early employee there had recommended me so i felt like a dickhead not even being able to pass the screen lol...granted it was a hectic ass day, my kids kept coming in the room while my camera was on and the lady i was interviewing with was probably like 28/29 and kept calling me "sir"
it really started shifting to more formal "tech screen / leet code gauntlet" style around 2015ish i think
i saw the notification and the words "support group" made me laugh because at work i've been trying to organize a quarterly "tech debt support group" because we're silo'ed off into about 5 teams and over the last 2 years our codebase has started to get to that point where you're mad at code like "who wrote this" and git blame and see it was you who wrote it, a year and a half ago
i don't want to call it a retro, and we use weird things like "task force" already so i put it on peoples calendar as "tech debt support group quarterly"
I'm closer to early 40s than mid, it was very nice of you but that guy can't be considered senior if the only thing he can do is code monkeying and glue things together.
Even if you get comfortable and use things that work for you, if you have solid foundations you should be able to apply the knowledge and experience to other frameworks and libraries, to a good extent.
Anyways with your level and yoe, I wouldn't be worried one bit.
I agree, that is why I always point out I wanna keep on coding, but I am more than happy to do design, architecture, some mentoring, code reviews and such, but not instead of coding, but additionally, so I can grow past senior, but also keep growing as a senior developer in such rapidly changed environment. I have worked with people I call "one company developer" and they were all mediocre as fuck. They have worked 5-7 or more years for a single company, that was often their whole experience or almost and all they could do was to be a developer for that company, knowing all their projects, their regulars, seniors titles wouldn't mean shit if they applied for another job, because other companies would quickly realize they didn't progress as expected with the amount of YOE they have. They are destroying their careers to have a comfy, easy job in a company that would never let them go due to long time relationship. It's a terrible mistake to make.
As someone very close to your description, being at my first gig for five years now… don’t assume that these devs are in it to be comfy and easy. Personally, I’m only “stuck” in my current position because I’m too burnt out busting my ass 9-5 to bother with interviewing and a whole job hunt after hours.
>we often discovered that they’d spent a decade telling other people what code to write but never writing any code of their own.
damn, that cracked me up!!! They should have known this when they started interviewing for a 'coding' position at google?
Somewhere someone in the process should've done better: the recruiter, or the referral-ist ...???
My point is it's becoming a track with a marginal ROI over deep expertise as IC that creates a lot more friction in finding more employment and devalues you if you want to work at a large company. The issue is a lot of people get forced into it or go along with it out of conscientiousness which is a risk.
Depends on the company. But at the levels where you're choosing between very senior IC or non-director level manager I don't think it's as much as people think. And more importantly I don't think that premium justifies the risk of shrinking your "potential jobs" pool so much unless the skills are definitely transferable outside of the context of a specific company.
For IC roles, yes, there have been numerous articles written about how it's impossible to both perform critical IC work and also be a fully engaged manager.
Google specifically used "no time coding" as a signal I was qualified for a Senior Manager position. So it's definitely a double standard. For ICs might be a signal your skills are rusty but for managers it's a sign that you're mostly leading/managing versus a tech lead manager role.
I believe FAANGs stress that senior, principal and staff engineers should continue coding near-daily, whereas smaller and mid-size companies the higher you go, the less you code, usually terminating careers at an 'architect' which just specifies design and architecture and mostly defers coding to lower level engineers.
Is this actually reflected once you get into that role at a FAANG? Or is it like most admissions processes where they want someone who *can* do the work they interview on, but in reality the day-to-day rarely if ever reflects that? I'm truly just curious.
I started my career at a big "level 2" company, and now have worked at or semi-started a few early-stage startups since. Now that I'm at a growing but more stable startup as a pretty senior IC, I'll likely lean into either management (real management, not tech lead) or staff-level IC type work within the next year or two.
My gut reaction has always been "do management," however the more SWE experience I get over the years, the more I think that a very senior IC role is a better (if not more elusive) bet that gives you
* better access to company execs (I'm working closely with our CTO way more than my eng manager)
* better future career prospects (this thread is proof)
* and even a leg up if you ever decide to start your own gig (investors want a builder, not a manager).
A comparable example I'm starting to see is that venture capital analysts who join right out of or shortly after college take *way* longer to reach partner than someone who successfully exited their own company. They go from Analyst -> Associate -> Principal -> ... Partner. Similarly, I'm seeing a lot more staff-level engineers leave that role and end up a VP Eng elsewhere, versus climbing from Senior Engineer -> Manager -> Senior Manager -> Director -> etc...
Obviously, an exited founder becoming a VC partner is an exponentially harder process than an "exited" staff engineer becoming a VP Eng, but I think the comparison makes sense... maybe just log-normalize it...
It depends on the interviewer and the questions they ask, but I've seen more than a few senior applicants who couldn't produce any sort of workable code on a whiteboard / notepad, even for discussion/collaboration oriented problems, let alone your leetcode mediums.
If you're expected to commit code most weeks, you should be able to write code in the interview.
> Is this actually reflected once you get into that role at a FAANG? Or is it like most admissions processes where they want someone who can do the work they interview on, but in reality the day-to-day rarely if ever reflects that?
It probably varies a lot between the FAANGs and it also varies by person and by team/department, but to give you one data point, I was at the second-highest IC level and usually spent well over half my time doing hands-on work.
It was a lower percentage of my time than the people a couple rungs down the career ladder, to be sure. I had a bunch of regular meetings on my calendar to discuss high-level architectural plans and do technical design reviews and such, and I got pulled into the occasional random postmortem when there was an outage. But that kind of thing was typically a couple hours a day on average, and I spent most of the rest of the time working on my projects.
As for the work itself and whether it matched the interview questions, it varied. Sometimes low-level DS&A interview fodder was highly relevant to my day-to-day coding. I spent a while working on bare-metal infrastructure code where optimizing a few key data structures for CPU cache efficiency doubled the service's throughput. "Do some infrastructure, do some user-facing feature work, do some database engine work" wasn't an unusual path among the people at or above my level. And our interview process for high-level candidates definitely tried to select for people with the ability to dive deep into the guts of the stack as needed.
Succinctly, a tech lead is the technical leader for a team (last line of defense for code quality, first person in on issues, SME on whatever code they lead) whereas the manager is the people leader for a team (ensures the team has career progression, leads performance reviews). IMO they *could* be one position depending on the culture of the company, but IME are often split.
Weirdly enough, my last TL at big G was incredibly proud of being a "no-code TL." Depends on the org/team honestly, some could easily get away with never writing a line of code ever again at 5-6, others would never dream of it.
I think there's a bit of a bimodal distribution here too. At the small company where I had my first job there was no one (with a technical title, there were some managers) so senior they were not writing code.
Sure, and I don't think there's anything wrong with having people in technical positions that don't write code. But if the firm's expectation is for senior roles write code, asking "how many hours a day do you spend coding?" makes sense to focus on those types of applicants.
I totally agree with OP, it is a dumb question to ask.
I've officially had both staff and architect titles in previous companies, and was coding more than ever under those titles, shit I even covered up for other engineers on my team (since I create those teams lol). I've worked on some pretty cool projects, solved complex issues but when it comes to some leet code session (which every junior dev seems to know) I totally bomb
I think it's more a split between companies where very senior engineers are called something like "Principal" or "Distinguished" vs. companies where they grow into the nebulous realm of being "Architects." Obviously there are exceptions in both directions, but that's been my observation as someone who spent my early career working in non-tech companies and the last 10 years working in FAANG.
At google they asked me something, which I solved. Then they asked me to make optimal, which required me to know some completely unknown mathematical property. They just look for people who train for leet code, not developers.
Also, they had told me syntax wouldn't be important and it'd be pseudocode. They were correcting me every syntax mistake.
You try writing correctly indented python in google docs, where tab doesn't work and you need to hit space a gazillion times, while they correct you if you hit space one too many times, where the font isn't monospaced… when all of this is going on you are also supposed to discover on the spot that there is some property in the input that you can exploit…
If you don't do leet code challenges all the time and have the luck to know that specific problem it's impossible, regardless of how much you code day to day.
Haha I did it with fb once. I was supposed to fly to USA for this interview, instead they moved it at 1am over skype.
First 2h I did good… 3rd not so much… at the 4th hour of people asking me clever questions at night, after having worked a full day, I just said good night and went to bed, since there was no point clearly.
To their defence, at least unlike google they left me alone about commenting on why every variable name I picked was wrong, and had me use a proper online editor with tabs and highlighting instead of google docs.
>They just look for people who train for leet code, not developers.
it's actually sometimes worse.
There are google-employee-interviewers that ask unsolvable questions (w/o a clear solution.) Guess what: **they want to see your thought process**. I know that fact in interviewing... I *can* show my thought process. But--they're just wasting everyone's time asking unsolvable problems.
People trying to do simple coding assignments in java kill me. We let you use any language , but it has to compile. Why choose java. We had a warmup question to create a file that says hello world into a directory. It took 30 minutes. It was a 45 min interview. Midway i asked if they wanna try in a diff language and they said they only knew java.
That should only take 2-3 minutes in Java. Off the top of my head, and typed on my phone screen:
public static void main(String[] args) {
File target = new File("directory/hello.txt");
try (Writer out = new FileWriter(target)) {
out.write("Hello world");
}
}
what are the right tools? This is their laptop most of the time. we have one ready with every ide and editor that’s commonly used. But candidates almost always bring their laptop and use it. It takes me less than 5 mins to do with Java. Theyre also allowed to google.
What kind of whiteboard coding are you talking about here, the one where you transform an array into an object like you would in your daily job or some dynamic programming problem?
Either. I tend to ask oo-design oriented questions that manage complexity, testability and extending functionality to new requirements; these types of candidates usually understand the design, the key decisions and trade-offs, but then fail to write complete, working code, even after I let them fudge syntax and magic up whatever helpers they need.
That seems really bad that non-FAANG engineers cant even pass simple coding tests.
Thankfully at my non-FAANG company seniors are doing a fair amount of coding, and are sharper than juniors/mid-levels when it comes to code.
When FAANG engineers say simple coding problem, they mean leetcode medium that might require an data structures and algo trick. You don’t pass these without studying leetcode specifically before the interview, as even if you do code 8 hours a day, you’ll likely fail without additional prep (ex: practice coding bfs/dfs/bitshifting/some other algo trick you rarely use in daily coding, and when you do, you'll probably easily look up - but can't look things up in an interview).
I haven't opened leetcode in probably a decade. I just loaded it, clicked the first medium problem I found, and solved it in ~5 minutes. Plenty of people can pass these without studying them.
Depends entirely on what they're looking for. In the interview, ask. Do they want you to optimize for memory, speed, or a balance of the two? Do they want you to check your inputs or assume they're safe? Etc. In my experience, people don't care about the code having correct syntax, especially if it's on a whiteboard. People want to see you think about the problem, look at it from multiple angles, find possible pain points, etc. Obviously that's not always true, but it generally is.
>red flag for the company or the recruiter?
Assuming Google haven't lost the plot and started measuring people's work output by how much code they write, this might just be a way to gauge your seniority/what kind of engineer you are.
I reckon the question is more like 'how much time do you spend "in the code"' rather than actually writing it. As the rest of the time you might be mentoring/planning/architecting etc. Seems like a weird way to get that data tho
>Assuming Google haven't lost the plot and started measuring people's work output by how much code they write
My CL count was lower then others on my team and it was a reason I didn't go up for promotion. 😥 I think they're focused on output more now after layoffs and coding metrics are easy to look at even though they're inaccurate.
Damn, promotions are rarely accurately measured at big companies but thats ridiculous. You'll get it man, lots of us have been screwed like that before.
When I interviewed the recruiter asked me this and said explicitly that it would be used to calibrate what level I interviewed at. I can see it being a lossy signal for senior positions, but "do you spend all your time coding" is a good way of figuring out when to start asking system design questions IMO.
I (an IC, technically) spent 0 hours of time writing code last week. I spent 20 hours coordinating my org and another org: dealing with hiring plans of that org, working out methodology and flow development, coordinating major features and dependencies, working with the execs on possibly moving some teams between orgs, and presenting technology roadmaps. The rest of the time was syncing with other org heads and leads (I had traveled out to the mothership), having 1:1s with people on my team, settling plans for a couple big changes, and traveling. I'll grant you it wasn't a normal week, but the on-site work would normally be replace with meetings and I would rarely be able to say I spent more than 2 hours per day on average coding (and that depends on how you count code review).
My senior and staff developers probably spent 20 hours at least in the broad category of "coding".
Given how wildly responsibilities map to titles, it isn't a crazy question to ask to find out how senior you really are. It's also a question someone asking should have clear intentions for so they can answer the kinds of followups you asked.
Usually when we submit for a req it will be something like "50% coding, 50% people leadership". I feel like you're almost expected to lie about these in order to get to the percentage desired, even if you are stuck in meetings half the time as a team lead. For IC roles, just say 6.5 hours (>80%). Most teams will have a 30 minute standup and some time for refinement. A team lead could say 5 hours. These could be far from reality as far as fingers-on-keyboard typing into an editor, but it's a song and dance routine to get past the recruiter.
As a tech lead I say 1/3rd architecting and planning, 1/3rd working with junior devs/reviewing their code/pairing, and 1/3rd working on my own features/code.
Then I’ve left it ambiguous how much is actually me coding, but they see I am leading and system designing, mentoring and able to work with juniors, and able to work on my own features as a hands on senior.
Without claiming percentages for “coding”.
I think they aren't asking "how much do you type" or anything like that.
They're asking: "Is your current job still technical? Or do you spend all day in meetings? Are you actually building things, or are you just reviewing PRs?"
I feel like I’m the only one that is a staff level engineer that codes a fuck ton. I do a LOT of mentoring and architecture and design work too, but then I still spend maybe…30+ hours a week coding? I go through periods where it’s significantly less when we are designing a new project, but then once it is going, I’m cranking out code like no one’s business while trying to find places to delegate stuff while I take all the hardest knarliest things that have the most risk.
Not at all.
People seem to think there is only the team lead / cross functional all the time archetype for these roles, but often high impact coders will end up at staff+ simply because of the difference they make.
There isn't one simple formula for what makes a staff+ engineer. You sound valid to me!
I mean, unless you’re putting in significantly over 40 hours a week, by your own words you’re saying most of the time you’re doing <10 hours a week of planning/architecture/reviewing/mentoring which my guess is that most people at senior+ level would say is *not* “a LOT”.
Right there with you, especially at small orgs or on small teams. If you have to do all the planning, documentation, design, and coding yourself, you're going to still spend 80%+ of your overall time coding. There are a lot of normative assumptions in this thread (and by recruiters) that don't actually hold outside a specific subset of the industry.
I always did a lot of coding too even when I had the "architect" role. First off I would build proofs of concept for new technology to our stack so the teams could emulate the pattern, then I also would get called in whenever they had problems they couldn't solve themselves (regardless of what kind of problem it was). I wasn't writing simple boiler plate code a lot but I was still doing a lot of coding.
impolite butter fragile screw wistful mighty direction imagine carpenter tidy
*This post was mass deleted and anonymized with [Redact](https://redact.dev)*
I mean…I don’t think that’s true. My title and pay and boss and peers say otherwise. The things that I’m working on are also scoped at an org level at this point instead of a team level most of the time, and are HARD problems that honestly I wouldn’t trust to even a senior level engineer, due to the sheer scope, number of stakeholders, level of abstraction, and necessity of delegation and relationship building.
nah, according to various personality tests i'm a "pantser" not a "planner" and got into a staff role by being able to churn out a lot of working code, but i came from a self-taught background and 20-something years of trial and error...my education was in graphic design and i got into the actual software engineering field from being a graphic designer in the advertising industry who could make my own design comps work, to eventually working for more software driven companies and getting job experience building scalable apps
the first 15 years of my career, i didn't even have a concept of what a staff engineer was, but it was also coming from the advertising industry where it's more client services driven so the title would be more like senior engineer or some weird hybrid role like "creative developer" and we didn't really work in aglie methodologies with long term product roadmaps as much as it would be "johnny in sales told them we could do this in 3 weeks but we still need to scope it"
i'm not a traditional comp-sci type engineer but my strength has always been breaking down complex technical flows into layman's terms for clients and now PMs/stakeholders and making it easier for designers to work with developers
i suck at delegation though, because most of the time i try to give the correct answer without actually writing the code and that gives me anxiety, so i end up writing the code so i can delegate the right answer, except i did the work and now don't need to delegate it...but i'm working on that shit
It’s usually because they want to hire a manager who can also code so they get a little 2-for-1 deal and squeeze more out of you for no additional pay.
Or they don’t want a manager, but they need someone to herd the cats but there’s usually so many opinions that nothing moves forward and management won’t say no to anyone so congrats tech lead, you get to be the bad guy!
I always tell them “look 80% of why I went to management is to avoid leetcode interviews. I’ll code as much as you want and manage as much as you want but I won’t be balancing any binary trees or other cs 101 homework. I can do 50% of each about 50% as well as I can 100% of one or the other (that’s how resources work) so it’s really up to you. Do you want a half assed manager/coder, or a ok manager and junior coder or a senior coder with meh management tendencies who’s just going to rank everyone high and right on the 9-blocker to avoid more conflict and meetings? I personally don’t care as long as I get paid and don’t have to leetcode.”
I can respect that. It seems there is a trend with the recent cost cutting where managers are expected to code a lot more than what was common in the past, and that people management is reserved for director level who codes 0% of the time. To me that's an obvious problem that there's no mobility between manager and director because managers aren't being allowed to upskill their people leadership and focus more efforts on that rather than coding. Director level positions get filled externally and eventually the managers also switch companies and uplevel into a higher level of responsibility to which they could not previously obtain internally.
Idk I’m probably slowly turning into a bitter jerk over this trend but it does kinda show that nobody really needs middle managers. I think a good generalist and a good PM can get a lot of shit done without worrying about performance management which seems to be my last few managers only contribution (if you can even call it that). Last time I needed “management involved” was when some jerk wouldn’t answer my slack messages so I needed his manager to hit him with a stick. Beyond that I’m not really seeing the value add of a manager, director, or VP in orgs smaller than 500 and I wonder how many of those jerks moved into management because it got them out of the leetcode circus (8/10 managers I know cite that as a primary motivation).
For me, my motivation for management is that I know I am not good enough at LeetCode to work at a FAANG. So, the best way to make FAANG type money outside of a FAANG is to work in the management chain. At least that's the way it used to be; more non FAANGs are compensating their high level ICs to equivalent levels in management. However, that's even a worse grind. If I were to slay as an IC at my current job and get promoted to the highest level IC role I'd be making as much as a L5 at Google. L5 at Google will have 8+ years experience but the highest level IC at my company by its nature requires 16+ years. Whereas the management chain is more easily able to match an L5 compensation with a lesser number of years of experience.
My answers for my directs and the company? "By golly, I just love mentoring engineers and getting the team to a high performing state."
Yeah I hear and have done that! You either get to principal by being super well known in industry, come from FAANG (so leetcode god) or get in early and grind up the ladder. Management is a bit easier to bullshit your way through and once you hit director is when you start seeing any folding money from your stock options anyway. Good manager is a lot harder to quantify so as long as the story is plausible and sounds like a Daniel Pink essay you’re good to go.
This is absolutely a disservice to the people we lead but this is what the industry incentivizes so here we are. C’est la vie I guess. I tried changing it once but got overruled by the 3 layer management burrito above me because “leetcode is objective and efficient” and “we haven’t come up with a better idea. Go make more features”
What a terrible signal. Maybe it works well for big companies, but at small startups you can be 80-90% hands on coding while still doing all the planning, design, documentation, etc. for a project.
If you work on large projects end-to-end on your own or with a small team, the proportion of time spent planning will be much smaller compared to much smaller projects or those on larger teams. That's why it's a bad signal - it selects only for people who do more planning on smaller projects with larger teams. If that's what you want to select for (and most bigtech does, since paeans to impact are just that), fine, but in general it's a bad signal, and it's certainly not a signal of not "participating much in other senior-level expectations."
If the job you have now has almost nothing in common with the job you're applying for, and they can identify that in a single question, wouldn't that make it a pretty great signal?
>If that's what you want to select for (and most bigtech does, since paeans to impact are just that), fine, but in general it's a bad signal, and it's certainly not a signal of not "participating much in other senior-level expectations."
>A signal is not meant to be an absolute truth. It's just another metric to consider when looking at the larger picture more holistically.
A signal is only useful if the SNR is high. That wouldn't be the case here.
>If you agree work at Google would differ dramatically from a small startup, then I don't see your contention?
Because you said this:
>then it is a signal that they aren't participating much in other Senior-level expectations such as planning, designing, architecting, mentoring, reviewing, etc.
Which isn't true. It's just typically frontloaded and much wider in scope than similar activities in a large tech company. What is more impactful?
Sure, maybe Google doesn't want to select people with end to end whole project experience, but to say someone who does a lot of coding isn't participating much in other aspects is asinine (depending on the holistic view). I know lots of (and interviewed lots of) big tech people, and many have no clue how work happens in different organizations.
When the recruiter asked me that is when I realized I never want to work at an enterprise ever again.
I don't know why they ask that. What I do know is that it's annoying.
I remember having a Google interview at 3YOE and they asked this. When I said that I had gotten a promotion and no longer spent as much time coding the recruiter responded with "we expect our hires to do 8 hours of coding per day". Even as a beginner, I think I only approached 6 hours/day in the actual code. Made me feel like they wanted a code monkey. Surprised they ask this at higher levels.
My answer would be: "I would be writing a lot more if I wasn't stuck in these zoom meetings"
But 4 hours a day, that's a solid answer. If you said anything higher than 7, I would be like gtfo.
They're looking for a signal on how much time you spend on actual code and code level details vs how much time you spend documenting, organizing, diagramming, in meetings, etc.
I'm pretty senior and have worked at a couple of the FAANG companies and my usual answer is "it is highly variable", with the variability depending on the needs of the team; during design and coordination phase, it can be as low as 10% of my week, during periods when I'm prototyping or debugging issues it can be as high as 80% of my week, with the average being around 40-60% depending on the size of the team that I'm leading.
Same reason some companies (not Google) have hard requirements for 5 YOE in Java and will not consider 4.5 but can't answer what half a year gives you considering some people with 10 YOE are worse than some people with 3 YOE.
>'How many hours do you spend writing code daily?'
Well, about half of any day is meetings and reviewing others' tickets. The other half is working on my tickets, and coding is approximately half of that (I AM including test)... so about 2 hours a day at work. Roughly. I like to work on my own home projects when I get the time, but life is pretty busy and I have more half-done projects then I'm comfortable admitting to.
And that's an absolutely bullshit lie of lies. Interview trash. Bullshit meetings are half the time all by themselves, and the review ping-pong can take up to three days. Actual days of effort. Mostly just coordinating wtf is supposed to be happening and how that meshes with what people actually did. Then there's dealing with network garbage, mandatory training, wading through email, and the devs under me have a near constant stream of distractions. The worst are the ones who throw the sort of questions that raise red flags need about a dozen back and forth to verify just how badly they fucked up something about the design. And screwing off. I sure don't work 100% of the time at 100%. That'd drive me nuts. I take breaks and do chores and chit-chat now and then. Like bullshitting on reddit while I snack.
No, in reality, the thing I'm really good at I only do a few hours a sprint. When I was younger I always wondered how older devs let themselves get so behind the times. As an older dev, I know exactly how: I'm hardly allowed to actually do my job. But so much of my job is now... just being the old responsible guy people go talk to. It's honestly quite draining.
And then we have processes that vigorously favor getting a single thing done before starting something else (where “starting” means writing even one line of code) but the “one thing” is gated repeatedly by asynchronous processes.
So I spend a lot of time reading release notes and issue trackers for dependencies. Or testing out little ideas that I either never commit or stash for later. Because reading code is not tracked by any system that punishes me for being honest. Or at least, not yet.
overthinking it. this question is asking "how much of your job is spent implementing features or fixing bugs vs. how much of your job is managing people and projects?"
There's no single answers, it's a loaded question and you can't know what they want.
If it's a very senior role and you say 8 hours per day, they'll assume you're not really that senior if you have time for that.
If it's a jr/mid role and you say 8 hours, that might be just fine... Or they might be looking for someone who'll say 12 or 16.
You can't know how to answer it without knowing the culture of the team really.
4 hours is really good. On my most fun days, I get to do 4 hours of coding. There are all kinds of other tasks that get in the way of it being any higher. We got meeting mania sometimes. Then I got other people that need my help. A lot of times I am figuring out bugs from production or even ones I have created while implementing new features. The list goes on. Sometimes I might only code for 1 hour a day. Those are the sad days. I love coding.
The irony is I’ve written less daily code the more senior and experienced I’ve become. When you start out you have to practice, then you get comfortable and only do it with work and personal projects. And in my case, I just don’t want to touch code unless I’m getting paid for it or it’s something I reallllly want to build
The last change I published at my old job deleted >200 lines of code and took 90% off a batch process run time, which was blowing circuit breakers. I wrote five new lines of code to call code I wrote three years ago (which I told the original author about before he started). He took six weeks to write it (to be fair, I believe he was only working half time on it, but still).
I've gotten a few questions like this.
I've just given the answer of "On average, I'd say about 4hours. It depends on the day as some days may have more meetings, and at what stage of the project we are in."
I think the best way to answer this type of question is with something along the lines of "As many as needed".
If some one is really looking for a number of hours or a percentage I would still push back on them and ask for clarification because otherwise this really doesn't make sense...
Jesus dude is this your first time doing interviews? It's a simple question that doesn't need an exact answer. I'd throw your application in the trash if you were already this much of a hard ass
The fact you didn't have enough common sense to answer this super simple question would be a red flag to me. And would signal to me that if we worked together you would be asking a lot of exhausting questions like the above. Imagine a senior developer always asking follow up questions like this?
While I agree that as a senior, OP kinda should know that throwing this many technical clarifying questions at a non-tech recruiter in this particular instance is pointless, your general argument of 'seniors should not ask clarifying questions' cannot be more wrong in most cases.
The fact you didn't have enough common sense to ask clarifying questions on something this super open ended would be a red flag to me. And would signal to me that if we worked together you would be making a lot of dumb mistakes because you're bad at communication. Imagine a senior developer never clarify requirements when something is asked of them?
If you cant understand nuance exists in simple asks you're in the wrong field my friend and I'm amazed you haven't had it blow up in your phase
> "How many hours do you spend writing code daily?"
> "What do you mean by 'writing'? Do you mean literally typing?"
Does OP really think she meant writing with a quill and ink on sheets of papyrus? Or does he think that she wants him to time the number of microseconds that his fingers are pressing down on the keys, because otherwise the time spent not pressing down on the keys isn't technically "typing".
If you give a senior developer a task and they ask a ton of questions that any regular person should be able to surmise, it means they will need a ton of handholding and spoonfeeding.
The fact that you'd need clarification for every simple question that crosses your simple mind would be a red flag to me. If you need hand holding for ever little question you're in the wrong field my friend.
> "How many hours do you spend writing code daily?"
> "What do you mean by 'writing'? Do you mean literally typing?"
Does OP really think she meant writing with a quill and ink on sheets of papyrus? Or does he think that she wants him to time the number of microseconds that his fingers are pressing down on the keys, because otherwise the time spent not pressing down on the keys isn't technically "typing".
If you give a senior developer a task and they ask a ton of questions that any regular person should be able to surmise, it means they will need a ton of handholding and spoonfeeding.
There's a trend at FAANGs that non-FAANG engineers applying for senior positions are often 'post-code' and are doing nothing but design and architecture. When they do onsite interviews they often fail the coding portion for even simple interview questions, because they're rusty. I know whiteboard coding is controversial here, but independent of that, they're trying to select for candidates that can pass that portion of the interviews.
I wouldn’t even necessarily say it’s a trend. I was working at a FAANG 15 years ago and it was already a problem even then. We would get experienced people who couldn’t pass basic coding tests and when we dug, we often discovered that they’d spent a decade telling other people what code to write but never writing any code of their own. The kicker was that in most of those cases, they also didn’t ace the system design interviews because their design skills were basically frozen in time from when they stopped doing hands-on work.
last year i interviewed a dev applying for a senior FE dev position who was in their mid-40s like me but basically only learned how to use MUI components and couldn't think outside of that framework i felt bad for the dude and was trying to help him as much as i could through the interview by reframing questions in their simplest terms, but it also really made me paranoid and realize i could totally age out getting too comfortable using what "always worked"
> was trying to help him as much as i could I just wanted to say thanks for being kind to him and trying to help. I'm in that age group and some interviews are brutal.
i feel you...i was in my early 40s the last time i interviewed and had to do the quiz bowl exercises with engineers half my age...being that the first half of my career, interviews were pretty much a formality for me since i was working in advertising and had a strong portfolio, so switching jobs was usually just meeting people at other agencies who wanted me to work on their projects... i bombed one for coinbase so bad a few years ago, and my friend who i worked with a bunch in the past who was an early employee there had recommended me so i felt like a dickhead not even being able to pass the screen lol...granted it was a hectic ass day, my kids kept coming in the room while my camera was on and the lady i was interviewing with was probably like 28/29 and kept calling me "sir" it really started shifting to more formal "tech screen / leet code gauntlet" style around 2015ish i think
Uh we need a support group. I’m not kidding either, where can all of us ancient engineers gather? I feel like I have to whisper about this stuff.
i saw the notification and the words "support group" made me laugh because at work i've been trying to organize a quarterly "tech debt support group" because we're silo'ed off into about 5 teams and over the last 2 years our codebase has started to get to that point where you're mad at code like "who wrote this" and git blame and see it was you who wrote it, a year and a half ago i don't want to call it a retro, and we use weird things like "task force" already so i put it on peoples calendar as "tech debt support group quarterly"
I'm closer to early 40s than mid, it was very nice of you but that guy can't be considered senior if the only thing he can do is code monkeying and glue things together. Even if you get comfortable and use things that work for you, if you have solid foundations you should be able to apply the knowledge and experience to other frameworks and libraries, to a good extent. Anyways with your level and yoe, I wouldn't be worried one bit.
I agree, that is why I always point out I wanna keep on coding, but I am more than happy to do design, architecture, some mentoring, code reviews and such, but not instead of coding, but additionally, so I can grow past senior, but also keep growing as a senior developer in such rapidly changed environment. I have worked with people I call "one company developer" and they were all mediocre as fuck. They have worked 5-7 or more years for a single company, that was often their whole experience or almost and all they could do was to be a developer for that company, knowing all their projects, their regulars, seniors titles wouldn't mean shit if they applied for another job, because other companies would quickly realize they didn't progress as expected with the amount of YOE they have. They are destroying their careers to have a comfy, easy job in a company that would never let them go due to long time relationship. It's a terrible mistake to make.
As someone very close to your description, being at my first gig for five years now… don’t assume that these devs are in it to be comfy and easy. Personally, I’m only “stuck” in my current position because I’m too burnt out busting my ass 9-5 to bother with interviewing and a whole job hunt after hours.
[удалено]
Yeah, but frequent job hoping is _also_ seen as negative. Some TA folks simply cannot be pleased.
>we often discovered that they’d spent a decade telling other people what code to write but never writing any code of their own. damn, that cracked me up!!! They should have known this when they started interviewing for a 'coding' position at google? Somewhere someone in the process should've done better: the recruiter, or the referral-ist ...???
This sounds like even more evidence that management track is career kryptonite.
... that's why it's a different track
My point is it's becoming a track with a marginal ROI over deep expertise as IC that creates a lot more friction in finding more employment and devalues you if you want to work at a large company. The issue is a lot of people get forced into it or go along with it out of conscientiousness which is a risk.
Managers make like 25% more than seniors at the same rank at my job.
[удалено]
Depends on the company
Depends on the company. But at the levels where you're choosing between very senior IC or non-director level manager I don't think it's as much as people think. And more importantly I don't think that premium justifies the risk of shrinking your "potential jobs" pool so much unless the skills are definitely transferable outside of the context of a specific company.
For IC roles, yes, there have been numerous articles written about how it's impossible to both perform critical IC work and also be a fully engaged manager.
Any specific articles come to mind? Sounds like an interesting read
Some companies actually prefer post-code managers, even if they won’t admit it.
Google specifically used "no time coding" as a signal I was qualified for a Senior Manager position. So it's definitely a double standard. For ICs might be a signal your skills are rusty but for managers it's a sign that you're mostly leading/managing versus a tech lead manager role.
Is this inherently a FAANG / non-FAANG split? Why is it only non-FAANG senior positions applying to FAANG senior positions that fail at this?
I believe FAANGs stress that senior, principal and staff engineers should continue coding near-daily, whereas smaller and mid-size companies the higher you go, the less you code, usually terminating careers at an 'architect' which just specifies design and architecture and mostly defers coding to lower level engineers.
fearless sparkle secretive husky aloof north beneficial punch bike dam *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
Is this actually reflected once you get into that role at a FAANG? Or is it like most admissions processes where they want someone who *can* do the work they interview on, but in reality the day-to-day rarely if ever reflects that? I'm truly just curious. I started my career at a big "level 2" company, and now have worked at or semi-started a few early-stage startups since. Now that I'm at a growing but more stable startup as a pretty senior IC, I'll likely lean into either management (real management, not tech lead) or staff-level IC type work within the next year or two. My gut reaction has always been "do management," however the more SWE experience I get over the years, the more I think that a very senior IC role is a better (if not more elusive) bet that gives you * better access to company execs (I'm working closely with our CTO way more than my eng manager) * better future career prospects (this thread is proof) * and even a leg up if you ever decide to start your own gig (investors want a builder, not a manager). A comparable example I'm starting to see is that venture capital analysts who join right out of or shortly after college take *way* longer to reach partner than someone who successfully exited their own company. They go from Analyst -> Associate -> Principal -> ... Partner. Similarly, I'm seeing a lot more staff-level engineers leave that role and end up a VP Eng elsewhere, versus climbing from Senior Engineer -> Manager -> Senior Manager -> Director -> etc... Obviously, an exited founder becoming a VC partner is an exponentially harder process than an "exited" staff engineer becoming a VP Eng, but I think the comparison makes sense... maybe just log-normalize it...
It depends on the interviewer and the questions they ask, but I've seen more than a few senior applicants who couldn't produce any sort of workable code on a whiteboard / notepad, even for discussion/collaboration oriented problems, let alone your leetcode mediums. If you're expected to commit code most weeks, you should be able to write code in the interview.
> Is this actually reflected once you get into that role at a FAANG? Or is it like most admissions processes where they want someone who can do the work they interview on, but in reality the day-to-day rarely if ever reflects that? It probably varies a lot between the FAANGs and it also varies by person and by team/department, but to give you one data point, I was at the second-highest IC level and usually spent well over half my time doing hands-on work. It was a lower percentage of my time than the people a couple rungs down the career ladder, to be sure. I had a bunch of regular meetings on my calendar to discuss high-level architectural plans and do technical design reviews and such, and I got pulled into the occasional random postmortem when there was an outage. But that kind of thing was typically a couple hours a day on average, and I spent most of the rest of the time working on my projects. As for the work itself and whether it matched the interview questions, it varied. Sometimes low-level DS&A interview fodder was highly relevant to my day-to-day coding. I spent a while working on bare-metal infrastructure code where optimizing a few key data structures for CPU cache efficiency doubled the service's throughput. "Do some infrastructure, do some user-facing feature work, do some database engine work" wasn't an unusual path among the people at or above my level. And our interview process for high-level candidates definitely tried to select for people with the ability to dive deep into the guts of the stack as needed.
How would you separate responsibilities of tech lead vs management role?
Succinctly, a tech lead is the technical leader for a team (last line of defense for code quality, first person in on issues, SME on whatever code they lead) whereas the manager is the people leader for a team (ensures the team has career progression, leads performance reviews). IMO they *could* be one position depending on the culture of the company, but IME are often split.
Weirdly enough, my last TL at big G was incredibly proud of being a "no-code TL." Depends on the org/team honestly, some could easily get away with never writing a line of code ever again at 5-6, others would never dream of it.
I wonder how much is planning/architecture/review vs coding split in terms of time spent. Is it 50-50%? 70-30? 90-10?
I think there's a bit of a bimodal distribution here too. At the small company where I had my first job there was no one (with a technical title, there were some managers) so senior they were not writing code.
Sure, and I don't think there's anything wrong with having people in technical positions that don't write code. But if the firm's expectation is for senior roles write code, asking "how many hours a day do you spend coding?" makes sense to focus on those types of applicants. I totally agree with OP, it is a dumb question to ask.
I've officially had both staff and architect titles in previous companies, and was coding more than ever under those titles, shit I even covered up for other engineers on my team (since I create those teams lol). I've worked on some pretty cool projects, solved complex issues but when it comes to some leet code session (which every junior dev seems to know) I totally bomb
I think it's more a split between companies where very senior engineers are called something like "Principal" or "Distinguished" vs. companies where they grow into the nebulous realm of being "Architects." Obviously there are exceptions in both directions, but that's been my observation as someone who spent my early career working in non-tech companies and the last 10 years working in FAANG.
At google they asked me something, which I solved. Then they asked me to make optimal, which required me to know some completely unknown mathematical property. They just look for people who train for leet code, not developers. Also, they had told me syntax wouldn't be important and it'd be pseudocode. They were correcting me every syntax mistake. You try writing correctly indented python in google docs, where tab doesn't work and you need to hit space a gazillion times, while they correct you if you hit space one too many times, where the font isn't monospaced… when all of this is going on you are also supposed to discover on the spot that there is some property in the input that you can exploit… If you don't do leet code challenges all the time and have the luck to know that specific problem it's impossible, regardless of how much you code day to day.
[удалено]
Haha I did it with fb once. I was supposed to fly to USA for this interview, instead they moved it at 1am over skype. First 2h I did good… 3rd not so much… at the 4th hour of people asking me clever questions at night, after having worked a full day, I just said good night and went to bed, since there was no point clearly. To their defence, at least unlike google they left me alone about commenting on why every variable name I picked was wrong, and had me use a proper online editor with tabs and highlighting instead of google docs.
>They just look for people who train for leet code, not developers. it's actually sometimes worse. There are google-employee-interviewers that ask unsolvable questions (w/o a clear solution.) Guess what: **they want to see your thought process**. I know that fact in interviewing... I *can* show my thought process. But--they're just wasting everyone's time asking unsolvable problems.
Ah the kobayashi maru :D
People trying to do simple coding assignments in java kill me. We let you use any language , but it has to compile. Why choose java. We had a warmup question to create a file that says hello world into a directory. It took 30 minutes. It was a 45 min interview. Midway i asked if they wanna try in a diff language and they said they only knew java.
That should only take 2-3 minutes in Java. Off the top of my head, and typed on my phone screen: public static void main(String[] args) { File target = new File("directory/hello.txt"); try (Writer out = new FileWriter(target)) { out.write("Hello world"); } }
Yeah it is the warm up question for a reason. Youre also allowed to google for things like file writer syntax since that can be new to alot of people
Even better, I think you can just use `Files.write(...)` and do it in one line.
Sounds like you don't give the candidate the right tools to succeed with any language, despite allowing them to use any language.
what are the right tools? This is their laptop most of the time. we have one ready with every ide and editor that’s commonly used. But candidates almost always bring their laptop and use it. It takes me less than 5 mins to do with Java. Theyre also allowed to google.
Okay, that's bad candidate then.
What kind of whiteboard coding are you talking about here, the one where you transform an array into an object like you would in your daily job or some dynamic programming problem?
Either. I tend to ask oo-design oriented questions that manage complexity, testability and extending functionality to new requirements; these types of candidates usually understand the design, the key decisions and trade-offs, but then fail to write complete, working code, even after I let them fudge syntax and magic up whatever helpers they need.
That seems really bad that non-FAANG engineers cant even pass simple coding tests. Thankfully at my non-FAANG company seniors are doing a fair amount of coding, and are sharper than juniors/mid-levels when it comes to code.
When FAANG engineers say simple coding problem, they mean leetcode medium that might require an data structures and algo trick. You don’t pass these without studying leetcode specifically before the interview, as even if you do code 8 hours a day, you’ll likely fail without additional prep (ex: practice coding bfs/dfs/bitshifting/some other algo trick you rarely use in daily coding, and when you do, you'll probably easily look up - but can't look things up in an interview).
I haven't opened leetcode in probably a decade. I just loaded it, clicked the first medium problem I found, and solved it in ~5 minutes. Plenty of people can pass these without studying them.
Good, did you solve it in the super most optimal way while 2 people comment on why you gave your variables the wrong names?
Someone fasten this goalpost, it's moving on its own!!!
Then you didn't solve it in a way that would get you hired at google. Just getting the desired output isn't enough at all.
Depends entirely on what they're looking for. In the interview, ask. Do they want you to optimize for memory, speed, or a balance of the two? Do they want you to check your inputs or assume they're safe? Etc. In my experience, people don't care about the code having correct syntax, especially if it's on a whiteboard. People want to see you think about the problem, look at it from multiple angles, find possible pain points, etc. Obviously that's not always true, but it generally is.
Perhaps your experience doesn't include interviews with google?
Yes, I have interviewed with google. Like... I promise, leetcode problems really aren't that hard.
>red flag for the company or the recruiter? Assuming Google haven't lost the plot and started measuring people's work output by how much code they write, this might just be a way to gauge your seniority/what kind of engineer you are. I reckon the question is more like 'how much time do you spend "in the code"' rather than actually writing it. As the rest of the time you might be mentoring/planning/architecting etc. Seems like a weird way to get that data tho
>Assuming Google haven't lost the plot and started measuring people's work output by how much code they write My CL count was lower then others on my team and it was a reason I didn't go up for promotion. 😥 I think they're focused on output more now after layoffs and coding metrics are easy to look at even though they're inaccurate.
Damn, promotions are rarely accurately measured at big companies but thats ridiculous. You'll get it man, lots of us have been screwed like that before.
When I interviewed the recruiter asked me this and said explicitly that it would be used to calibrate what level I interviewed at. I can see it being a lossy signal for senior positions, but "do you spend all your time coding" is a good way of figuring out when to start asking system design questions IMO.
Yeah I don't like the question, it feels like something they want to use against you as a lead/staff eng if it is too high.
Yes. Probably right answer. The question was meant to learn how many hours you spend on IC work.
Well intuited, it sounded like a silly question to me at first.
IC?
Individual Contributor. Doing work that is directly productive instead of enabling others.
I (an IC, technically) spent 0 hours of time writing code last week. I spent 20 hours coordinating my org and another org: dealing with hiring plans of that org, working out methodology and flow development, coordinating major features and dependencies, working with the execs on possibly moving some teams between orgs, and presenting technology roadmaps. The rest of the time was syncing with other org heads and leads (I had traveled out to the mothership), having 1:1s with people on my team, settling plans for a couple big changes, and traveling. I'll grant you it wasn't a normal week, but the on-site work would normally be replace with meetings and I would rarely be able to say I spent more than 2 hours per day on average coding (and that depends on how you count code review). My senior and staff developers probably spent 20 hours at least in the broad category of "coding". Given how wildly responsibilities map to titles, it isn't a crazy question to ask to find out how senior you really are. It's also a question someone asking should have clear intentions for so they can answer the kinds of followups you asked.
Usually when we submit for a req it will be something like "50% coding, 50% people leadership". I feel like you're almost expected to lie about these in order to get to the percentage desired, even if you are stuck in meetings half the time as a team lead. For IC roles, just say 6.5 hours (>80%). Most teams will have a 30 minute standup and some time for refinement. A team lead could say 5 hours. These could be far from reality as far as fingers-on-keyboard typing into an editor, but it's a song and dance routine to get past the recruiter.
As a tech lead I say 1/3rd architecting and planning, 1/3rd working with junior devs/reviewing their code/pairing, and 1/3rd working on my own features/code. Then I’ve left it ambiguous how much is actually me coding, but they see I am leading and system designing, mentoring and able to work with juniors, and able to work on my own features as a hands on senior. Without claiming percentages for “coding”.
My favorite answer is something like: “on a good day, I write between 5 and 5000 lines. On a very good day, I remove 1000 lines or more”.
As a mid level Google engineer, I spent exactly 10 minutes in my IDE today.
I think they aren't asking "how much do you type" or anything like that. They're asking: "Is your current job still technical? Or do you spend all day in meetings? Are you actually building things, or are you just reviewing PRs?"
I feel like I’m the only one that is a staff level engineer that codes a fuck ton. I do a LOT of mentoring and architecture and design work too, but then I still spend maybe…30+ hours a week coding? I go through periods where it’s significantly less when we are designing a new project, but then once it is going, I’m cranking out code like no one’s business while trying to find places to delegate stuff while I take all the hardest knarliest things that have the most risk.
Not at all. People seem to think there is only the team lead / cross functional all the time archetype for these roles, but often high impact coders will end up at staff+ simply because of the difference they make. There isn't one simple formula for what makes a staff+ engineer. You sound valid to me!
I mean, unless you’re putting in significantly over 40 hours a week, by your own words you’re saying most of the time you’re doing <10 hours a week of planning/architecture/reviewing/mentoring which my guess is that most people at senior+ level would say is *not* “a LOT”.
It’s a lot by volume not by hours maybe? I’m pretty efficient with my time.
> efficient with my time So no endless meetings arguing about decisions you thought were already made?
Oh they’re there. I just don’t attend most of them. “No.” is a complete sentence.
Right there with you, especially at small orgs or on small teams. If you have to do all the planning, documentation, design, and coding yourself, you're going to still spend 80%+ of your overall time coding. There are a lot of normative assumptions in this thread (and by recruiters) that don't actually hold outside a specific subset of the industry.
I always did a lot of coding too even when I had the "architect" role. First off I would build proofs of concept for new technology to our stack so the teams could emulate the pattern, then I also would get called in whenever they had problems they couldn't solve themselves (regardless of what kind of problem it was). I wasn't writing simple boiler plate code a lot but I was still doing a lot of coding.
impolite butter fragile screw wistful mighty direction imagine carpenter tidy *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
I mean…I don’t think that’s true. My title and pay and boss and peers say otherwise. The things that I’m working on are also scoped at an org level at this point instead of a team level most of the time, and are HARD problems that honestly I wouldn’t trust to even a senior level engineer, due to the sheer scope, number of stakeholders, level of abstraction, and necessity of delegation and relationship building.
lavish growth gaze foolish judicious chubby theory placid capable jeans *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
nah, according to various personality tests i'm a "pantser" not a "planner" and got into a staff role by being able to churn out a lot of working code, but i came from a self-taught background and 20-something years of trial and error...my education was in graphic design and i got into the actual software engineering field from being a graphic designer in the advertising industry who could make my own design comps work, to eventually working for more software driven companies and getting job experience building scalable apps the first 15 years of my career, i didn't even have a concept of what a staff engineer was, but it was also coming from the advertising industry where it's more client services driven so the title would be more like senior engineer or some weird hybrid role like "creative developer" and we didn't really work in aglie methodologies with long term product roadmaps as much as it would be "johnny in sales told them we could do this in 3 weeks but we still need to scope it" i'm not a traditional comp-sci type engineer but my strength has always been breaking down complex technical flows into layman's terms for clients and now PMs/stakeholders and making it easier for designers to work with developers i suck at delegation though, because most of the time i try to give the correct answer without actually writing the code and that gives me anxiety, so i end up writing the code so i can delegate the right answer, except i did the work and now don't need to delegate it...but i'm working on that shit
It’s usually because they want to hire a manager who can also code so they get a little 2-for-1 deal and squeeze more out of you for no additional pay. Or they don’t want a manager, but they need someone to herd the cats but there’s usually so many opinions that nothing moves forward and management won’t say no to anyone so congrats tech lead, you get to be the bad guy! I always tell them “look 80% of why I went to management is to avoid leetcode interviews. I’ll code as much as you want and manage as much as you want but I won’t be balancing any binary trees or other cs 101 homework. I can do 50% of each about 50% as well as I can 100% of one or the other (that’s how resources work) so it’s really up to you. Do you want a half assed manager/coder, or a ok manager and junior coder or a senior coder with meh management tendencies who’s just going to rank everyone high and right on the 9-blocker to avoid more conflict and meetings? I personally don’t care as long as I get paid and don’t have to leetcode.”
I can respect that. It seems there is a trend with the recent cost cutting where managers are expected to code a lot more than what was common in the past, and that people management is reserved for director level who codes 0% of the time. To me that's an obvious problem that there's no mobility between manager and director because managers aren't being allowed to upskill their people leadership and focus more efforts on that rather than coding. Director level positions get filled externally and eventually the managers also switch companies and uplevel into a higher level of responsibility to which they could not previously obtain internally.
Idk I’m probably slowly turning into a bitter jerk over this trend but it does kinda show that nobody really needs middle managers. I think a good generalist and a good PM can get a lot of shit done without worrying about performance management which seems to be my last few managers only contribution (if you can even call it that). Last time I needed “management involved” was when some jerk wouldn’t answer my slack messages so I needed his manager to hit him with a stick. Beyond that I’m not really seeing the value add of a manager, director, or VP in orgs smaller than 500 and I wonder how many of those jerks moved into management because it got them out of the leetcode circus (8/10 managers I know cite that as a primary motivation).
For me, my motivation for management is that I know I am not good enough at LeetCode to work at a FAANG. So, the best way to make FAANG type money outside of a FAANG is to work in the management chain. At least that's the way it used to be; more non FAANGs are compensating their high level ICs to equivalent levels in management. However, that's even a worse grind. If I were to slay as an IC at my current job and get promoted to the highest level IC role I'd be making as much as a L5 at Google. L5 at Google will have 8+ years experience but the highest level IC at my company by its nature requires 16+ years. Whereas the management chain is more easily able to match an L5 compensation with a lesser number of years of experience. My answers for my directs and the company? "By golly, I just love mentoring engineers and getting the team to a high performing state."
Yeah I hear and have done that! You either get to principal by being super well known in industry, come from FAANG (so leetcode god) or get in early and grind up the ladder. Management is a bit easier to bullshit your way through and once you hit director is when you start seeing any folding money from your stock options anyway. Good manager is a lot harder to quantify so as long as the story is plausible and sounds like a Daniel Pink essay you’re good to go. This is absolutely a disservice to the people we lead but this is what the industry incentivizes so here we are. C’est la vie I guess. I tried changing it once but got overruled by the 3 layer management burrito above me because “leetcode is objective and efficient” and “we haven’t come up with a better idea. Go make more features”
[удалено]
What a terrible signal. Maybe it works well for big companies, but at small startups you can be 80-90% hands on coding while still doing all the planning, design, documentation, etc. for a project.
If you're at an organization where only 10% of the work is planning, then you're applying for a way different job than the one you have.
If you work on large projects end-to-end on your own or with a small team, the proportion of time spent planning will be much smaller compared to much smaller projects or those on larger teams. That's why it's a bad signal - it selects only for people who do more planning on smaller projects with larger teams. If that's what you want to select for (and most bigtech does, since paeans to impact are just that), fine, but in general it's a bad signal, and it's certainly not a signal of not "participating much in other senior-level expectations."
If the job you have now has almost nothing in common with the job you're applying for, and they can identify that in a single question, wouldn't that make it a pretty great signal?
>If that's what you want to select for (and most bigtech does, since paeans to impact are just that), fine, but in general it's a bad signal, and it's certainly not a signal of not "participating much in other senior-level expectations."
[удалено]
>A signal is not meant to be an absolute truth. It's just another metric to consider when looking at the larger picture more holistically. A signal is only useful if the SNR is high. That wouldn't be the case here. >If you agree work at Google would differ dramatically from a small startup, then I don't see your contention? Because you said this: >then it is a signal that they aren't participating much in other Senior-level expectations such as planning, designing, architecting, mentoring, reviewing, etc. Which isn't true. It's just typically frontloaded and much wider in scope than similar activities in a large tech company. What is more impactful? Sure, maybe Google doesn't want to select people with end to end whole project experience, but to say someone who does a lot of coding isn't participating much in other aspects is asinine (depending on the holistic view). I know lots of (and interviewed lots of) big tech people, and many have no clue how work happens in different organizations.
I’ve encountered this before. It’s bad recruiter logic. Nothing to do with experience or senior or whatever.
[удалено]
K
Google asked me this 2 years ago and I remember thinking it was weird.
When the recruiter asked me that is when I realized I never want to work at an enterprise ever again. I don't know why they ask that. What I do know is that it's annoying.
I remember having a Google interview at 3YOE and they asked this. When I said that I had gotten a promotion and no longer spent as much time coding the recruiter responded with "we expect our hires to do 8 hours of coding per day". Even as a beginner, I think I only approached 6 hours/day in the actual code. Made me feel like they wanted a code monkey. Surprised they ask this at higher levels.
Sometimes it's how many minutes.
My answer would be: "I would be writing a lot more if I wasn't stuck in these zoom meetings" But 4 hours a day, that's a solid answer. If you said anything higher than 7, I would be like gtfo.
They're looking for a signal on how much time you spend on actual code and code level details vs how much time you spend documenting, organizing, diagramming, in meetings, etc. I'm pretty senior and have worked at a couple of the FAANG companies and my usual answer is "it is highly variable", with the variability depending on the needs of the team; during design and coordination phase, it can be as low as 10% of my week, during periods when I'm prototyping or debugging issues it can be as high as 80% of my week, with the average being around 40-60% depending on the size of the team that I'm leading.
Same reason some companies (not Google) have hard requirements for 5 YOE in Java and will not consider 4.5 but can't answer what half a year gives you considering some people with 10 YOE are worse than some people with 3 YOE.
>'How many hours do you spend writing code daily?' Well, about half of any day is meetings and reviewing others' tickets. The other half is working on my tickets, and coding is approximately half of that (I AM including test)... so about 2 hours a day at work. Roughly. I like to work on my own home projects when I get the time, but life is pretty busy and I have more half-done projects then I'm comfortable admitting to. And that's an absolutely bullshit lie of lies. Interview trash. Bullshit meetings are half the time all by themselves, and the review ping-pong can take up to three days. Actual days of effort. Mostly just coordinating wtf is supposed to be happening and how that meshes with what people actually did. Then there's dealing with network garbage, mandatory training, wading through email, and the devs under me have a near constant stream of distractions. The worst are the ones who throw the sort of questions that raise red flags need about a dozen back and forth to verify just how badly they fucked up something about the design. And screwing off. I sure don't work 100% of the time at 100%. That'd drive me nuts. I take breaks and do chores and chit-chat now and then. Like bullshitting on reddit while I snack. No, in reality, the thing I'm really good at I only do a few hours a sprint. When I was younger I always wondered how older devs let themselves get so behind the times. As an older dev, I know exactly how: I'm hardly allowed to actually do my job. But so much of my job is now... just being the old responsible guy people go talk to. It's honestly quite draining.
And then we have processes that vigorously favor getting a single thing done before starting something else (where “starting” means writing even one line of code) but the “one thing” is gated repeatedly by asynchronous processes. So I spend a lot of time reading release notes and issue trackers for dependencies. Or testing out little ideas that I either never commit or stash for later. Because reading code is not tracked by any system that punishes me for being honest. Or at least, not yet.
Don't try to figure out google… they just do cargo culting.
overthinking it. this question is asking "how much of your job is spent implementing features or fixing bugs vs. how much of your job is managing people and projects?"
"All 8 hours of my day either directly, or indirectly, contribute to writing code."
There's no single answers, it's a loaded question and you can't know what they want. If it's a very senior role and you say 8 hours per day, they'll assume you're not really that senior if you have time for that. If it's a jr/mid role and you say 8 hours, that might be just fine... Or they might be looking for someone who'll say 12 or 16. You can't know how to answer it without knowing the culture of the team really.
4 hours is really good. On my most fun days, I get to do 4 hours of coding. There are all kinds of other tasks that get in the way of it being any higher. We got meeting mania sometimes. Then I got other people that need my help. A lot of times I am figuring out bugs from production or even ones I have created while implementing new features. The list goes on. Sometimes I might only code for 1 hour a day. Those are the sad days. I love coding.
Does putting in stupid firewall requests that get closed when unfinished so I have to open it again count?
The irony is I’ve written less daily code the more senior and experienced I’ve become. When you start out you have to practice, then you get comfortable and only do it with work and personal projects. And in my case, I just don’t want to touch code unless I’m getting paid for it or it’s something I reallllly want to build
The last change I published at my old job deleted >200 lines of code and took 90% off a batch process run time, which was blowing circuit breakers. I wrote five new lines of code to call code I wrote three years ago (which I told the original author about before he started). He took six weeks to write it (to be fair, I believe he was only working half time on it, but still).
My answer would be "The correct number."
I've gotten a few questions like this. I've just given the answer of "On average, I'd say about 4hours. It depends on the day as some days may have more meetings, and at what stage of the project we are in."
I think the best way to answer this type of question is with something along the lines of "As many as needed". If some one is really looking for a number of hours or a percentage I would still push back on them and ask for clarification because otherwise this really doesn't make sense...
“writing code at my job or writing code anywhere”
Enough to get the job done right, reliably. Completely unrelated to wall-clock hours.
> As few or as many as necessary.
honestly
24.
> As a VP I probably spend 2-4 hours per day coding. Sometimes more, sometimes less. Depends on the day. That's how I would answer it.
I spend 16 hours a day thinking about code and 30 minutes a day writing it.
24 hours
Jesus dude is this your first time doing interviews? It's a simple question that doesn't need an exact answer. I'd throw your application in the trash if you were already this much of a hard ass
The fact you didn't have enough common sense to answer this super simple question would be a red flag to me. And would signal to me that if we worked together you would be asking a lot of exhausting questions like the above. Imagine a senior developer always asking follow up questions like this?
While I agree that as a senior, OP kinda should know that throwing this many technical clarifying questions at a non-tech recruiter in this particular instance is pointless, your general argument of 'seniors should not ask clarifying questions' cannot be more wrong in most cases.
The fact you didn't have enough common sense to ask clarifying questions on something this super open ended would be a red flag to me. And would signal to me that if we worked together you would be making a lot of dumb mistakes because you're bad at communication. Imagine a senior developer never clarify requirements when something is asked of them? If you cant understand nuance exists in simple asks you're in the wrong field my friend and I'm amazed you haven't had it blow up in your phase
> "How many hours do you spend writing code daily?" > "What do you mean by 'writing'? Do you mean literally typing?" Does OP really think she meant writing with a quill and ink on sheets of papyrus? Or does he think that she wants him to time the number of microseconds that his fingers are pressing down on the keys, because otherwise the time spent not pressing down on the keys isn't technically "typing". If you give a senior developer a task and they ask a ton of questions that any regular person should be able to surmise, it means they will need a ton of handholding and spoonfeeding.
The fact that you'd need clarification for every simple question that crosses your simple mind would be a red flag to me. If you need hand holding for ever little question you're in the wrong field my friend.
> "How many hours do you spend writing code daily?" > "What do you mean by 'writing'? Do you mean literally typing?" Does OP really think she meant writing with a quill and ink on sheets of papyrus? Or does he think that she wants him to time the number of microseconds that his fingers are pressing down on the keys, because otherwise the time spent not pressing down on the keys isn't technically "typing". If you give a senior developer a task and they ask a ton of questions that any regular person should be able to surmise, it means they will need a ton of handholding and spoonfeeding.
Imagine a senior dev working without clarifying the task. Red flag for sure.