9 ms·

The “hopeless list”, no. 3: “If you run into an asshole in the morning, you ran into an asshole. If you run into assholes all day, you’re the asshole.” This p

The “hopeless list”, no. 3: “If you run into an asshole in the morning, you ran into an asshole. If you run into assholes all day, you’re the asshole.” This pretty much sums up my impression of these hiring managers that crank the bar sky-high: they are assholes through-and-through, and are full of shit to boot. If you crank the bar sky-high, all you will get are two kinds of people: those that interview/test well, but fail at the job, or those who can do both but will put a crater a mile wide into your payroll due to their high demand garnering an equally high paycheque. Anyone who isn’t quite at nosebleed levels of competency can grow into their roles and skill sets. Yes, they won’t be able to hit the ground running, and yes, they will have a higher than comfortable drag-to-thrust ratio, BUT THAT CLEARS UP IN TIME, WITH SUFFICIENT GUIDANCE AND MENTORSHIP.

scarface74 7y ago
But while they are getting guidance and mentorship, they are not being a productive member of the team, taking time away from experienced developers and as soon as they level up they will change companies and the next company didn’t have to invest training time. I know everyone has to start somewhere but from the company’s perspective, hiring a junior developer doesn’t make sense.
- LordFast 7y ago
  Another perspective to consider as well: while you are spending the time investing into and training people who needs the training and investment, your competitors are throwing money luring away the ones you have already trained, and leaving you in the dust in terms of velocity. Turtles all the way down. Once a game shifts into zero-sum, it's not gonna stop getting played until it collapses. Normally, I would say to avoid entering into any zero-sum games. But the world has made a sharp turn towards zero-sum over the past 5 years, so that advice has rapidly become impractical in today's climate.
  - Apocryphon 7y ago
    Not every business needs to be aiming for hyper-growth. Perhaps some tech startups can take a breather and reconsider whether they need to be engaged in the same zero-sum game as everyone else. Because grow at all costs doesn’t just harm untrained juniors- it also leads to corner cutting and short-term thinking that could bite the business in the back later on.
    - LordFast 7y ago
      I agree with you, but from what I've seen there's been a steady and increasing stream of pressure from the capital side of things. Wisdom shall lead again at some point, but I don't clearly see when. Threads like this one though are a promising sign.
    - scarface74 7y ago
      By definition if you are a VC backend startup, you are expected to concentrate on “hyper growth”.
  - no_wizard 7y ago
    Or is it? I think this ignores the human psychology factors. Like actually following through with being loyal to employees, training as a benefit etc. Also if you are going to lose employees because you can’t match competitive salaries than i would say you are losing them if all other things are equal. In another words this greatly oversimplified version of events here only allows for you to come to that conclusion and dismisses how an organization could adopt different practices, values and foster organizational culture that combats these issues differently which I think training is an essential component. I actually think this is a good argument for licensure like civil engineers etc have to have, because one thing it mandates is required training hours (among other reasons I won’t diverge into here for the sake of staying on topic) You can debate what that should look like and I encourage that but I see little downside to forcing employers to acknowledge that all employees may need some time just to train on new things and different concepts away from the day to day work. I know this is a little bit of a tangent here but it’s something I see so often at every level of an engineers career path yet organizations so rarely set aside adequate time for it.
    - scarface74 7y ago
      When you are early in your career, it’s quite easy that within two or three years your market rate can easily go up 20-30%, but your HR policies don’t allow more than a 5% raise. Why wouldn’t a developer leave for more money and more learning opportunities?
      - no_wizard 7y ago
        1. Not saying they should or shouldn’t and as I noted if you can’t match salary and all other things are equal you may as well take the raise. 2. If that’s HR policy and you request for an exception and it’s denied, that may be a sign to start asking more questions. 3. You’re assuming that’s HR policy. Again, example dictates you have one option without actually thinking through how an organization could position themselves differently. Of couse salary is a component and rightly so, but at a certain point it’s just not everything Think of it this way: lifestyle, ancillary benefits, “perks” etc can be all valid reasons to stay a place that treats you well and displays real loyalty (which is often displayed in more generous long term planning like big 401K contributions and fully paid health insurance for the family, open source software time etc). Can’t say I would just arbitrarily leave that for an extra 20% because that 20% can be easily eaten in other ways. Not to mention transparently knowing that your job won’t evaporate if the economy gets soft is a win. All this salary gloating is fine until that happens. 1999-2001 was not a fun time to be in the upper band taking pay cuts Let’s not grossly oversimplify this. I’m never going to say don’t maximize your value, you should, I’m saying there is more than one (salary) way of doing that. FAANG or not. Oh and one dirty secret FAANGS don’t tell you? They happily underpay on salary once you’re in, or freeze you into a specific department etc. it’s not all roses.
  - rekabis 7y ago
    >while you are spending the time investing into and training people who needs the training and investment, your competitors are throwing money luring away the ones you have already trained That is a zero-sum attitude that does not hold up when a company does other things well. If you are training your employees, you are likely to be doing the other things that help retain employees (https://www.bayshorestaffing.com/images/uploads/Blog_Image.jpg https://www.bayshorestaffing.com/images/uploads/Blog_Image.j...). And if you are focusing on and actually delivering all ten of those benefits, employees are extremely unlikely to be jumping ship unless they are either a poor employee or have poor character (which you don’t want anyhow), or the competition is paying not only well above market rate, but well above your rates. Which means that they are now at a strategic disadvantage because an inordinate amount of funding needs to be diverted to payroll - much more so than in a company like yours. Any company can make an end run around zero-sum thinking by fully and honestly employing those ten benefits. Employees can and will rise to the occasion, bringing a competitive advantage to your company that is well in excess to their numbers.
- irq11 7y ago
  ” I know everyone has to start somewhere but from the company’s perspective, hiring a junior developer doesn’t make sense.” When did “not able to solve leetcode-nuclear puzzles while singing and tapdancing backwards”, become “junior developer”? The OP is talking about “sky-high” levels of (interview) competency, and you immediately jumped to the conclusion that anything less must be juniors who need training to wipe their rears. I think I see the problem in this field.
  - scarface74 7y ago
    Seeing that in over 20 years and very successful track record of getting jobs quickly that I’ve never done leetCode or had an algorithm interview - how did you get that out of anything that I said? I’ve met “junior developers” who couldn’t translate simple business requirements into code. The stereotypical “developer” who couldn’t do FizzBuzz.
    - omar_a1 7y ago
      The technical interviews I've had are decidedly not fizzbuzz level problems. They're "implement new features in an unfamiliar codebase in 10 minutes while we watch closely and tell you that every line of code you start to write is the wrong approach."-problems.
    - irq11 7y ago
      ”Seeing that in over 20 years and very successful track record of getting jobs quickly that I’ve never done leetCode or had an algorithm interview - how did you get that out of anything that I said?” Well, first...you were replying directly to a post that was talking about whitebord/algorithm questions and how they’re out of control. On an article about same. So my answer is: ”because I bothered to read the post to which you were replying.” Regardless, if you haven’t done an algorithm interview in “over 20 years”, you either haven’t changed jobs, or you’ve had a unicorn career. Either way, you’re clearly not representative of the vast majority of devs. True or exaggerated, your experience is so exceptional that it isn’t worth discussing.
      - 7y ago
- a1369209993 7y ago
  If you're hiring new people because you need more people working on your current project, Fred Brooks would like to have a word with you.
  - watwut 7y ago
    It is completely reasonable to hire more people when you need more people on current project. Fred Brooks definitely did not said you can never add people to currently running projects or change them up. You dont have to stop the projects when people on them change jobs either.
  - scarface74 7y ago
    Your “current project” is the ongoing success of the company. Are you claiming that companies never grow or need new people?
  - edoceo 7y ago
    Fred is talking about adding folk to a late project
- fzeroracer 7y ago
  I'm really not sure where people got this idea that junior developers that are being mentored cannot contribute to the team. Are they going to contribute as much as a senior dev? No, but they can still contribute in significant ways. They can still fix bugs and find issues in your system, bring a fresh perspective on design and take ownership over smaller parts of the codebase. The reason why junior developers jump ship is because companies aren't willing to even promote people. So of course developers (of all levels!) are going to leave after 2-3 years when it's the best way to actually get paid and not taken advantage of by stupid CEOs that would rather have high turnover than a happy workforce.
  - TuringNYC 7y ago
    Career track is a great point. I’ve already seen two organizations that refuse to provide any structured job growth or career track — then they wonder why attrition is so high amongst top performers or why “knowledge keeps walking out the door.” One even hired McKinsey to analyze the issue. If they had given away the McKinsey fees as raises it would have solved the issues easily.
- no_wizard 7y ago
  In my experience a great way to hire and train juniors is to have them do tasks that need to be done but you can’t over allocate or reallocate an existing engineer for it. Like refactoring existing code. Why? The only guidance then a more senior engineer would need to give is during code review and where they may have questions. It’s a great way to get them familiar with the code base and train them up. I haven’t seen this be a productivity killer. Also, with the shocking frequency I’ve seen, code based need more tests. Have them write tests! That’s a fast way to get up to speed. One other point: senior engineers in one code base may have an uptick if a “junior” in another depending on existing quality, circumstances etc. I think organizations are lying to themselves that they can only hire seniors. It’s a myth. Just like 10x developers. I need hard data to be convinced otherwise not anecdotal evidence. All the hard data I’ve seen points in the opposite direction of any anecdotal information I’ve come across. There are so many volumes of books devoted to these topics alone that I think most ideas around developer productivity without the firm backing of numbers are mostly hand wavy and myths we tell our selves to feel better
  - watwut 7y ago
    We would have always seniors who are there already for some time to refactor the code. No reason to have it refactored by someone who does not know how to properly code yet and does not know what problems existing structures have or solve. Otherwise you are just switching one mess to another mess. We had juniors for easy new features, tests, anything that is small and isolated.
  - scarface74 7y ago
    How would a junior no what to refactor and not make it worse? In my experience it’s harder to refactor existing code than to start with green field development.
    - no_wizard 7y ago
      You give them tasks with frames of reference. Not all refactored are monsters. It does require some guidance though that’s kind of the point. These are just some things I’ve been apart of. I’ve gladly been apart of this before. You can as I said also have them write tests or as others noted have them write smaller features or other things in isolation. Also how green are we talking is another question entirely. Some tasks are better fit for people with maybe practical experience in another tech stack but need to get up to speed in a new language etc. My overall point which may not have been clear is that there is always a way to get an engineer up to speed without killing velocity. It’s a management failure to say you can’t hire junior engineers. It’s one thing to need someone that’s a domain expert, but often I see “senior engineer” === “No ramp time” and I think that’s just a lie management tells themselves to justify not coming up with a good on-ramp plan for new engineers
- Apocryphon 7y ago
  If you build a culture where you expect no loyalty, it will be a self-fulfilling prophecy. Sadly this culture now no longer applies to specific companies, but the industry- and perhaps the economy- as a whole.
  - tonyedgecombe 7y ago
    Definitely the economy as a whole, it started in the Thatcher/Reagan era when corporates starting shedding people. It's no surprise employees show no loyalty when their employers do exactly the same.
- wpietri 7y ago
  Sure, you can't invest a ton in mentoring employees if people don't actually want to keep working there. But one of the best ways to ensure programmers stay is to make sure they keep learning. And one of he best ways to make sure your senior people always have something new and interesting to tackle is having them mentor junior people to take over the things seniors are bored with.
  - scarface74 7y ago
    And why would they stay just to “keep learning” if they could both keep learning and make more money? Corporate America is infamous for HR policies where they will only give current employees a maximum percentage raise while hiring new people at market rates (salary compression and inversion). Even if you as a manager want to keep good developers who were juniors but have now leveled up, your hands are tied.
    - wpietri 7y ago
      As I said, it only works if people want to keep working there. Paying market rates is important for that. However, most of the people I know who start looking for another job don't do it because they suspect there's more money somewhere else. They do it because they've grown less happy with the job.
- notabee 7y ago
  If you consider a larger pool of available competent developers to hire as beneficial for companies (thus driving down wages), then it does make sense. But it requires long term planning and investment, which does not mesh with the short term profit over everything business model currently running the economy. Training is a cost that must be paid, and while both students and governments have been made to pay much of that cost for a while, that system may not function for much longer.
- james_s_tayler 7y ago
  There's plenty of work that doesn't require an experienced expensive senior level dev to do it. If you have no juniors you have to have your seniors doing that work. So, it makes sense somewhat.
philjohn 7y ago
You see, I've had the opposite experience whenever I've been looking for my next challenge. I've had recruiters talk to me at length about each of the people I'd be meeting in the on-site, their backgrounds, what they'd be covering. I've had ones give me broad strokes about why previous candidates were passed on. At the end of the day, it's not in their interest to bring too many people to an on-site who will fail spectacularly, because that means they're not doing their job properly. I may just be lucky.
- cushychicken 7y ago
  I'm reading a little between the lines of your comment, but two possible interpretations of your post are: 1) You've had the good fortune to work with good recruiters/HR reps, and 2) You're a qualified candidate for the role they're bringing you in for. I say that because of an HN comment I saw from a recruiter (maybe Aline Lerner? Don't remember) that they typically send in one unqualified candidate to interview for a role first, no matter what. That's because the hiring committee always - always - has an itchy trigger finger to reject the first candidate. I'd have to imagine that a recruiter worth their salt would learn this lesson as well; you don't get good at something like recruiting without learning similar hard lessons as the other good people in the field. Point being: the recruiter was trying to give you an idea of what to expect in your on-site, because they thought you were good, and they thought you'd be introduced at a point in the process where you could actually succeed. (The hiring committee having already gotten their itch to reject a candidate out of their collective system.)
  - philjohn 7y ago
    Good point - perhaps it's a little of column A, a little of column B.
biztos 7y ago
Many years ago I interviewed at a FAANG and the VP who interviewed me over a (fairly crappy, 30-minute) lunch was really a pain, enough so I didn't want to work for him. The feeling was mutual. Turned out he did 500 interviews a year. Five hundred. Unless that's your entire job, I don't see how you could come out of that without becoming an asshole.
- perl4ever 7y ago
  500 lunch interviews in a year seems like it's stretching it.
  - cameronbrown 7y ago
    Imagine how much weight you could gain doing that many lunch interviews.. yikes
- choppaface 7y ago
  At a previous employer, managers were expected to do 200 per quarter (typically for 2-2.5 of the most active quarters). We were told it's better than Twitter where engineers did a minimum of 8 per week (and, allegedly, managers did even more). From my own experience, that sort of load undeniably turns evaluators into assholes. I think the main problem is that to see any return on investment (i.e. a 'successful' interview) it takes about a 6-12 months assuming the person is hired. Having to do such a repetitive task with such a dearth of feedback I think will make anybody go crazy. That's not even considering any imbalance between time spent on recruiting versus time spent on strategy or other management tasks.

scarface74 7y ago

But while they are getting guidance and mentorship, they are not being a productive member of the team, taking time away from experienced developers and as soon as they level up they will change companies and the next company didn’t have to invest training time. I know everyone has to start somewhere but from the company’s perspective, hiring a junior developer doesn’t make sense.

LordFast 7y ago
Another perspective to consider as well: while you are spending the time investing into and training people who needs the training and investment, your competitors are throwing money luring away the ones you have already trained, and leaving you in the dust in terms of velocity. Turtles all the way down. Once a game shifts into zero-sum, it's not gonna stop getting played until it collapses. Normally, I would say to avoid entering into any zero-sum games. But the world has made a sharp turn towards zero-sum over the past 5 years, so that advice has rapidly become impractical in today's climate.
- Apocryphon 7y ago
  Not every business needs to be aiming for hyper-growth. Perhaps some tech startups can take a breather and reconsider whether they need to be engaged in the same zero-sum game as everyone else. Because grow at all costs doesn’t just harm untrained juniors- it also leads to corner cutting and short-term thinking that could bite the business in the back later on.
  - LordFast 7y ago
    I agree with you, but from what I've seen there's been a steady and increasing stream of pressure from the capital side of things. Wisdom shall lead again at some point, but I don't clearly see when. Threads like this one though are a promising sign.
  - scarface74 7y ago
    By definition if you are a VC backend startup, you are expected to concentrate on “hyper growth”.
- no_wizard 7y ago
  Or is it? I think this ignores the human psychology factors. Like actually following through with being loyal to employees, training as a benefit etc. Also if you are going to lose employees because you can’t match competitive salaries than i would say you are losing them if all other things are equal. In another words this greatly oversimplified version of events here only allows for you to come to that conclusion and dismisses how an organization could adopt different practices, values and foster organizational culture that combats these issues differently which I think training is an essential component. I actually think this is a good argument for licensure like civil engineers etc have to have, because one thing it mandates is required training hours (among other reasons I won’t diverge into here for the sake of staying on topic) You can debate what that should look like and I encourage that but I see little downside to forcing employers to acknowledge that all employees may need some time just to train on new things and different concepts away from the day to day work. I know this is a little bit of a tangent here but it’s something I see so often at every level of an engineers career path yet organizations so rarely set aside adequate time for it.
  - scarface74 7y ago
    When you are early in your career, it’s quite easy that within two or three years your market rate can easily go up 20-30%, but your HR policies don’t allow more than a 5% raise. Why wouldn’t a developer leave for more money and more learning opportunities?
    - no_wizard 7y ago
      1. Not saying they should or shouldn’t and as I noted if you can’t match salary and all other things are equal you may as well take the raise. 2. If that’s HR policy and you request for an exception and it’s denied, that may be a sign to start asking more questions. 3. You’re assuming that’s HR policy. Again, example dictates you have one option without actually thinking through how an organization could position themselves differently. Of couse salary is a component and rightly so, but at a certain point it’s just not everything Think of it this way: lifestyle, ancillary benefits, “perks” etc can be all valid reasons to stay a place that treats you well and displays real loyalty (which is often displayed in more generous long term planning like big 401K contributions and fully paid health insurance for the family, open source software time etc). Can’t say I would just arbitrarily leave that for an extra 20% because that 20% can be easily eaten in other ways. Not to mention transparently knowing that your job won’t evaporate if the economy gets soft is a win. All this salary gloating is fine until that happens. 1999-2001 was not a fun time to be in the upper band taking pay cuts Let’s not grossly oversimplify this. I’m never going to say don’t maximize your value, you should, I’m saying there is more than one (salary) way of doing that. FAANG or not. Oh and one dirty secret FAANGS don’t tell you? They happily underpay on salary once you’re in, or freeze you into a specific department etc. it’s not all roses.
- rekabis 7y ago
  >while you are spending the time investing into and training people who needs the training and investment, your competitors are throwing money luring away the ones you have already trained That is a zero-sum attitude that does not hold up when a company does other things well. If you are training your employees, you are likely to be doing the other things that help retain employees (https://www.bayshorestaffing.com/images/uploads/Blog_Image.jpg https://www.bayshorestaffing.com/images/uploads/Blog_Image.j...). And if you are focusing on and actually delivering all ten of those benefits, employees are extremely unlikely to be jumping ship unless they are either a poor employee or have poor character (which you don’t want anyhow), or the competition is paying not only well above market rate, but well above your rates. Which means that they are now at a strategic disadvantage because an inordinate amount of funding needs to be diverted to payroll - much more so than in a company like yours. Any company can make an end run around zero-sum thinking by fully and honestly employing those ten benefits. Employees can and will rise to the occasion, bringing a competitive advantage to your company that is well in excess to their numbers.
irq11 7y ago
” I know everyone has to start somewhere but from the company’s perspective, hiring a junior developer doesn’t make sense.” When did “not able to solve leetcode-nuclear puzzles while singing and tapdancing backwards”, become “junior developer”? The OP is talking about “sky-high” levels of (interview) competency, and you immediately jumped to the conclusion that anything less must be juniors who need training to wipe their rears. I think I see the problem in this field.
- scarface74 7y ago
  Seeing that in over 20 years and very successful track record of getting jobs quickly that I’ve never done leetCode or had an algorithm interview - how did you get that out of anything that I said? I’ve met “junior developers” who couldn’t translate simple business requirements into code. The stereotypical “developer” who couldn’t do FizzBuzz.
  - omar_a1 7y ago
    The technical interviews I've had are decidedly not fizzbuzz level problems. They're "implement new features in an unfamiliar codebase in 10 minutes while we watch closely and tell you that every line of code you start to write is the wrong approach."-problems.
  - irq11 7y ago
    ”Seeing that in over 20 years and very successful track record of getting jobs quickly that I’ve never done leetCode or had an algorithm interview - how did you get that out of anything that I said?” Well, first...you were replying directly to a post that was talking about whitebord/algorithm questions and how they’re out of control. On an article about same. So my answer is: ”because I bothered to read the post to which you were replying.” Regardless, if you haven’t done an algorithm interview in “over 20 years”, you either haven’t changed jobs, or you’ve had a unicorn career. Either way, you’re clearly not representative of the vast majority of devs. True or exaggerated, your experience is so exceptional that it isn’t worth discussing.
    - 7y ago
a1369209993 7y ago
If you're hiring new people because you need more people working on your current project, Fred Brooks would like to have a word with you.
- watwut 7y ago
  It is completely reasonable to hire more people when you need more people on current project. Fred Brooks definitely did not said you can never add people to currently running projects or change them up. You dont have to stop the projects when people on them change jobs either.
- scarface74 7y ago
  Your “current project” is the ongoing success of the company. Are you claiming that companies never grow or need new people?
- edoceo 7y ago
  Fred is talking about adding folk to a late project
fzeroracer 7y ago
I'm really not sure where people got this idea that junior developers that are being mentored cannot contribute to the team. Are they going to contribute as much as a senior dev? No, but they can still contribute in significant ways. They can still fix bugs and find issues in your system, bring a fresh perspective on design and take ownership over smaller parts of the codebase. The reason why junior developers jump ship is because companies aren't willing to even promote people. So of course developers (of all levels!) are going to leave after 2-3 years when it's the best way to actually get paid and not taken advantage of by stupid CEOs that would rather have high turnover than a happy workforce.
- TuringNYC 7y ago
  Career track is a great point. I’ve already seen two organizations that refuse to provide any structured job growth or career track — then they wonder why attrition is so high amongst top performers or why “knowledge keeps walking out the door.” One even hired McKinsey to analyze the issue. If they had given away the McKinsey fees as raises it would have solved the issues easily.
no_wizard 7y ago
In my experience a great way to hire and train juniors is to have them do tasks that need to be done but you can’t over allocate or reallocate an existing engineer for it. Like refactoring existing code. Why? The only guidance then a more senior engineer would need to give is during code review and where they may have questions. It’s a great way to get them familiar with the code base and train them up. I haven’t seen this be a productivity killer. Also, with the shocking frequency I’ve seen, code based need more tests. Have them write tests! That’s a fast way to get up to speed. One other point: senior engineers in one code base may have an uptick if a “junior” in another depending on existing quality, circumstances etc. I think organizations are lying to themselves that they can only hire seniors. It’s a myth. Just like 10x developers. I need hard data to be convinced otherwise not anecdotal evidence. All the hard data I’ve seen points in the opposite direction of any anecdotal information I’ve come across. There are so many volumes of books devoted to these topics alone that I think most ideas around developer productivity without the firm backing of numbers are mostly hand wavy and myths we tell our selves to feel better
- watwut 7y ago
  We would have always seniors who are there already for some time to refactor the code. No reason to have it refactored by someone who does not know how to properly code yet and does not know what problems existing structures have or solve. Otherwise you are just switching one mess to another mess. We had juniors for easy new features, tests, anything that is small and isolated.
- scarface74 7y ago
  How would a junior no what to refactor and not make it worse? In my experience it’s harder to refactor existing code than to start with green field development.
  - no_wizard 7y ago
    You give them tasks with frames of reference. Not all refactored are monsters. It does require some guidance though that’s kind of the point. These are just some things I’ve been apart of. I’ve gladly been apart of this before. You can as I said also have them write tests or as others noted have them write smaller features or other things in isolation. Also how green are we talking is another question entirely. Some tasks are better fit for people with maybe practical experience in another tech stack but need to get up to speed in a new language etc. My overall point which may not have been clear is that there is always a way to get an engineer up to speed without killing velocity. It’s a management failure to say you can’t hire junior engineers. It’s one thing to need someone that’s a domain expert, but often I see “senior engineer” === “No ramp time” and I think that’s just a lie management tells themselves to justify not coming up with a good on-ramp plan for new engineers
Apocryphon 7y ago
If you build a culture where you expect no loyalty, it will be a self-fulfilling prophecy. Sadly this culture now no longer applies to specific companies, but the industry- and perhaps the economy- as a whole.
- tonyedgecombe 7y ago
  Definitely the economy as a whole, it started in the Thatcher/Reagan era when corporates starting shedding people. It's no surprise employees show no loyalty when their employers do exactly the same.
wpietri 7y ago
Sure, you can't invest a ton in mentoring employees if people don't actually want to keep working there. But one of the best ways to ensure programmers stay is to make sure they keep learning. And one of he best ways to make sure your senior people always have something new and interesting to tackle is having them mentor junior people to take over the things seniors are bored with.
- scarface74 7y ago
  And why would they stay just to “keep learning” if they could both keep learning and make more money? Corporate America is infamous for HR policies where they will only give current employees a maximum percentage raise while hiring new people at market rates (salary compression and inversion). Even if you as a manager want to keep good developers who were juniors but have now leveled up, your hands are tied.
  - wpietri 7y ago
    As I said, it only works if people want to keep working there. Paying market rates is important for that. However, most of the people I know who start looking for another job don't do it because they suspect there's more money somewhere else. They do it because they've grown less happy with the job.
notabee 7y ago
If you consider a larger pool of available competent developers to hire as beneficial for companies (thus driving down wages), then it does make sense. But it requires long term planning and investment, which does not mesh with the short term profit over everything business model currently running the economy. Training is a cost that must be paid, and while both students and governments have been made to pay much of that cost for a while, that system may not function for much longer.
james_s_tayler 7y ago
There's plenty of work that doesn't require an experienced expensive senior level dev to do it. If you have no juniors you have to have your seniors doing that work. So, it makes sense somewhat.

philjohn 7y ago

You see, I've had the opposite experience whenever I've been looking for my next challenge. I've had recruiters talk to me at length about each of the people I'd be meeting in the on-site, their backgrounds, what they'd be covering. I've had ones give me broad strokes about why previous candidates were passed on. At the end of the day, it's not in their interest to bring too many people to an on-site who will fail spectacularly, because that means they're not doing their job properly. I may just be lucky.

cushychicken 7y ago
I'm reading a little between the lines of your comment, but two possible interpretations of your post are: 1) You've had the good fortune to work with good recruiters/HR reps, and 2) You're a qualified candidate for the role they're bringing you in for. I say that because of an HN comment I saw from a recruiter (maybe Aline Lerner? Don't remember) that they typically send in one unqualified candidate to interview for a role first, no matter what. That's because the hiring committee always - always - has an itchy trigger finger to reject the first candidate. I'd have to imagine that a recruiter worth their salt would learn this lesson as well; you don't get good at something like recruiting without learning similar hard lessons as the other good people in the field. Point being: the recruiter was trying to give you an idea of what to expect in your on-site, because they thought you were good, and they thought you'd be introduced at a point in the process where you could actually succeed. (The hiring committee having already gotten their itch to reject a candidate out of their collective system.)
- philjohn 7y ago
  Good point - perhaps it's a little of column A, a little of column B.

biztos 7y ago

Many years ago I interviewed at a FAANG and the VP who interviewed me over a (fairly crappy, 30-minute) lunch was really a pain, enough so I didn't want to work for him. The feeling was mutual. Turned out he did 500 interviews a year. Five hundred. Unless that's your entire job, I don't see how you could come out of that without becoming an asshole.

perl4ever 7y ago
500 lunch interviews in a year seems like it's stretching it.
- cameronbrown 7y ago
  Imagine how much weight you could gain doing that many lunch interviews.. yikes
choppaface 7y ago
At a previous employer, managers were expected to do 200 per quarter (typically for 2-2.5 of the most active quarters). We were told it's better than Twitter where engineers did a minimum of 8 per week (and, allegedly, managers did even more). From my own experience, that sort of load undeniably turns evaluators into assholes. I think the main problem is that to see any return on investment (i.e. a 'successful' interview) it takes about a 6-12 months assuming the person is hired. Having to do such a repetitive task with such a dearth of feedback I think will make anybody go crazy. That's not even considering any imbalance between time spent on recruiting versus time spent on strategy or other management tasks.