13 ms·

I like this approach. Far to often I’ve interviewed at places and been grilled by the interviewer only to find out when you start the quality isn’t great, what

I like this approach. Far to often I’ve interviewed at places and been grilled by the interviewer only to find out when you start the quality isn’t great, what you where grilled on you won’t be working on “as that’s to hard” or “we don’t do that” despite being grilled on it and the level of skill not to great they just want senior people. It’s the bait and switch. At least being taken through existing code you know what you are getting yourself in to. Also looking at the current open pull requests and closed pull requests to see the standard and speed of delivery. Bonus points for no PR’s and trunk driven development as that shows a very mature team. My simpler interviews have often been with companies that have held a higher bar than the ones with tougher interviews. Those companies have often been sink or swim though and if you don’t make the grade you’ll be kicked out pretty quick. My last company had a reputation for new starts disappearing and not great that way, but the team was probably the strongest bunch of people I’ve ever worked with as only do good survived.

kozd 5y ago
Why no PRs?
- lanstein 5y ago
  I read “no open PRs”
ignoramous 5y ago
> Those companies have often been sink or swim though and if you don’t make the grade you’ll be kicked out pretty quick. I hope they weren't some gatekeepers you ran into... "don't use emacs and fish and the dvorak keyboard? you don't fit in here."
- linspace 5y ago
  It would be quite absurd to dismiss a candidate based on the editor and yet I find it more important that a particular cloud provider, which quite often is a requirement.
- deleted 5y ago
  [deleted]
bluefirebrand 5y ago
> Bonus points for no PR’s and trunk driven development as that shows a very mature team. I'm not sure what Trunk Driven Development is, could you elaborate?
- csmiller 5y ago
  https://trunkbaseddevelopment.com/ https://trunkbaseddevelopment.com/
  - Manuel_D 5y ago
    https://trunkbaseddevelopment.com/trunk1c.png https://trunkbaseddevelopment.com/trunk1c.png So trunk driven development means no PRs, until you decide you want to use PRs?
    - iampims 5y ago
      It’s trunk driven because there aren’t some long lived branches like ‘dev’ and ‘staging’ or ‘release-xx’ Feature flags can be used to gate features until they are ready, but all code is committed to trunk and is deployed to prod mostly continuously.
    - Izkata 5y ago
      Trunk-based development, as I've seen it explained in the past, isn't what that site describes. The way I understood it is, no branches at all, everything committed straight to trunk, and extensive use of feature flags to keep incomplete features hidden. Short-lived branches like that site's describing just sounds like a team that's adopted git pretty well, but not formalized usage into gitflow or similar...
    - the_gipsy 5y ago
      It's optional, I guess because so many companies or teams would immediately discard TBD if this wasn't addressed.
    - dgb23 5y ago
      What’s the benefit of having release branches without commits if you can just use tags? I guess the difference is mostly cosmetic?
mylons 5y ago
the blog author doesn’t take them through the company’s code base. the author creates code for the interview.
- wnolens 5y ago
  Yea a lot of people in this thread missed that point. It's still contrived problems, just testing comprehension rather than creation. But you can contrive much larger problems than you could ever ask a candidate to code, so you escape the ability for a candidate to practice your exact questions to some degree.
  - mylons 5y ago
    i kind of like the idea of taking them through your codebase, though. allowing the interviewer to concoct problems leads to something i'm very passionate about, and that's attempting to stifle the ego involved in the interview process. for whatever reason, intellectual prowess, and displaying it, exposes itself in interviews. the interviewer will ultimately end up trying to dominate you intellectually to satisfy their own ego. it's pretty pathetic, and rampant in whiteboarding.
jwatte 5y ago
Trunk driven development has worked well everywhere I've used it. That being said, pull requests / code reviews / merge commits are totally compatible with that. Gerrit, for example, does every commit as a mini-pull-request on top of a branchless HEAD, and when the review finishes, you merge to main/trunk and off to CD it goes.
devoutsalsa 5y ago
I took a job once because they were honest about the fact that the code was a complete shit show, and that’d I’d have to clean it up. I’m sure this is naive on some level, but I’d say you don’t have to lie to people. Just help them imagine doing the job and let them decide if that’s how they want to spend their time.
- whatshisface 5y ago
  Bad code + time allowed to clean it up = perfectly well-defined business requirements + a license to think about code craftsmanship. That's a lot of people's dream job.
  - RosanaAnaDana 5y ago
    Its a pretty common paradigm too. Build fast, poorly, more ducttape than boiler plate, and it works. Bring in a spit and polish crew and build towards an evergreen codebase.
    - formerkrogemp 5y ago
      Duct tape and spit keeps our infrastructure together.
  - jseban 5y ago
    > Bad code + time allowed to clean it up = perfectly well-defined business requirements + a license to think about code craftsmanship. That's a lot of people's dream job. I agree, also sounds like an unusually well defined role with a clear way of having impact. I would also take this job any day over another job that would bait and switch me into some rewrite death march.
  - akhmatova 5y ago
    Not sure if it's my "dream job". But yeah, when you think about -- a sufficiently fecal-encrusted, lost-cause codebase is almost indistinguishable from an actual greenfield opportunity.
zdragnar 5y ago
> Bonus points for no PR’s and trunk driven development as that shows a very mature team. Ugh, pass. Trunk development is fine. Skipping PRs just brings back nightmares of SVN. Even if 90% of PRs are approved without comment, it's extremely helpful for everyone to have a second set of eyes on work before it is merged in.
- BFLpL0QNek 5y ago
  Skipping pr’s is not equal to skipping code review. If you pair, there’s two sets of eyes, to commit both pairs have to sign a commit. You can also organise a demo/quick mob session before commit. Then there’s a level of trust in your teammates. PR’s are great for open source projects as act as gatekeeper so not everyone can commit freely. If you need to gate keep your team members then I’d question the strength of your team. The best teams I worked on who delivered working code fast, efficiently even when they are some of the most complex projects I worked on committed straight to trunk, had a very good build pipeline (super import) and worked closely together for review. The standards where extremely high yet the general feeling was it was less dogmatic, micromanaged or kept behind a gatekeeper. The projects I’ve worked on with dogmatic pr’s generally failed to deliver anything in any amount of reasonable time. The prs where dogmatic as more junior teams get caught up in superficial things such as names, package structure, syntax preferences rather than what the pr actually does.
  - deleted 5y ago
    [deleted]
  - chrismcb 5y ago
    > demo/quick mob session Are you suggesting that a meeting to review cost is going to be faster than a code review? And any comments will be lost? And pair programming? No thanks. I think it you are doing actual code reviews, you are doing something wrong.
    - olliej 5y ago
      Code reviews are incredibly valuable, and are a crucial part of software development at all of tech companies. I would argue that if you aren't doing code review, then you're saying that you believe you and all your company's engineers are better than the engineers at Google, Apple, Mozilla, Microsoft, Oracle, ....
pojzon 5y ago
This is precicely why only few companies will do this kind of interview. Good candidate would instantly notice the team is being labeled as seniors but instead are a bunch of crappy devs with years of experience. Code does not lie. If you are crap you gonna produce crap code. Ive recently hit such a mine. Lies during interview. Gonna sit here through vacations and jump the ship. Was sold on working with experienced ppl with over 10y of experience. Turns out those ppl IMHO have less skill than me few years ago with only 2y experience. Legacy bugers that did not improve over the years.
- jonathanlydall 5y ago
  They have 10 years of experience, but unfortunately it's just the same year of experience repeated 10 times.
mstipetic 5y ago
I’ve never understood this. I’ve had Teams grill me on questions I know most of them wouldn’t pass and they themselves said they’re struggling with delivering things. Some weird dick measuring thing
- jacquesm 5y ago
  Power game.
- jseban 5y ago
  They want someone to do all the work so they can continue coasting, team effort!
- chucksmash 5y ago
  It could be that, but it doesn't have to be. If you're on a team that isn't currently having staffing issues, I don't think it's weird to want your next hire to be better than the median person on the team. "Raise the bar," etc. Asking harder leetcode questions seems like a bad way to achieve it, but I get the impulse. If the bar for member nine of the team is approximately "better than the bottom 4" then that 9th person in is likely to have at least one moment of "wait, how did you pass that interview?" at some point after they come on.
- Riverheart 5y ago
  Or they don't have the time or manpower to fix/learn things and are trying their best to hire someone to help right the ship before bringing you onboard. Such a negative take.
  - mstipetic 5y ago
    Which engineer that is that good would spend years of his time improving a low performing team?
    - Riverheart 5y ago
      One who needs a good, steady paycheck at a stable company? Just because hiring team doesn't have time to learn/apply a specific piece tech on the job doesn't mean they're low performers or less competent than the interviewee. They can be sufficiently busy with their current jobs and need someone experienced to lay the groundwork for others to run with. People that go and implement stuff when they're already busy usually half arse it. Those people are just creating issues that'll be fully realized months, years later. If you say you know tech X, manager wants to hire for tech X to solve a business need, and I'm asked to help interview, I may ask you questions about things I don't know or do myself because it's my professional responsibility to my employer and manager to help them hire a quality candidate. Maybe some people use the interview as a place to be jerks or show off but that's not always true. Personally I'd rather not be involved in the process at all.
jahnu 5y ago
Last person I hired to work with me in my previous job I walked them through the entire code base, architecture and CI setup. This gave the hire a chance to best understand day to day work and me a chance to know which parts they understood immediately and which they would need to learn. Works perfectly for me.
- jseban 5y ago
  A for effort!
  - jahnu 5y ago
    Honestly, it’s less stress than trying to divine magic tests that I alone would be the first to invent if they worked :)
KnobbleMcKnees 5y ago
Riddles posed to me at engineering interviews: ~12 Riddles I've encountered while working as an engineer: 0
jseban 5y ago
> despite being grilled on it and the level of skill not to great they just want senior people Happens to me too, I get tough interviews, and a good salary, but the work is exactly the same as the juniors "a guy on the scrum team". I don't even understand why they hire seniors, or have that title when it means nothing. I guess they expect them to be just faster versions of juniors.
- jacquesm 5y ago
  > I guess they expect them to be just faster versions of juniors. No, they expect them to be: - more independent - able to bring past experience to bear on present problems - make fewer mistakes - be able to help others rise to the next level - possibly make good team leads at a later stage
  - mylons 5y ago
    yes and no. the last company I worked at is a feature factory. They have senior, and staff engineers, on various product teams that have 0 technical influence. What they expected is you to somehow increase quality of the product via code review and writing design documents... but the quality of the product was being destroyed by a handful of people making all of the technical and architectural decisions and forcing their platform on the rest of the org. Upper management doesn't have the technical expertise to see this and thinks this approach will lead to some sort of unified performance and scalability. Maybe it will down the road, but if I can't change out the underlying database, ORM, or web framework for something that is just _better_, I'm ultimately just working on the assembly line at the feature factory as a Sr/Staff engineer.
    - icedchai 5y ago
      I think we must've worked at the same place. I took a job at a jira feature factory working on an aging, ossified code base. Literally, it was using the same tech I was using 10 years ago, almost exactly, except it was new back then. I spent most of my time writing design documents, doing code reviews, and shepherding my relatively small changes through review. Something I could've banged out in a week would take months due to all the review and processes.
kurko 5y ago
> Bonus points for no PR’s and trunk driven development as that shows a very mature team. Trunk driven does not mean mature team 100% of the time, but if you have a mature team trunk-driven is more efficient than PRs. It only works if either everyone is senior, or it’s a project of 1-2 devs, or if people are pairing most of the time.
deleted 5y ago
[deleted]
kolanos 5y ago
> Those companies have often been sink or swim though and if you don’t make the grade you’ll be kicked out pretty quick. My last company had a reputation for new starts disappearing and not great that way, but the team was probably the strongest bunch of people I’ve ever worked with as only do good survived. This is not what I would call a "strong" team. This is what I would call a developmentally stunted team. By that I mean they've reached competency as individuals, but they have limited ability to level up fellow developers. As such, they are not a producer of talent and rely on actual strong teams for their hiring pool. In my experience, these teams are best avoided if you actually care about growth.

kozd 5y ago

Why no PRs?

lanstein 5y ago
I read “no open PRs”

ignoramous 5y ago

> Those companies have often been sink or swim though and if you don’t make the grade you’ll be kicked out pretty quick. I hope they weren't some gatekeepers you ran into... "don't use emacs and fish and the dvorak keyboard? you don't fit in here."

linspace 5y ago
It would be quite absurd to dismiss a candidate based on the editor and yet I find it more important that a particular cloud provider, which quite often is a requirement.
deleted 5y ago
[deleted]

bluefirebrand 5y ago

> Bonus points for no PR’s and trunk driven development as that shows a very mature team. I'm not sure what Trunk Driven Development is, could you elaborate?

csmiller 5y ago
https://trunkbaseddevelopment.com/ https://trunkbaseddevelopment.com/
- Manuel_D 5y ago
  https://trunkbaseddevelopment.com/trunk1c.png https://trunkbaseddevelopment.com/trunk1c.png So trunk driven development means no PRs, until you decide you want to use PRs?
  - iampims 5y ago
    It’s trunk driven because there aren’t some long lived branches like ‘dev’ and ‘staging’ or ‘release-xx’ Feature flags can be used to gate features until they are ready, but all code is committed to trunk and is deployed to prod mostly continuously.
  - Izkata 5y ago
    Trunk-based development, as I've seen it explained in the past, isn't what that site describes. The way I understood it is, no branches at all, everything committed straight to trunk, and extensive use of feature flags to keep incomplete features hidden. Short-lived branches like that site's describing just sounds like a team that's adopted git pretty well, but not formalized usage into gitflow or similar...
  - the_gipsy 5y ago
    It's optional, I guess because so many companies or teams would immediately discard TBD if this wasn't addressed.
  - dgb23 5y ago
    What’s the benefit of having release branches without commits if you can just use tags? I guess the difference is mostly cosmetic?

mylons 5y ago

the blog author doesn’t take them through the company’s code base. the author creates code for the interview.

wnolens 5y ago
Yea a lot of people in this thread missed that point. It's still contrived problems, just testing comprehension rather than creation. But you can contrive much larger problems than you could ever ask a candidate to code, so you escape the ability for a candidate to practice your exact questions to some degree.
- mylons 5y ago
  i kind of like the idea of taking them through your codebase, though. allowing the interviewer to concoct problems leads to something i'm very passionate about, and that's attempting to stifle the ego involved in the interview process. for whatever reason, intellectual prowess, and displaying it, exposes itself in interviews. the interviewer will ultimately end up trying to dominate you intellectually to satisfy their own ego. it's pretty pathetic, and rampant in whiteboarding.

jwatte 5y ago

Trunk driven development has worked well everywhere I've used it. That being said, pull requests / code reviews / merge commits are totally compatible with that. Gerrit, for example, does every commit as a mini-pull-request on top of a branchless HEAD, and when the review finishes, you merge to main/trunk and off to CD it goes.

devoutsalsa 5y ago

I took a job once because they were honest about the fact that the code was a complete shit show, and that’d I’d have to clean it up. I’m sure this is naive on some level, but I’d say you don’t have to lie to people. Just help them imagine doing the job and let them decide if that’s how they want to spend their time.

whatshisface 5y ago
Bad code + time allowed to clean it up = perfectly well-defined business requirements + a license to think about code craftsmanship. That's a lot of people's dream job.
- RosanaAnaDana 5y ago
  Its a pretty common paradigm too. Build fast, poorly, more ducttape than boiler plate, and it works. Bring in a spit and polish crew and build towards an evergreen codebase.
  - formerkrogemp 5y ago
    Duct tape and spit keeps our infrastructure together.
- jseban 5y ago
  > Bad code + time allowed to clean it up = perfectly well-defined business requirements + a license to think about code craftsmanship. That's a lot of people's dream job. I agree, also sounds like an unusually well defined role with a clear way of having impact. I would also take this job any day over another job that would bait and switch me into some rewrite death march.
- akhmatova 5y ago
  Not sure if it's my "dream job". But yeah, when you think about -- a sufficiently fecal-encrusted, lost-cause codebase is almost indistinguishable from an actual greenfield opportunity.

zdragnar 5y ago

> Bonus points for no PR’s and trunk driven development as that shows a very mature team. Ugh, pass. Trunk development is fine. Skipping PRs just brings back nightmares of SVN. Even if 90% of PRs are approved without comment, it's extremely helpful for everyone to have a second set of eyes on work before it is merged in.

BFLpL0QNek 5y ago
Skipping pr’s is not equal to skipping code review. If you pair, there’s two sets of eyes, to commit both pairs have to sign a commit. You can also organise a demo/quick mob session before commit. Then there’s a level of trust in your teammates. PR’s are great for open source projects as act as gatekeeper so not everyone can commit freely. If you need to gate keep your team members then I’d question the strength of your team. The best teams I worked on who delivered working code fast, efficiently even when they are some of the most complex projects I worked on committed straight to trunk, had a very good build pipeline (super import) and worked closely together for review. The standards where extremely high yet the general feeling was it was less dogmatic, micromanaged or kept behind a gatekeeper. The projects I’ve worked on with dogmatic pr’s generally failed to deliver anything in any amount of reasonable time. The prs where dogmatic as more junior teams get caught up in superficial things such as names, package structure, syntax preferences rather than what the pr actually does.
- deleted 5y ago
  [deleted]
- chrismcb 5y ago
  > demo/quick mob session Are you suggesting that a meeting to review cost is going to be faster than a code review? And any comments will be lost? And pair programming? No thanks. I think it you are doing actual code reviews, you are doing something wrong.
  - olliej 5y ago
    Code reviews are incredibly valuable, and are a crucial part of software development at all of tech companies. I would argue that if you aren't doing code review, then you're saying that you believe you and all your company's engineers are better than the engineers at Google, Apple, Mozilla, Microsoft, Oracle, ....

pojzon 5y ago

This is precicely why only few companies will do this kind of interview. Good candidate would instantly notice the team is being labeled as seniors but instead are a bunch of crappy devs with years of experience. Code does not lie. If you are crap you gonna produce crap code. Ive recently hit such a mine. Lies during interview. Gonna sit here through vacations and jump the ship. Was sold on working with experienced ppl with over 10y of experience. Turns out those ppl IMHO have less skill than me few years ago with only 2y experience. Legacy bugers that did not improve over the years.

jonathanlydall 5y ago
They have 10 years of experience, but unfortunately it's just the same year of experience repeated 10 times.

mstipetic 5y ago

I’ve never understood this. I’ve had Teams grill me on questions I know most of them wouldn’t pass and they themselves said they’re struggling with delivering things. Some weird dick measuring thing

jacquesm 5y ago
Power game.
jseban 5y ago
They want someone to do all the work so they can continue coasting, team effort!
chucksmash 5y ago
It could be that, but it doesn't have to be. If you're on a team that isn't currently having staffing issues, I don't think it's weird to want your next hire to be better than the median person on the team. "Raise the bar," etc. Asking harder leetcode questions seems like a bad way to achieve it, but I get the impulse. If the bar for member nine of the team is approximately "better than the bottom 4" then that 9th person in is likely to have at least one moment of "wait, how did you pass that interview?" at some point after they come on.
Riverheart 5y ago
Or they don't have the time or manpower to fix/learn things and are trying their best to hire someone to help right the ship before bringing you onboard. Such a negative take.
- mstipetic 5y ago
  Which engineer that is that good would spend years of his time improving a low performing team?
  - Riverheart 5y ago
    One who needs a good, steady paycheck at a stable company? Just because hiring team doesn't have time to learn/apply a specific piece tech on the job doesn't mean they're low performers or less competent than the interviewee. They can be sufficiently busy with their current jobs and need someone experienced to lay the groundwork for others to run with. People that go and implement stuff when they're already busy usually half arse it. Those people are just creating issues that'll be fully realized months, years later. If you say you know tech X, manager wants to hire for tech X to solve a business need, and I'm asked to help interview, I may ask you questions about things I don't know or do myself because it's my professional responsibility to my employer and manager to help them hire a quality candidate. Maybe some people use the interview as a place to be jerks or show off but that's not always true. Personally I'd rather not be involved in the process at all.

jahnu 5y ago

Last person I hired to work with me in my previous job I walked them through the entire code base, architecture and CI setup. This gave the hire a chance to best understand day to day work and me a chance to know which parts they understood immediately and which they would need to learn. Works perfectly for me.

jseban 5y ago
A for effort!
- jahnu 5y ago
  Honestly, it’s less stress than trying to divine magic tests that I alone would be the first to invent if they worked :)

KnobbleMcKnees 5y ago

Riddles posed to me at engineering interviews: ~12 Riddles I've encountered while working as an engineer: 0

jseban 5y ago

> despite being grilled on it and the level of skill not to great they just want senior people Happens to me too, I get tough interviews, and a good salary, but the work is exactly the same as the juniors "a guy on the scrum team". I don't even understand why they hire seniors, or have that title when it means nothing. I guess they expect them to be just faster versions of juniors.

jacquesm 5y ago
> I guess they expect them to be just faster versions of juniors. No, they expect them to be: - more independent - able to bring past experience to bear on present problems - make fewer mistakes - be able to help others rise to the next level - possibly make good team leads at a later stage
- mylons 5y ago
  yes and no. the last company I worked at is a feature factory. They have senior, and staff engineers, on various product teams that have 0 technical influence. What they expected is you to somehow increase quality of the product via code review and writing design documents... but the quality of the product was being destroyed by a handful of people making all of the technical and architectural decisions and forcing their platform on the rest of the org. Upper management doesn't have the technical expertise to see this and thinks this approach will lead to some sort of unified performance and scalability. Maybe it will down the road, but if I can't change out the underlying database, ORM, or web framework for something that is just _better_, I'm ultimately just working on the assembly line at the feature factory as a Sr/Staff engineer.
  - icedchai 5y ago
    I think we must've worked at the same place. I took a job at a jira feature factory working on an aging, ossified code base. Literally, it was using the same tech I was using 10 years ago, almost exactly, except it was new back then. I spent most of my time writing design documents, doing code reviews, and shepherding my relatively small changes through review. Something I could've banged out in a week would take months due to all the review and processes.

kurko 5y ago

> Bonus points for no PR’s and trunk driven development as that shows a very mature team. Trunk driven does not mean mature team 100% of the time, but if you have a mature team trunk-driven is more efficient than PRs. It only works if either everyone is senior, or it’s a project of 1-2 devs, or if people are pairing most of the time.

deleted 5y ago

[deleted]

kolanos 5y ago

> Those companies have often been sink or swim though and if you don’t make the grade you’ll be kicked out pretty quick. My last company had a reputation for new starts disappearing and not great that way, but the team was probably the strongest bunch of people I’ve ever worked with as only do good survived. This is not what I would call a "strong" team. This is what I would call a developmentally stunted team. By that I mean they've reached competency as individuals, but they have limited ability to level up fellow developers. As such, they are not a producer of talent and rely on actual strong teams for their hiring pool. In my experience, these teams are best avoided if you actually care about growth.