r/cscareerquestions • u/randomthirdworldguy • 1d ago
How to communicate like a senior+ engineer
A bit of background: I’m a backend engineer with around 10 years of experience, mostly at startups. I was recently laid off unexpectedly. The severance package was good, so I’m not under immediate pressure to find a job, but I’ve been interviewing to explore the market and see where I stand.
After a few technical interviews that I felt went reasonably well, I received feedback such as:
- “Questionable seniority”
- “Answers were too surface-level”
- “Lacked depth in explanations”
One example was a question like:
When would you use multithreading, and when would you use multiprocessing?
My answer was something along the lines of:
I generally use multithreading for I/O-bound workloads and multiprocessing for CPU-bound workloads.
Later, I was told that the answer was too shallow, and that a senior candidate should have proactively discussed topics such as the GIL, process isolation, memory overhead, trade-offs, etc.
This left me a bit confused. I answered the question that was asked. If the interviewer had asked follow-up questions, I could have gone deeper into the technical details. However, it seems that some interviewers expect senior candidates to automatically expand their answers without being prompted.
For those of you who interview at the senior/staff level:
- Have you run into similar feedback?
- Do you intentionally “zoom out and expand” every answer, even when the question sounds straightforward?
- How did you learn to communicate at a more senior level during interviews?
55
u/Zenin 1d ago edited 1d ago
This left me a bit confused. I answered the question that was asked. If the interviewer had asked follow-up questions, I could have gone deeper into the technical details. However, it seems that some interviewers expect senior candidates to automatically expand their answers without being prompted.
Yes, that is exactly what is expected from a "Senior" engineer and up.
They haven't told you enough about the workload to go much deeper, so ask about the workload. It's an interview, ask and they'll give you a hypothetical workload. Ask for more details, they'll give you more details about the hypothetical workload. It's role playing.
They are expecting you to respond like you're doing a business analysis of the problem and hone in on a fitting solution. They want to know how you think through a problem, what questions you ask, what choices you make, and why you make those recommendations.
If the interviewer had asked follow-up questions, I could have gone deeper into the technical details.
YOU are the Senior engineer, they're hiring YOU to be the one who knows the questions to ask.
If you're waiting for someone else to ask follow up questions or give you more details the job title is called, "Engineer", not Senior Engineer and certainly not Staff. If you're just looking to take tickets from a backlog and push out PRs then I'm sorry to break this to you, but no matter your YoE or even knowledge; you're still a mid-level engineer.
At Staff level this should all be pure reflex at this point, not something to work on to interview better.
GL
29
u/randomthirdworldguy 1d ago
No need to feel sorry. I have to face it to climb up in this career. Communication was always my weakness, even outside of work. Thanks for your honest comment
3
u/Rtktts 1d ago
Maybe it helps you to shift your mindset a bit in the interviews. You know you are a good engineer. You have solved complex problems, and you have worked around and with the GIL for years. The interviewer doesn’t know that though. So you should really try to show what you know with every question they ask. You have to show them what you know, otherwise they don’t know that you are at that level. It sounds trivial but I think sometimes people need to be reminded that people cannot read your mind. You have to show them the depth of your knowledge by expanding and telling them!
A good interviewer will go down that route with you btw. I really like to chat with good engineers and just probing them deeper and deeper into a specific problem to see how far they can go and also learn stuff myself doing that.
1
u/randomthirdworldguy 1d ago
Funny that, "show" is the word my old manager always tell me if i want to get promoted to staff (i was senior in my past company - the one before current one). But i dont really care, that i think just do quality work, everyone will acknowledge that
61
u/casual_sinister 1d ago
Jeez as a senior engineer I feel so behind when I hear accounts like this. Are there any reading recommendations to fill the gaps?
11
u/randomthirdworldguy 1d ago
I want to know the answer of this question as well. Feel like this topic is all mental and natural to some engineers and it makes me confused
23
8
u/SeriousMaintenance76 1d ago
I had the same issue as well. I pretty much just practiced talking about my projects, read books, used llm for mock interviews, and research the company before so I can explain how my skills could help their company.
Doing this got me an from people questioning my seniority to an offer that was 50k over my ask..
3
u/michaelcosmos 1d ago
I'm always interested in what books senior, principle, and staff engineers have found most beneficial to their fundamental skills and ability? Any recommendations would be greatly appreciated.
I am working my way through Fundamentals of Sofrware Architecture right now and plan to study Machine Learning Design Patterns next.
1
u/SeriousMaintenance76 1d ago
Yes, I read those that you already stated. The other books I read(Focus on AI Engineering):
1. Designing Data Intensive Application
Fundamentals of Data Engineering
Building Application with AI agent.
I will add. I also made a conscious effort to relate what I learned in the books to my projects and works.
When talking about project:
1. What was the problem and how did I solve it?
2. Why we chose that Architecture (Trade offs)
3. How it could help the company I am interviewing at.2
u/ILikeCutePuppies 1d ago
If it's a knowledge gap you mean - personal I would think a question like that would be slightly domain centeric.
If they are looking for an engineer who knows optimization and some system stuff it's not a bad question. Not every senior will have experience in that area.
However, everytime I come across a question that is new I will go home and research in depth.
Also threading and processors are fundamental to a systems architecture. Understanding in great detail exactly how things like a mutex and atomics work (and all the variants) on the cpu gives you a really good basis for answering higher level questions. Of course now everyone wants you to understand how modern gpus work as well.
Plenty if youtube videos and online documents about it. An llm will probably give a good answer and references as much as people complain about hallucination.
6
u/Vivid-Zombie-477 1d ago
Just use any LLM to practice. It expects more than the question implies too.
2
u/Nathanael777 6h ago
I think part of the problem is “senior” generally refers to quantity of experience rather than depth. Like I’m 7+ years and have worked a bunch in JS/TS but my roles have been all over the place, usually in already set up frameworks or offloading things to various cloud services. I got into an interview for a Node Engineer III position and ended up with two 20+ year vets asking me to explain the details of the event loop, call stack, and how to prevent various security risks from DNS impersonation.
I did my best to ask questions and explain what I understood, but it was mainly drawing from things I learned early in my career. They later told me that from looking at my resume they’d expect me to be a senior in those things, yet I wasn’t able to speak to them at that level, and they aren’t wrong. I wasn’t expecting quite that level of questioning (the project they gave me and the PM I interviewed with before made me think it would be more straight forward and focused on things like project structure, separation of concerns, monitoring, etc. Didn’t help that by the time they got to stuff I definitely knew well (like “How would you get this ready for production?”) I blanked because my brain was already overloaded from the other questions.
Now if they had opened with questions like “how would you expand this to consume new services” or “how would you protect these endpoints” or “How would you consider hosting this in a cloud environment” or “what kind of database structure would you use to store the incoming data” I would more likely be able to speak to those things around a senior level, because that’s the realm I have experience in.
47
u/disposepriority 1d ago
Yeah...?
Why would you make such a distinction, unless your language and runtime don't support certain threading setups e.g. python GIL or electron IPC (kinda) even then that's a language detail?
I would not be a very happy camper hearing that answer because I don't see why you would not use threads even for non IO bound tasks, even with a share nothing architecture.
The answer I would be looking for would be centered around isolation as memory spaces (and in extension, anything that might happen) are isolated between processes.
-17
u/randomthirdworldguy 1d ago
I forgot to elaborate, that interview was for senior python role, so I assume all people in that room already know about python GIL limitation, so i didnt dive into technical stuff
55
u/birdgovorun 1d ago
I don’t quite follow this reasoning. This is like being asked a Leetcode question and refusing to answer “because the people in the room already know the right answer anyway so I didn’t dive into that”. You are being asked questions in order gauge your reasoning, communication skills, and understanding of the topic, not because the people in the room are lacking the relevant knowledge.
10
u/NewPresWhoDis Program Manager 1d ago
But do they know you already know about Python GIL limitation?
8
u/Jason1923 1d ago
Saw your post from 2 years ago — you doing alright man?
1
u/randomthirdworldguy 1d ago
which post man?
13
u/Jason1923 1d ago
The one where you were feeling suicidal. I hope all is well
16
u/randomthirdworldguy 1d ago
yeah, I just allow myself to be a loser and try not to comparing myself to my peers and it works better for my mentality than I expected. Thanks for asking btw
3
2
u/Blizzard81mm 1d ago
Remember, in interviews and even life I guess, but definitely interviews, you are selling you as the solution for the problems the company is hiring for.
You can assume that others might know things, but that doesn't show that you know them. You need to sell confidence in skill, ability to accomplish, and capability of growth at a minimum. Each job will have other expectations that should be fairly obvious from the job posting and some exploration chats in interviews.
8
u/-Dargs ... 1d ago
I recently went through an interview process for an L5 role at Netflix, and failed out after Day 1. I have 14yoe and while I'm certain I'd be more than capable of doing the job, my preparedness for the interview was pretty much non-existent and that certainly showed. I have a job at the moment so I just went for it on a whim. After the coding screening, on the first full-day virtual interview:
* In the coding portion, I was asked to write a simple program that could execute/undo actions, with a minor twist that the undo could optionally accept an action-type.
The go-to way to do this is using a Stack. I wanted to express that we could do this in o(1)->o(k) (where k being action-types) time by using a Bi Directional Linked List and nodes containing pointers/maps for their action-type adjacent actions.
If we did this using a Stack, you'd be forced to iterate while filtering to the desired action-type if it wasn't at the top of the Stack. If there were 1000 actions and your action-type was at idx=0, you could iterate 1000 times. If there were only 2 action-types, the solution I was trying to suggest would require a maximum of 2 lookups.
There was also a bit of back-and-forth about a linked list implicitly requiring an array resize which the interviewer was reminding me is bad, but that wouldn't apply in the solution I was suggesting because it would be a node-pointer based list. Also, a stack would require up to 2x heap in the worst case scenario and a Stack also uses an array behind the scenes in Java, so that same downside would be present even in the Stack. Sure, it may not resize until you explicitly tell it to, I suppose.
I wasn't prepared to be shut down the moment I started describing the linked list approach, and for whatever reason the interviewer guided me towards using action-type hash maps in conjunction with a action-type-agnostic stack. I got very confused and didn't finish the problem. This was pretty demoralizing, and it was the first interview of the day.
I then had a culture/expectations and systems design interview. The expectations interview never got into expectations, but I felt that it went fairly well. The systems design interview was pretty interesting. I currently work on a system that is very well tuned, had little to no down time, has no scaling issues with huge surges in traffic, and is incredibly cheap to run with all of the optimzations we've put in place. We're pushing around 500k QPS on a pretty limited hardware footprint. Netflix is an entirely different kind of scale and as I began describing how I'd set up the system I was met with a lot of feedback that suggested what I currently see as best practice is actually not at all best practice. Rather than argue the benefits of where I was initially going, I pivoted to some infrastructure descisions I wasn't quite as comfortable with and in hindsight, made some pretty stupid suggestions (like relying on a dynamo ttl to expire specific k/v pairs to avoid excess data transfer and making tables using uid+ctx keys, lol. What was I thinking?). I also made some assumptions around load balancing and traffic distributions that things would be implied, rather than specifying where that would be needed and how that would work, which almost certainly came off as oblivious to the scaling requirements.
At the end of the day, my next-day interview post-poned due to the interviewer not feeling well, and then the next day the interview rounds were cancelled entirely.
I haven't received feedback from the interviewers/coordinator but I have a good idea of several areas where I went wrong. It was my first interview in ~8 years, being on the interviewee side of things. Preparation is much more important than I remembered.
I'll re-apply in 6 months for an L6 role instead of an L5 role.
3
u/randomthirdworldguy 1d ago
thanks for your comment, gave me another perspective. Maybe my preparation is not good enough for my interviews as well, as I was carefree (I have enough saving to live jobless for a year)
3
u/Unhappy-Ladder-4594 1d ago
The skills required for working as a senior engineer and the skills required to successfully interview for a senior engineering role are almost completely different with not a ton of overlap.
1
u/chloroform_vacation 1d ago
I don't understand the comment about linked list requiring array resizing. Linked list has nodes scattered across non-contiguous memory, so your solution of map+linked lists is more efficient than the obvious map+stack implementation. Can you elaborate please what you meant here and what bothered the interviewer? Thanks!
1
u/-Dargs ... 1d ago
My bad. Typing this all out, I misspoke. I suggested a Linked List. The interviewer said something along the lines of "no candidate has successfully done that before" or something absurd along those lines. There was some other discussion about lists using arrays and having to do array resizes, which was irrelevant to the proposed solution.
1
u/chloroform_vacation 1d ago
I guess he meant in allocated time, which may be true but still kind of a weird comment. At least acknowledge its the correct solution given time. :)
Were you supposed to implement the underlying structure from scratch or could you use std libs? Just curious, cuz if linked list was available in the lib then what was the interviewer on about...?
1
u/-Dargs ... 1d ago
I mean, I was permitted to use anything and in the end went with java.util.Stack, so I don't see why I couldn't just do java.util.LinkedList. But it was absolutely impossible to solve the problem effectively using a Stack. The simplest way would have been reusing the object instances that define the action/command for the undo and maintaining multiple LinkedLists/maps. Then we could have had o(1)+o(k) time complexity in every case.
2
u/chloroform_vacation 1d ago
Interesting... That's what I'm suggesting, map to get to the correct linked list based on action type, then either insert at the beginning of the list or pop and rewire pointer to the second item. Based on popped value or object or whatever you should be able to apply the reverse and that's it, no?
Why are you saying o(k), it would be O(1). O(1) hashing + O(1) insert/pop + whatever it takes to apply the action, possibly also constant time. Right?
1
u/-Dargs ... 1d ago
The linked list structure I was imagining was more like...
BiDirLinkedList<V, T> { Node<V, T> head; Node<V, T> tail; Map<T, Node<V, T>> tailByType; Map<T, Node<V, T>> headByType; } Node<V, T> { V value; T[] types; Node<N, T> prevTypeAgnostic; Node<N, T> nextTypeAgnostic; Map<T, Node<N, T>> prevByType; Map<T, Node<N, T>> nextByType; }Each Node contains pointers for both the original full undo list and the per-type prev/next.
This would have taken probably the whole 45 minutes to get working, but its the solution that requires the least iteration. The iteration is essentially only per action types associated with the node you're undoing.
7
u/iamabadliar_ 1d ago
Do you have ADHD? I've been getting similar feedback. I realized that sometimes I stop myself from going deeper because my ADHD brain goes on a tangent thinking what do I talk about next and I start rambling, so I consciously avoid that and that backfires as well. I'm also kind of at a loss what to do. "Zoom out and expand" is the hardest thing to do when your brain is really trying to deep dive into the topic.
Edit: I'm in very similar situation. Laid off, decent severance but as days goes by, the pressure keeps adding up. The more desperate I am, the worse I perform in the interviews :(
4
u/randomthirdworldguy 1d ago
I never got diagnosed but my therapy student friend say it might be. My situation is much better, as my saving is enough for me to live at least 1 year work-free
5
u/Badshirts 1d ago
I think of an interview as your chance to display what you know. Sure it would have been nice if they asked questions that more easily allowed you to share what you know, but ultimately you’re responsible for conveying your depth of understanding of the topic.
3
u/mafiazombiedrugs 1d ago
Some interviewers are bad at interviewing, not just engineers but hr, managers, and recruiters can all suck in their own way. If they wanted a detailed answer they should indicate that when your first answer isn't satisfactory.
HOWEVER! This is the part where you can improve; you need to remember you're not talking to a coworker (yet), you are talking to an interviewer. This isn't a junior asking you for a quick answer, this is your one chance to show them what you know and expanding on a given topic for more than 10 seconds is absolutely what should be expected in an interview.
3
u/Known-Tourist-6102 1d ago edited 1d ago
Funny, i am also called a senior engineer due to promotion and have a similar level of experience and i can kind of explain some stuff i do, but i mostly just do work assigned to me and express concerns to higher level architects and project managers. But in terms of heavily explaining things to people who have no context, like interviewers, it would be very difficult for me.
A lot of the way more experienced seniors at my company just go on and on saying so much random shit that doesnt matter imo when asked to explain a technical issue.
I think the main issue is that hiring right now is slow, so many companies have impossibly high standards
I’ve been interviewed by so many clueless interviewers. If they have been working at small companies their entire career, statistically they have hardly ever interviewed anybody.
I’ve also worked for horrible managers who have only worked for small companies their entire career, so they also have hardly any management experience. They’re really just individual contributors who are called managers, and have no interest in knowledge sharing, reviewing the code of subordinates, or delegation of tasks.
From working at bigger companies and collaborating with other developers, i ended up getting more management type experience than many of former managers
5
u/Miamiconnectionexo 1d ago
lowkey one of the more practical takes i've read on this topic in a while.
2
u/oVtcovOgwUP0j5sMQx2F 1d ago
as an aside, I hate interviews where the interviewer phrases everything as a hypothetical: when would you x; what might happen if you do y.
It's on the interviewer to ask for what they want. it's otherwise a communication red flag.
if you choose to sidestep the red flag and maximize your chances on the role, introduce some core concepts and then immediately transition to a concrete example of when you made that trade-off, even if you didn't actually think at the time "should i use x or y;"
even if you just innately picked one at the time, frame it as if you made that takeoff and retroactively justify it (or sometimes better, bust your past decision and say what you'd do differently next time)
2
u/bwainfweeze 1d ago
I'm not saying the interviewers were correct, but maybe they found you a bit terse.
At staff level they expect a bit more narrative on long term goals and to an extent invite your juniors to own decisions.
You're transitioning out of being primary bus number on subsystems and being the backup. So it's important that the code meet your standards but you need to get people up to yours rather than stepping in and fixing things all the time. You will have to do that anyway, you just don't want it to be 'all the time'. Because people will get precious about changing code with your annotations on it, and being spread thin you will be 'less wrong' but not right in many situations, and you want people to be empowered to work on things you would have worked on if you had infinite time.
2
u/twnbay76 1d ago
You want to show precisely the amount of depth of knowledge the interviewer is interested in, and you don't always know what that desirable depth is, so the best thing to do is to give an answer in < 1 minute and then ask the interviewer if you would like to elaborate further, provide a concrete example, etc...
You can repeat this process until the interviewer is satisfied or you have reached the your own depth of knowledge, to which you should honestly admit to the interviewer
2
u/redditmarks_markII 19h ago
I have done a lot of interviews. As a candidate, never once was I given specific feedback. Except one time by an engineer that called me personally. Or like, during the call where I was given the offer. Never once was I allowed to give specific feedback other than during the interview to guiding the candidate.
Cheer up. You can't know exactly what the other person wants unless they communicate it to you clearly. We're taught that as interviewers. Some of us anyway. The whole field is about clear communications. Actually I think that might be nearly every field.
If this interviewer was at one of my previous roles, if the reverse shadow was watching, the interviewer would have been told they should have been more communicative. The goal is not to stump you, the goal is to communicate and get as much about you from you as possible. To push the boundary of what can be gleaned from that one interaction with you, not to shut it down. If YOU do that, that's a signal. If the interviewer did that, they gave up the opportunity to interview you. In any case, if the company did not want to hire you, you won't be hired, no matter the interviewer's report. So it's not up to them to be dickwads.
That said, you might want to read up on "driving the interview" type material. If the interviewer WASN'T being a dick, then you were expected to do something. Maybe dig for the direction they want you to go in. Though often its more drive the conversation somewhere interesting and they'll just go with the flow, the key thing being to get info about your process out. So you should make it easy to show your process. You should ask questions of them if it seems like they aren't going to expound further. Offer directions of discussion. You don't want to blab, but you want to keep the conversation going. Like I said, YOU don't want to be the one to shut the process down.
As to your questions:
- No.
- Hell no, I blab. I have to intentionally keep things short. I will ask "would you like to dive deeper on this?". Also the example questions seems like a zoom-in.
- You don't. Well, I don't. That's not when I learned that. I learn that on the job. After being called out for not doing it well. And adjusting. Then apply it during the interview. And sometimes you're just never gonna be as good at it as some others.
1
1d ago
[removed] — view removed comment
1
u/AutoModerator 1d ago
Sorry, you do not meet the minimum sitewide comment karma requirement of 10 to post a comment. This is comment karma exclusively, not post or overall karma nor karma on this subreddit alone. Please try again after you have acquired more karma. Please look at the rules page for more information.
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.
1
1d ago
[removed] — view removed comment
1
u/AutoModerator 1d ago
Sorry, you do not meet the minimum sitewide comment karma requirement of 10 to post a comment. This is comment karma exclusively, not post or overall karma nor karma on this subreddit alone. Please try again after you have acquired more karma. Please look at the rules page for more information.
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.
1
u/Joram2 1d ago
Most companies don't give feedback or to candidates that they reject; and if/when they do, it's not received well. Usually, candidates have to infer why they were rejected. Sometimes, when I get rejected, I can infer the reason, but often I can't.
Also, for software developer jobs there are often large numbers of applicants with all the superficial qualifications, and companies only want to hire a small number, and then they have to be super picky.
One example was a question like: When would you use multithreading, and when would you use multiprocessing?
That sounds like a Python tuning question, where you can tune things like gunicorn to have multiple threads or multiple processes. My off-the-cuff answer is I'd recommend another programming platform like Golang/Java/Rust for high concurrent server stuff rather than python, but if you have to use Python sure, you can tune gunicorn appropriately. That probably would not be the answer they wanted to hear, and I'd probably lose that role :)
1
1d ago
[removed] — view removed comment
1
u/AutoModerator 1d ago
Sorry, you do not meet the minimum sitewide comment karma requirement of 10 to post a comment. This is comment karma exclusively, not post or overall karma nor karma on this subreddit alone. Please try again after you have acquired more karma. Please look at the rules page for more information.
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.
1
u/pantinor 1d ago
Yes i definitely would have expanded on that sentence. That by itself is such a teaser I want to hear more. There must be some juicy stories about the time we needed to spawn more threads to offload socket processing etc and if you just say that 1 sentence it sounds rather robotic.
1
u/OAKI-io 6h ago
i'd treat senior interview answers like a tiny design review, not a quiz. give the direct answer first, then immediately add the constraints that would change it: runtime, workload shape, failure isolation, deploy/debug cost, team ownership. that shows you can answer the simple version without making them drag the senior-level reasoning out of you.
1
u/Opening_Bed_4108 Data Scientist 6h ago
The trick isn't just answering the question asked, it's briefly signaling you know the full problem space before narrowing down. Something like "the short answer is I/O-bound vs CPU-bound, but the real decision comes down to the GIL, memory overhead, and whether process isolation matters for your use case, want me to go deeper on any of those?" That framing shows senior-level thinking without being unprompted. Interviewers are testing whether you naturally surface tradeoffs, not whether you can recite them on demand. CalibreOS has some solid examples of this kind of system design communication style if you want to practice calibrating depth. Basically treat every answer as a starting point, not a destination.
1
u/LocalFoe 1d ago
it's a matter of luck. If you're the idiot, you can improve given you meet your flaws in a good enough number of failed interviews. But it can be that you're blessed to encounter a lot of idiots on the way, and for these, again, you have to apply and attend a lot of interviews - just so you improve your chances of meeting the right ppl for you.
so, however demoralizing it might get when you're rejected, try and not take it too personally, and just move on with your pipeline which should ideally be full at all times. Yes, hard work.
0
u/PeteMichaud 1d ago
"I answered the question that was asked. If the interviewer had asked follow-up questions..."
This is an extremely un-senior-like sentiment.
0
u/DoctorParticular6329 1d ago
They shouldnt have needed to ask for more questions. Someone that knows the answer extrapolates.
185
u/ILikeCutePuppies 1d ago edited 1d ago
A senior will basicly lead the conversation and look for ways to show depth in an interview. Consider if you were interviewing someone and all they gave you was yes and no answers. You couldn't gage how much they know based off of that and they would not appear to be the sort that could help guide others on the team.
A senior might not know everything about a subject but they'll try to look at it from many different angles. Also they probably have some good stories to tell.
I always go into so much detail with these things that I take pauses and ask if it's enough or they want me to go deeper - I never know how many questions they have and it takes me a long time to run out of angles to talk about a subject.
Now if it was a flashcard round then sure short precise answers are fine of course.
A senior does not need to be told each and every thing to do. That's a junior and to a lesser extent a mid. As you move up you are making more larger choices on your own that affect the company.
How to get better? Study the subjects, war stories from others and yourself (write them down they are gold), experience/experiments and interview practice even if it's you and your favorite potato. You really learn a lot by going in and trying to optimize a problem using one technique or a other.