6 ms·

This, so much this. Just know though, that there are different places out there. I surely am tempting Murphy right now. Please recognize my sacrifice. My curr

This, so much this. Just know though, that there are different places out there. I surely am tempting Murphy right now. Please recognize my sacrifice. My current place is rather good in this regard. People actually care. The Devs genuinely care about both their work environment and code base. We actively try to hire other people that care and not let in the ones that don't. We do hire 'inexperienced' as well but that doesn't mean you gotta take bad dev experience. For example I have a really 'inexperienced' guy on my team. But we hire him anyway because he showed signs of 'caring' during the interview and coding challenge (take home - I know what you think. It's different than you think and I'd be happy to elaborate if you want to). He is awesome! I try as hard as I can to give him the space to be awesome and not let the 'bad parts' of the company (which exist even in awesome companies) reach and discourage him (and others like him). We keep our builds fast, we spend a bunch of money on giving every dev a prod like environment. A monorepo.

Ternari 5y ago
Your company sounds great. Are you hiring?
phnofive 5y ago
Please do elaborate on your take-home; in a profession with no formal credentials (i.e. no MSBE for SDEs), I don't mind putting a little skin in them game for the same purpose.
- tharkun__ 5y ago
  Well why I said that is because of all the discussions on HN about people hating leetcode, hating take homes hating... well just about any form of interview if I read it right. Now I am/have been on both sides of this. I happen to like take home for devs. I like it because it takes out some of the stress of interviewing. If done right. I have been advocating internally at my company for stripping down the take home test. Who wants to do a "this should take you 4-8 hours" test? Which nobody internally actually tried to do themselves in that timeframe. Nobody! Especially not if you have a job at the moment. And a family. But want to take advantage of the market and/or look for a better company. What do I look for in a take home? Not running code! I couldn't care less! I have never in my life run up a take home test someone sent in (backend). I look for code cleanliness, consistency, abstractions, DRY, WHY comments. If you send in something without any tests you are out. If you have a hundred tests to show 'you do tests', you are out. If you have 5 tests that are of awesome quality and show that you know what is worth testing and how to write tests that will survive a refactoring of the code and actually tell you that your refactoring didn't break anything I will hire you and pay you money to write a hundred of those tests when it actually matters. Maybe add a comment that you could write the same kind of tests for the rest of the code but your kid needed a good night song and the deadline for the test was up. I was hired on such a take home. My code deliberately did not run. I called out to external services that I did not bother to include in the take home test because it asked to solve the problem and I knew they used microservices. And business wise those things should've been handled in those other microservices and not the one I was writing. I also left out the database. Not worth even an h2 in pom.xml. They happened to use gradle. They didn't care I used maven. Still love them for it. Had the best interview ever. Loved the pros and cons discussion with my interviewer. Awesome guy. Now depending on what position you get hired for this might change. An architect position for example a whiteboarding session might be more appropriate. Just have a problem to solve (e.g. one of your own main use cases) and have them design it with you. Who cares if they come up with the same solution you did. It's about the discussion. The pros and cons. The general attitude towards solving the problem. If they admit they don't have the answer to something off hand but its a 'googleable thing' they've just never had to solve before, that's fine!
  - Osiris 5y ago
    We do take home tests and I find them valuable. We do, however ask them to host it somewhere to be used. 1) we want the time investment to be <4 hours 2) the test uses public APIs and is directly related to our work (crypto) 3) we had the team (mine) do the test themselves before making it official 4) we also are looking for things like tests, thoughtful architecture, etc. It's hard for a junior dev to fake well structured and organized code because it takes experience and thought to do it that way. If I were interviewing I would much prefer a take home rather than an in person leetcode interview. I also don't mind in person pair programming (like help us fix the bug in this code or whatever).
    - disgruntledphd2 5y ago
      > If I were interviewing I would much prefer a take home rather than an in person leetcode interview. It's tricky, because this can vary within one person across time. For example, in my area (DS), i think that the take-home gives the best signal for the actual work (as long as its well scoped). But, as a parent of a small child, I'd much prefer to just do in-person tests/discussions as it takes less time away from my family. So it's hard, and whatever you choose will lead to you missing good candidates. Unfortunately, as in many areas, there's no silver bullet.
  - stavros 5y ago
    Exactly agreed. We implemented such a take-home as well, hopefully it takes candidates 1-2 hours to complete, but we need more data on that. You're scored on various well-defined areas, and it is, as you say, to show us that you know how to organize code. We don't even try to run it (though CI should pass).
randmeerkat 5y ago
You lost me at monorepo. That might work at a very small scale, but past that monorepos create more problems than they solve.
- delta1 5y ago
  Like google scale?
  - randmeerkat 5y ago
    Sure, if you want to write your own version control system and also your own computer language to support it.
    - delta1 5y ago
      There are many other examples of large scale monorepos. They in no way require custom version control nor programming language.
      - randmeerkat 5y ago
        What are the other examples you’re referencing?
- hsn915 5y ago
  like what?
  - randmeerkat 5y ago
    Like versioning services, deployment of the code base, breaking out new microservices, transitioning to any container based deployment solution. Monorepos aren’t just a nightmare for release management, they’re a nightmare for any sort of single responsibility oriented architecture. I’m really exhausted of “senior devs” that believe they’re architects championing monorepos just because they’re too lazy to change minor versions in a repo.
bob1029 5y ago
This sounds like our shop. One big fat monorepo, every merge to master must satisfy a checkbuild. Speed is a big deal for us too. The entire thing can be built from clean in ~3 minutes by GH action workers. We buy our developers threadripper workstations, so local rebuild times of the solution during typical development iterations are closer to 15 seconds. We are much more interested in developer ergonomics than with simulating prod environment. I genuinely believe having fast builds is the most important part of the developer experience. Somewhere around a build taking more than 30 seconds is when bad things start to happen to my engagement loop. If I can keep it under 30, I can stay in flow the whole time. Other developers on the team have expressed similar tolerances.
- rightbyte 5y ago
  I don't get the initial short build time thing. My prior work project took 15h too build from clean - obviously a nightmare. It was due to bad layout of dependencies and a lot of generation. So it is still important to not mess up. I care mostly about cached build time. A clean build time of eg. 1h does not bother me.
  - selfhoster11 5y ago
    With a bad enough (or just unfortunate) codebase or technology choices, every build could easily turn into a full build. I care about cold build and cold restart times exactly for this reason.
- selfhoster11 5y ago
  > I genuinely believe having fast builds is the most important part of the developer experience. Somewhere around a build taking more than 30 seconds is when bad things start to happen to my engagement loop. If I can keep it under 30, I can stay in flow the whole time. Other developers on the team have expressed similar tolerances. This, a thousand times. Anything after 30 seconds is where you start to lose your focus, and your work output suffers for it.

Ternari 5y ago

Your company sounds great. Are you hiring?

phnofive 5y ago

Please do elaborate on your take-home; in a profession with no formal credentials (i.e. no MSBE for SDEs), I don't mind putting a little skin in them game for the same purpose.

tharkun__ 5y ago
Well why I said that is because of all the discussions on HN about people hating leetcode, hating take homes hating... well just about any form of interview if I read it right. Now I am/have been on both sides of this. I happen to like take home for devs. I like it because it takes out some of the stress of interviewing. If done right. I have been advocating internally at my company for stripping down the take home test. Who wants to do a "this should take you 4-8 hours" test? Which nobody internally actually tried to do themselves in that timeframe. Nobody! Especially not if you have a job at the moment. And a family. But want to take advantage of the market and/or look for a better company. What do I look for in a take home? Not running code! I couldn't care less! I have never in my life run up a take home test someone sent in (backend). I look for code cleanliness, consistency, abstractions, DRY, WHY comments. If you send in something without any tests you are out. If you have a hundred tests to show 'you do tests', you are out. If you have 5 tests that are of awesome quality and show that you know what is worth testing and how to write tests that will survive a refactoring of the code and actually tell you that your refactoring didn't break anything I will hire you and pay you money to write a hundred of those tests when it actually matters. Maybe add a comment that you could write the same kind of tests for the rest of the code but your kid needed a good night song and the deadline for the test was up. I was hired on such a take home. My code deliberately did not run. I called out to external services that I did not bother to include in the take home test because it asked to solve the problem and I knew they used microservices. And business wise those things should've been handled in those other microservices and not the one I was writing. I also left out the database. Not worth even an h2 in pom.xml. They happened to use gradle. They didn't care I used maven. Still love them for it. Had the best interview ever. Loved the pros and cons discussion with my interviewer. Awesome guy. Now depending on what position you get hired for this might change. An architect position for example a whiteboarding session might be more appropriate. Just have a problem to solve (e.g. one of your own main use cases) and have them design it with you. Who cares if they come up with the same solution you did. It's about the discussion. The pros and cons. The general attitude towards solving the problem. If they admit they don't have the answer to something off hand but its a 'googleable thing' they've just never had to solve before, that's fine!
- Osiris 5y ago
  We do take home tests and I find them valuable. We do, however ask them to host it somewhere to be used. 1) we want the time investment to be <4 hours 2) the test uses public APIs and is directly related to our work (crypto) 3) we had the team (mine) do the test themselves before making it official 4) we also are looking for things like tests, thoughtful architecture, etc. It's hard for a junior dev to fake well structured and organized code because it takes experience and thought to do it that way. If I were interviewing I would much prefer a take home rather than an in person leetcode interview. I also don't mind in person pair programming (like help us fix the bug in this code or whatever).
  - disgruntledphd2 5y ago
    > If I were interviewing I would much prefer a take home rather than an in person leetcode interview. It's tricky, because this can vary within one person across time. For example, in my area (DS), i think that the take-home gives the best signal for the actual work (as long as its well scoped). But, as a parent of a small child, I'd much prefer to just do in-person tests/discussions as it takes less time away from my family. So it's hard, and whatever you choose will lead to you missing good candidates. Unfortunately, as in many areas, there's no silver bullet.
- stavros 5y ago
  Exactly agreed. We implemented such a take-home as well, hopefully it takes candidates 1-2 hours to complete, but we need more data on that. You're scored on various well-defined areas, and it is, as you say, to show us that you know how to organize code. We don't even try to run it (though CI should pass).

randmeerkat 5y ago

You lost me at monorepo. That might work at a very small scale, but past that monorepos create more problems than they solve.

delta1 5y ago
Like google scale?
- randmeerkat 5y ago
  Sure, if you want to write your own version control system and also your own computer language to support it.
  - delta1 5y ago
    There are many other examples of large scale monorepos. They in no way require custom version control nor programming language.
    - randmeerkat 5y ago
      What are the other examples you’re referencing?
hsn915 5y ago
like what?
- randmeerkat 5y ago
  Like versioning services, deployment of the code base, breaking out new microservices, transitioning to any container based deployment solution. Monorepos aren’t just a nightmare for release management, they’re a nightmare for any sort of single responsibility oriented architecture. I’m really exhausted of “senior devs” that believe they’re architects championing monorepos just because they’re too lazy to change minor versions in a repo.

bob1029 5y ago

This sounds like our shop. One big fat monorepo, every merge to master must satisfy a checkbuild. Speed is a big deal for us too. The entire thing can be built from clean in ~3 minutes by GH action workers. We buy our developers threadripper workstations, so local rebuild times of the solution during typical development iterations are closer to 15 seconds. We are much more interested in developer ergonomics than with simulating prod environment. I genuinely believe having fast builds is the most important part of the developer experience. Somewhere around a build taking more than 30 seconds is when bad things start to happen to my engagement loop. If I can keep it under 30, I can stay in flow the whole time. Other developers on the team have expressed similar tolerances.

rightbyte 5y ago
I don't get the initial short build time thing. My prior work project took 15h too build from clean - obviously a nightmare. It was due to bad layout of dependencies and a lot of generation. So it is still important to not mess up. I care mostly about cached build time. A clean build time of eg. 1h does not bother me.
- selfhoster11 5y ago
  With a bad enough (or just unfortunate) codebase or technology choices, every build could easily turn into a full build. I care about cold build and cold restart times exactly for this reason.
selfhoster11 5y ago
> I genuinely believe having fast builds is the most important part of the developer experience. Somewhere around a build taking more than 30 seconds is when bad things start to happen to my engagement loop. If I can keep it under 30, I can stay in flow the whole time. Other developers on the team have expressed similar tolerances. This, a thousand times. Anything after 30 seconds is where you start to lose your focus, and your work output suffers for it.