How do you interview senior software engineer ? What do u consider is a good interview ?
Posted by lambda-reddit-user@reddit | ExperiencedDevs | View on Reddit | 21 comments
Hello everyone,
I have been asked to participate in the interview of candidates for software engineer (fullstack) rôle at my company. And as I don’t have much experience interviewing people, I was wondering a bit what you consider good or bad, what are the things pertinent to ask or to look for ?
Or for people who were being interviewed, which one you appreciate vs the ones you hated and why ?
UnderstandingDry1256@reddit
How many tokens do you burn per day?
You’re dealing with a project in a 100k files monorepo and weird bazel tooling you’ve never seen. What will be your first prompt and overall process to make updates?
How would you validate this 50 files / 1k likes PR - your prompts and overall approach.
Then “design me this … system” for architecture.
Regular_Yesterday76@reddit
Ask them what language level update solved a problem that was previously being corrected by a library, tooling, style or architecture paradigm.
Slow-Entertainment20@reddit
When I interview people senior+ I usually have them whiteboard a recent system they worked on and then dig into specific components they worked on and why they made x y z decisions. If they can’t talk DEEPLY about it then they are not a great fit.
futuresman179@reddit
What do you define as deep? Maybe an example would help.
Slow-Entertainment20@reddit
Say they used Kafka for something, I might ask why Kafka, I’ll ask what is their retention period. What issues have they run into running it? Etc it’s not a black and white they answered any of those questions i just prob on things and see what they say and how they say it.
javasuxandiloveit@reddit
Do you require coding challenge for seniors?
Slow-Entertainment20@reddit
Since AI I stopped doing coding challenges as people were just cheating.
guardian87@reddit
One of the best articles I've read on hiring: https://dannorth.net/blog/interviewing-for-evidence/
gjionergqwebrlkbjg@reddit
Keep in mind this subreddit is predominantly people with little experience, and most of them on the candidate side, not interview side. It's honestly a terrible place to get advice about hiring for.
dvorgson@reddit
If they talk about implementation details in terms of the underlying ideas rather than the packages and services they would use
pydry@reddit
I get them to work on a set of tasks which are as realistic as possible, usually using real code that is decoupled from external crap.
I start off with easy tasks to get people into the swing of things and calm the interview jitters.
I select tasks which have hidden, realistic traps which experienced people will see and inexperienced people will miss.
I usually set tasks which take 150% of the interview time and warn the candidate that we wont finish.
Ive had interviews done on me which sprung a "narcissism trap" in the technical part. although i havent done this one myself but i would like to do it in future interviews coz those people are an existential danger to teams
juusorneim@reddit
pydry@reddit
Something like using a floating point for money or being led down the garden path to a nonobvious bug.
I think it was telling somebody that theyre wrong about a few minor things and seeing how they react.
Sharpei_are_Life@reddit
The good engineers can explain projects they've worked on in a coherent way - not just how it worked, but why it was designed to work that way. They will talk about the trade-offs that needed to be considered before implementation and after release, and will give credit to other team members when due.
Vamosity-Cosmic@reddit
pursue management subreddits or management education, unfortunately, software devs are poor at interviewing because it either becomes a circlejerk or its off the mark (just being honest, im included in that group)
F0tNMC@reddit
I like the technical deep dive interview. Either something extremely common or something with which they have experience. For the extremely common thing, I like asking "What happens when you type some words in the browser search/address bar?" And have them walk through as deep and as detailed as they can, down to the DNS cache/lookup.
For the "thing they know" I like them to walk through a system that they owned. Again, going into the details. If they say it was deployed using Kubernetes, I ask how kubernetes works. What are the services, what is the system of record, how does the system know when to change things etc. etc.
I'm looking for understanding and ability to communicate that understanding. I'm also judging based on seniority and years of experience. Less than 6-8 years, I'm expecting a good understanding of the basics and the details of their implementation, but not the implementation of all of the systems on which they relied. More than 10 years, I'm expecting all of that and good understanding of at least a few of the systems that they didn't write but used. I'm also expecting a lot of "I don't know, but here's how I'd figure that out." answers. I don't expect anyone to know every detail of all of the implementation down to the metal.
hitanthrope@reddit
Everybody (especially HR people) want it all structured and formal.
For me, sit me down in a room with somebody for an hour while we talk about software, and by the end of the hour, I will know whether or not I want to hire them and I am fairly certain that no other process would provide a better "hit rate", of good hires.
For senior people, I don't even need to see code. If they can engage in conversation with me about things, on the level that I would expect to be able to engage with seniors, i'll know they can code.
Actually, i'll up this ante a bit. I am fairly sure, I could make good hires by just asking, "How do you think all this AI stuff is going to effect things and why?", and nothing else.
I simply "just know" when a competent, senior engineer is talking about engineering.
"Senior" isn't really about specific questions, or even specific code skills... it's about how you connect everything. At least in my opinion.
GoodishCoder@reddit
Personally when I'm interviewing people, I start with a really good understanding of the role being filled. From there I look through resumes for anything that might be relevant and pre form some base line questions to start the conversation. Then we just spend time talking about what they have done throughout their career that's relevant.
igharios@reddit
What are you trying to cover? Coding/Architecture/System thinking/cultural fit/....?
I would put the category down and go from there. I like breaking it all down to this
Existing experience vs New thinking. Tell me about a time when you did X VS I don't see X on your resume, how would go about solving it?
Allow them to ask questions - you will learn a lot about them
I always liked pushing on some button. It is important for me to understand if they can conflict and manage it
Don't forget practices, what do they care about or not (unit testing?) I would say pull your company career ladder, see what it means to be a senior engineer and cover that
Outside-Storage-1523@reddit
Never interviewed anyone, but basically I like those interviews that get deep into the tasks I did. It would also be nice for the other party (the interviewer) to discuss alternative ideas on the fly.
But in general, you want to look at his/her CV, find something and make sure it is not a BS. You want to grill down into some technical details and why they are chosen. You also want to ask what went wrong and how was it maintained, etc.. Requirement taking and handover should also be asked.
Sensitive-Ear-3896@reddit
Have you ever impelmented X (where X is something in their recent experience) , What were the gotchas of X
I also ask them what are you working on this week/month which might lead to me asking about X, often because I am genuinely curious.