Whats the best way to determine if an engineering team is great?
Posted by aLifeOfPi@reddit | ExperiencedDevs | View on Reddit | 61 comments
when it comes to interviews, everyone is on their best behavior, hides the bad parts, and says all the right things: "we value testing, high quality matters more than going fast, sometimes we accrue technical debt but we manage it, we collaborate and discuss openly as a team, yada yada"
whats the best way to actually determine if an engineering team is great?
BarberMajor6778@reddit
It's tough and you're more likely to determine if there are too much of red flags than the team is great.
You should be very active during interviews and while they interview you you interview them. You should have a list of questions you want to ask them. And believe me, you don't want to ask them if they have 2 or 3 week sprints.
Ask things you're most interested in, for example how they do organize cooperation with teams that are in a different timezone? How often do you stay late? Do you have to start job very early? Ask what they don't like in the company and in the team. Observe they reaction and response. Do you think they lie or they don't tell you whole truth? You can ask them to show you a part of application or the code. If they agree to do it, then while you're looking on the code ask them kindly to open a file witha name which intrigues you (but in reality it don't) - just to see if they show you the best piece of code or just a standard class of the codebase. Ask about technical debt - if they respond they are allocating time for it then ask how much, what does the management thinks about tech debt, how do they determine what to actually improve. Are they just personal 'meh, I don't like that code' or they list problems they found, discuss and prioritize together? Ask them what kind of tech debt they paid during last half months and what are their plans for next six month.
There are many things to evaluate, many things to ask for. You may expect that you some of people will lie to you or they won't tell you whole truth. That's why some of the questions has to be repeated in a different form or have to overlap with each other.
And remember - it is much easier to spot red flags and see that the team or company is not a good place to work that find out that the particular team is great.
By the way - there was a comment stating that 25% of time allocated to tech debt is too much is and is a very very red flag. Not always. Speaking about my current role - our team was established 2 years ago and when we all joined the company we were thrown into a codebase which was literally a battlefield of many, many contributors. We had to take control over it and improve a lot so there are no situations that someone who is on-call has to stay late because of incidents. So, at the beginning, our tech-debt allocation was even higher, it was around 30-35% of time. We all listed all problems we see, discuss them together, prioritize considering the importance from application user level and planned how to improve.
Remember, look for red flags. And also remember that you may be interviewed by people outside of the team you're supposed to join so it can be even more complicated
dillydilly2@reddit
Ask about turnover on the team. If people are constantly quitting, don't join the team. This is something it is harder for the team to lie about, because you would probably find out the truth after joining the team.
circalight@reddit
How quickly people respond to PRs.
Longjumping-Ad8775@reddit
How much money has their code generated? That is what matters beyond anything else. Did you solve the business problem and is the sales team able to take your code and make sales from it? Did you save your company money? How much?
Sure, everyone wants awesome code that makes other developers excited. It doesn’t matter. Cool technology doesn’t matter. Making money from code, that matters.
ched_21h@reddit
But isn't it mostly the product/business responsibility? I mean, the team is your tool to implement the ideas, but ideas should come from product/business. Of course good manager/team lead will listen to the business problems and will give some ideas how to solve them. However it's not the team's fault if they were told to implement X and Y and these X and Y turned out to be unprofitable.
Longjumping-Ad8775@reddit
No, no, no. You are over simplifying this and shifting the blame. You have to produce code that is sellable. I’ve seen code that is complete sh*t that wasn’t sellable. I’ve written great code that did everything that was asked of it and performed very well that didn’t sell. It wasn’t the problem of the sales organization, it was the problem of the pm.
I’ve taken over code that met every testing requirement and didn’t work from the standpoint of the user. Is it more important that it was testable, or that it didn’t do what the user wanted, so they didn’t want it?
Developers never want to look internally to problems. Internal problems are hard. I get it. I’ve been there. Developers think that their code is perfect. Writing code is only about 20% of the battle in software development. 80% is dealing with other people, getting correct information, etc.
If you come to me and I interview you and you tell me that you wrote code that did not produce any money or generate any value for the organization, I am going to ask you why. If your response is, “the sales organization is to blame,” I don’t know if that is true or not. I am going to wrap you up in the same ball of funk as any other failed project, and I am going to not consider you. I’ll accept, “I gave feedback on the design being wrong.” And then we will dig into that with more questions from me along the lines of the back and forth between you and others regarding the problems. I’m looking for people that can take the bull by the horns, not the mindless automatons that simply do what they are told.
ched_21h@reddit
Well, I've been working as software engineer for 13 years, and I have never access to the information how much money the code me and my team generated brought. Our clients didn't want to share this for, my company also didn't want to share how much did they earn selling our code. So where should I find out this information?
Longjumping-Ad8775@reddit
I’ve been working longer.
Surely you’ve got enough experience to understand what is going on.
Here are a few projects that I’ve been pulled into. Hopefully this will give you some ideas as to how to examine what is going on. * built a report system for C level execs at major fortune 100 company to be able to determine forecasts of upcoming sales. Based on estimates and would help company to determine where to spend more money quickly. Projected to improve productivity $8-10m per quarter. * build the complete system for a startup that scaled to $25k per day of income in 2001. This included income and real time reporting. Startup eventually sold shortly thereafter after for $11.5m. Built front end, back end, and reporting solution single-handedly. * built the entire reporting system to track foster parent education for a US state under federal court order. Saved state from penalties of $X per day in legal penalties (I don’t remember what the legal penalties were). And on and on and on. The key is to be able to put some financial figure on the amounts. I got this data by asking questions and listening. Being able to quantify results is incredibly important. It justifies your existence.
ched_21h@reddit
I don't know, it's all sounds like a made-up numbers for me. Unless you have the the access to the exact financial information, all these "projections" and "assumptions" as effective as putting random number.
I know that HRs and hiring managers love such kind of things, and I can made up them, but it doesn't change the fact that these numbers are made up.
Longjumping-Ad8775@reddit
Well, I can only share what has worked for me. The feedback I get from customers is that they will pay more for me than “just a developer.”
Ok-Yogurt2360@reddit
This is how you get buttlickers and vibe coders. A bit of business sense might help but you would be better off with someone who talks back and negotiates.
Shazvox@reddit
I tend to ask how their general workflow is. Like, "Describe a features journey from idea to product". When things tend to get vague or I feel like their missing steps (like the journey starts with "PM tells us to do X" or a journey ends with a push to prod with no followup).
TBF that is more an indicator of the IT maturity, but can also be an indicator of the willingness to become more mature.
Another question I ask is to describe the roles they have on a team. Like, do they have designers? Do they use manual testers? Do they even know what a product owner is?
lazytitan211@reddit
The joel test should be a decent place to start
https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-steps-to-better-code/
aedile@reddit
There are a lot of small things, but one thing I haven't seen mentioned in the thread yet - I usually ask if I can talk to their DevOps engineer. DevOps engineers usually give it straight and know where all the skeletons a team has buried are located. They're usually the person who's most overworked on the team and can give you a good idea of how things will go. Or they're crap and you should pass anyways.
CombinationNearby308@reddit
I was trying to do this a decade ago when there were many options to choose from because I want to make a less shitty choice. The last 4 years have been so bad that I sold my soul for better money. Is the market returning to this place where people have a choice?
chrisrrawr@reddit
ask intimate, personal questions about outcomes.
ask about their favourite work.
ask about what theyre proud of, and followup with what they would want to work on if they got the chance.
ask them what they regret, what they would fix if they could, and how.
these are hard questions for many, and their answers are not always, or ever, top of mind. give a lot of grace when interpreting the responses.
but they are typically very good at showing what the person being questioned actually values as an individual when it comes to their daily work, goals, and deliverables.
apartment-seeker@reddit
( ͡° ͜ʖ ͡°)
diablo1128@reddit
When you ask questions and get answers, think about their answer and ask follow up questions.
How do you manage it? How does the work get put in to the sprint? How much time is dedicated to paying down this debt?
Then listen to their answer and ask a follow up question to get at more details. Nobody answers in detail right away you have to drill down to get at them.
It's like they people who ask if the team does code reviews. The question is just there to set the topic. You need to anticipate the general big picture answer is going to be some form of Yes and ask follow up questions to get at the details that you want to know.
aLifeOfPi@reddit (OP)
>How do you manage it? How does the work get put in to the sprint? How much time is dedicated to paying down this debt?
last team i asked said "we have dedicated tech debt weeks once a month"
sounded good. was amazing answer.
turns out they didn't accomplish shit in those weeks. because they often didn't know all the problems they had and were just pushing piles of s*** around.
i guess i could've pressed harder: "what did you accomplish the last tech debt week" but dont wanna come off as interrogating
recycled_ideas@reddit
Developers are really bad about tech debt because we often view technical debt as "anything I don't like in the code base", which isn't right.
Technical debt is a loan, you borrow it for a reason (to meet a deadline, because of a mistake, because things you couldn't predict changed) and it has an interest payment (extra bugs, drag on velocity, difficulty training new hires). When you choose to take on technical debt you try to predict the value of the loan and the cost of the interest payments, when you pay it down you look at the cost to fix vs the interest payments.
When you evaluate things this way you can talk to your manager in a meaningful way about decisions both to take on debt and the priority of paying it down in real terms. The flip side of it is that you'll find that a lot of technical debt has little to no interest payment and so it actually doesn't make sense to pay it down. If code isn't how you'd like it to be, but it's not causing problems you leave it alone.
If you are allocating 25% of your overall time to paying down tech debt you are either accruing tech debt waaaaaay to rapidly (which indicates bad leadership) , paying it down waaaaaay too slowly (which indicates a bad team) or you're fixing shit that doesn't need fixing (which indicates a bad both).
This answer is a massive red flag.
zirouk@reddit
However it got there, at least they’re paying it off rather than drinking strong beer in the park.
recycled_ideas@reddit
Except they weren't, that's the whole point.
No functional team is spending 25% of their time paying down tech debt, it's insane. If your tech debt levels are bad enough that competent managers are actually going to allow that you'd just spend the time required to get it done so management is incompetent, which means the team probably isn't delivering anything or they spend the rest of their time building up tech debt to make up for all the time they lost.
Beyond that, a team that remotely considers that a reasonable thing to do and with management that hasn't said wtf to it is likely to be churning because there's no one keeping them from pissing away their budget or on track (see incompetent management) so most of the "pay down" is likely just bike shedding bullshit.
And then you have the fact that even for a hyper productive team a week isn't really enough time to sort out any serious problems and three weeks of bit rotting and context switching probably puts you back at square one so you'll never accomplish anything.
If a team said they spent a month a year, that might be sensible, it's not an untenable amount of time and you could actually make a difference, but one week a month is dysfunction at the highest level.
zirouk@reddit
Yes, it’s one thing to look at the past and say “we shouldn’t have done that”. It’s something else entirely to say “oh dear, we’re in a pickle, let’s do something to plug the holes in our ship”.
It feels like no matter what this company does now, you’re going to want to find fault with it. It doesn’t have to be like that.
recycled_ideas@reddit
This company is not plugging the holes. If you need to plug the holes you stop work and plug the holes.
What this company is doing is burning 25% of their FTE budget attempting surface level fixes without a plan because someone has convinced an incompetent manager that that's best practice. OP literally said all they were doing was pushing shit around, and that's all they were ever going to do because you can't fix structural problems in an unorganised week.
It's not a matter of "no matter what they do", there are a hundred sane things to do depending on what their actual situation. The problem is that what they're actively doing is dysfunctional and wrong. They are burning an absolutely massive and unsustainable amount of budget in a way that will never work because they are allocating way too much time in chunks that are too small to fix anything that's actually worth fixing.
aLifeOfPi@reddit (OP)
Issue: team doesn’t know where the holes are that need plugged
aLifeOfPi@reddit (OP)
Thank you for bringing sanity into this.
recycled_ideas@reddit
It's hard to judge a good team, just as it's hard to judge a good developer, that's why personal recommendations are such a huge thingin this industry.
If a dev you know and trust says "come join my team it's great here" it counts for a lot just like if they say "I've worked with this dev before and I'd love for them to join our team" that also counts for a lot. Still not a guarantee, but the best I've ever seen.
diablo1128@reddit
If it was important to me then I would have pushed. An answer like: "we have dedicated tech debt weeks once a month" would have me asking follow up questions. Though I wouldn't ask "what did you accomplish the last tech debt week" has it's too generic.
I would ask like How did the team decided what tech debt items you want to solved during the week? Then based on the answer I may follow up with how many changes actually gets released? There is only so much they can say until you get the sense they are just trying to dodge the question or hide something. That's the data point I would be looking for.
kosmos1209@reddit
If it’s a consumer-based app or website, just use the product or service. The quality of the product mirrors the quality of the team.
its4thecatlol@reddit
This is a common FAILURE MODE actually. Learn from my mistakes. The team that built the product is not even guaranteed to be the team you are joining. People leave, get promoted, go through life transitions, etc. Even if it is the same team, excellence may be limited to a select few individuals.
Product quality is thus a very noisy signal of competence, and competence is only one of the things to look for in a new team.
Jarmsicle@reddit
I don’t know that I agree. I think you can tell when an engineering team is good by looking at the project, but a bad product doesn’t necessarily mean the engineering team is bad. It could also be the result of compromises made for the sake of timeline. Or changing requirements. Or any number of other non-engineering decisions that wind up impacting the software.
Ok-Advantage-308@reddit
Agreed. Engineers can still deliver a shitty idea with good engineering.
Also bad quality sometimes can be because of bad requirements. It doesn’t always mean the engineers are a bad team.
trwolfe13@reddit
Or in our case, we weren’t allowed to resolve technical debt or fix bugs unless the work had been signed off by product. Which of course it never was.
We tried our best to front-load all those things or sneak them through with other PRs, but there was a member of the product team on every call, so we had to be sneaky about it.
mcjohnalds45@reddit
A new product built by a good team may suck and an old product made by a bad team may work flawlessly.
bestanealtcizgi@reddit
Ask to have a tour of the project’s codebase that you’ll be working on.
Just sit down with one of the team members at their workstation.
Ask about how to set up the working environment and how to run or test the project locally (if the README file explains that clearly, you might not need any guidance).
Check their PRs, notice the tone and vibe there. What are they focused on?
Look at the tasks: how detailed are they? Are the acceptance criteria clearly defined?
If they are not willing to do these simple demonstrations, probably they are trying to cover some nasty stuff,
forgottenHedgehog@reddit
No fucking way is my company going to allow showing you any code. For all I know you might as well be scoping out the company for an attack.
bestanealtcizgi@reddit
They don't have to show. If a codebase is vulnerable just by presenting a readme file, explaining how it spins on a development environment and maybe just a few classes are partially exposed, I wouldn't like to work on that. It's a win-win situation.
forgottenHedgehog@reddit
Readme of all the apps at my company contains information about deployment, observability, PRs could easily be features covered under NDA. No upside to the company to allow this.
MB_Zeppin@reddit
Ask about the negatives - what would you change if you had a magic wand? What’s something you don’t like about your process? What’s your least favorite part of your product to work on
Your mileage may vary but in my experience bad teams dodge the question or give a vague one, good teams have answers with specifics as to why
No codebase is perfect but codebases where people feel compelled to bury or hide obvious issues? Those are worse
andrew_sauce@reddit
This, really good teams will have no problem sharing what their pain points are. They will have good accounting of them and probably even some plans or ideas for how to move in the right direction.
In Poorer environments they will be tight lipped around that stuff, wary of other people on the call or going to review it, and hesitant to talk about things they have no plans to address.
Intelligent_Water_79@reddit
above all, there will be a communal groannn which indicates a shared commitment to their work practices
gemengelage@reddit
The only technique I found to truly work is already knowing someone on the inside.
Whenever I tried to interview the company, they either lied, refused to answer or absolutely did not like that.
HK-65@reddit
Drill down into questions, ask for examples.
What strategy and frameworks do you use, what are your coverage numbers, why so high, why so low? Do you frequently have blinking tests? Do you test-first, test-last? Are tests required for a PR?
How much time do you have in sprints left over for keeping tech debt under control? What velocity metrics do you use?
What is the biggest technical debt item you would like to refactor or get rid of? How much time do you think it would take? When do you think you'll have time to do it?
Specific questions are harder to consistently and convincingly lie to.
ched_21h@reddit
The core of the application which had been written 15 years ago and the creator while still working at the company left no documentation.
Nobody knows, because it's the core of the application, the original creator is too busy and has no time and nobody wants to mess with it. Just investigating this will take a couple of human-months, and business don't want to spend money on it.
Never, because the business again is not interested in spending money on that. And even if we invest into that, it most likely won't be worth it.
Here are the honest answers for the last project I worked for. But I don't think you will be satisfied with these answer. You will most likely see it as a negative attitude and the lack of initiative. So I will come with a made-up story instead where I show myself (or my team) as thoughtful, pro-active and taking care of the technical dept as much as for the business needs. And you will have no way to check whether what I'm saying is true or not.
ched_21h@reddit
Here is the thing: even with the candidate you can't say, if it's great or now.
The interview process nowadays is just a 30-60 minutes of hypocrisy, lying and trying to guess what another side expects to hear. Even the technical ones are full of this. You should be really stupid to tell on the interview "I'm a father of 2 small children, I'm just looking for a job which maybe not be having the highest pay, but I will be able to coast there and get as much free time as possible". Of course you will be saying, that you're pro-active, ready for challenges and a great problem solver.
You can filter out fully incompetent workers or somebody who's values and expectations are not matching with yours. But anybody who wants to get the job will be preparing to maximize their chances of getting this job. And they will be looking "what questions are usually asked on the interview" and will prepare correct answers for these questions.
So realistically you can't determine if an engineering team is great on the interview. You can filter out somebody who does not match your vibe, but only by working with them and seeing their results you can see whether the team is great.
Don't be delusional.
AdamISOS@reddit
You cannot determine this from an interview. You need to ask a different question: How can I determine red flags that would prevent me from taking this job interview process further? You will only learn if you're in a great team after months in the organization.
testingusername0987@reddit
Ask about the turnover rate (split by voluntary / compulsory). And then, depending on the answer, dig further on the why-s high/low. "Oh, how do you guys manage to have such an high retention?" or "Uh, have you guys managed to identify the reasons for this?", etc.
If they provide it, and you manage to interpret it correctly, it is the single most valuable metric that tells you everything you need to know about an engineering team before joining it.
LogicRaven_@reddit
There is no way I know of to be certain, but asking open ended questions helps.
“How does an idea get from scoping to release in this team?” - watch for any warning flags and how they describe their process overall.
“When was the last critical production outage and how was it handled?” - watch also for pauses and their facial expressions, do they look honest?
“How was your last week? What did the team do?” - what topics do they pick to represent the work is interesting. A follow up question on how many hours did they work comes naturally.
Observing how they treat each other during the interviews can also reveal things. Professional tone, equal contribution from people or only the manager talking, etc.
Zestyclose_Humor3362@reddit
The trick I've learned is asking about their biggest technical disaster from the last year and how they handled it. Great teams will tell you specifics about what went wrong, who was involved in fixing it, and what they changed afterward. Bad teams either can't think of anything (red flag) or blame individuals instead of systems.
Also watch how they talk about their current codebase during technical discussions. If they're constantly apologizing for it or making excuses, that tells you everything. Good teams acknowledge technical debt but can articulate why certain tradeoffs were made and their plan for addressing it. At HireAligned we've noticed the best engineering cultures are honest about their problems because they're actively working to solve them rather than pretending they dont exist.
aLifeOfPi@reddit (OP)
You last point was my answer to this question.
Great teams know when they are making debt and why they are making it (the specific tradeoffs)
Bad teams add to debt without knowing until one day they are screaming about “tech debt”. but if you asked gave the unlimited time, they’d still have built it the same way they did before
JimDabell@reddit
Their last point was spam. You’re praising spam.
E3K@reddit
Bad bot.
WhyNotCollegeBoard@reddit
Are you sure about that? Because I am 86.11871% sure that Zestyclose_Humor3362 is not a bot.
^(I am a neural network being trained to detect spammers | Summon me with !isbot |) ^(/r/spambotdetector |) ^(Optout) ^(|) ^(Original Github)
E3K@reddit
I'm 100% sure he's spamming his startup in every comment he writes.
Willbo@reddit
It's very subjective to what you're looking for in a job, and the more time you spend in the field the more you're able to recognize the signs and ask relevant questions. IMO engineering is the easy part, but planning, prioritization, delivery, mentorship, frameworks etc are the hard questions.
"What type of Agile methodology do you use?"
"It's Friday afternoon, the last day of our sprint and we are working for a PR for a production deploy when a high severity security alert comes in. We also have a meeting scheduled with a customer in 30 minutes. Which of these tasks get prioritized and how?"
"A director for another product asks you for an important feature and you're not sure it's even possible but it would look really good for the department. How do you choose which of your engineers gets assigned to it and what timeline do tell the director?"
"What's the most impactful process improvement you made that was based off of incorporating an employee's feedback?"
Some of these questions might even get you disqualified for just asking, but that's an answer in itself.
kyoob@reddit
“Do you work with any jerks?”
Icy-Stock-5838@reddit
Ask to meet your team mates..
Read their tone of response, their body language, their none verbals..
They will be less adept at lying than the manager because they LIVE the daily pains, and you will pick this up in their none verbal cues.. Of course you need to ask good questions to draw this out... The kind of questions one worker to another can relate to..
Often "Common Pain" is what gets people to lower their guard.. "..we are the same...", "..I know what you mean.."
https://youtu.be/2ZgUTX3VNQ4?si=YhM-iy2CVPEusxPC
nfigo@reddit
Pale_Height_1251@reddit
Realistically, without looking at the code you can't tell.
funbike@reddit
User satisfaction.
Jackfruit_Then@reddit
Best way is to see what the team has delivered.