4 ms·

Nobody can help unless you show us your actual ads, your company site etc. There could me a million little signals that are putting people off. You've also not

Nobody can help unless you show us your actual ads, your company site etc. There could me a million little signals that are putting people off. You've also not said what your pipeline looks like - is there nobody coming in at the top? Or are the "great people" not as great as you think? Or the "really deep knowledge of the platform" is in fact less reasonable or badly paid than you think? If you're stuck, find a good recruiter and pay them properly. They can end-run around whatever the problem is, at least temporarily and give you informed, discreet feedback on how to fix it.

throw1138 4y ago
This is a throwaway because I'm just an engineer on the team wondering if there's something obvious we're doing wrong, and I don't imagine this would be considered desirable attention by management. Would posting a job ad on AskHN requesting feedback be acceptable? I ask because I'd have expected to see it a bunch if it were. @dang would be very appreciative of your word one way or another. Thanks mattbee.
- deleted 4y ago
  [deleted]
- mattbee 4y ago
  Ohhhh OK. I'd say don't post your actual ad because we will find you and give you more help than you wanted ;) Like maybe your team page is all white men, or your defence contracts are very prominent, or your CEO is a public dong. It's a bit of a yellow flag that you don't feel you can go to your managers with this to help fix a team you're obviously invested in? But here's two tips that you might be able to implement or influence by yourself: 1) Treat incoming candidates like GOLD. Respond to them within hours, same day where at all possible. Make decisions really fast, schedule interviews within 1-2 days, drop other things to make that happen. Have future managers & engineers communicate directly, lightly backed up by HR if you have that function (and you trust them). Keep. It. Moving. Make it clear their time is more valuable than yours. 2) Document the whole interview process up-front, put it prominently on your ads, specify the damned salary, and stick to your word the whole way. If you execute on both of these points, the FAANGs will not be able to come close in a really critical part of the process. They will be unclear about what happens next, who you're meeting, how important it is, maybe it will be a week, maybe it will be 12 weeks, who knows. But they got the prestige and the big bucks, and candidates will put up with a lot for that. (fwiw, I co-designed careers.bytemark.co.uk/full-process for most of the above reasons, and my current role went from introductory chat->3 interviews->contract signed in about 10 days flat - I like fast recruitment!).
  - pcthrowaway 4y ago
    > careers.bytemark.co.uk/full-process This is really cool!
  - Beltalowda 4y ago
    > Have future managers & engineers communicate directly, lightly backed up by HR if you have that function (and you trust them). Keep. It. Moving. Make it clear their time is more valuable than yours. Yeah, this. Not that I dislike recruiters or HR folks or don't appreciate the work they do, but with someone with engineering experience I can talk to them on an equal level and don't need to "dumb down" describing my skills or past experiences, and I can usually be a lot more straightforward and/or have an actual conversation instead of reading my CV out loud, which is what a lot of initial screenings are like (it's okay to use the CV as a starting point for the conversation). Talking to an engineer is also a signal I'm being taken serious as a candidate. I get that people use recruiters for an initial screen, but if it's "recruiter → another recruiter → HR person → coding test → finally I talk to a damn engineer (or engineering lead)" then that's a bit of a turn-off. At this point you're expecting me to spend time to "prove" my technical skills and I don't even know if I want to work for you because I have no idea what your engineering is like beyond the buzzwords your HR people dropped (which is very little information). If you've got more candidates than you know what to do with then that's fine, but if not... Using a recruiter for the initial (short) screening is fine to go through some basic preconditions from both sides, but the second person should really be an engineering lead if you're desperate for people IMHO. If you do insist on a code test and you intent on hiring the person if nothing strange comes falling out then say so. A lot of times I have the impression these things are shotgunned to a bunch of candidates.
  - bombcar 4y ago
    1) Treat incoming candidates like GOLD. Respond to them within hours, same day where at all possible. This is a huge point and something to work on. Act quickly and work out as many things in advance as you can. Don't be like unnamed company X who kept changing interview times and stretching it out so the candidate just took the offer from unnamed large company Y instead. If you get some nibbles on your pipeline treat them quite fast, and note where they drop off. Likely for the process you have the salary is too low, and people skip out to find the same money easier or more money at the same difficulty.
lostdog 4y ago
Yeah, the real answer is "something is less good than you are describing." Ask a senior engineer you've worked with in the past to take a look at your job posting and give you some honest feedback about what the problem is. There are yellow flags in your post, but it's unclear whether they are problems without details. For example: > the work requires a reasonably deep understanding of the underlying platforms which a lot of people seem to dislike. Why? > I'm wondering if the work being a higher percentage non-code is what's causing us trouble Probably. > Benefits and salary are good Are you sure? Plus, where are people dropping out of your pipeline? Is it early, suggesting that the job posting isn't great, or is it later, so part of the discussion process could be bad?
- b112 4y ago
  > the work requires a reasonably deep understanding of the underlying platforms which a lot of people seem to dislike. Why? Willing to bet the 'dislike' is "we have lots of mismashed, disorganized stacks, and expect seniors to have 20 years experience with all of them." coupled with "Even though some tools/stacks/etc have only been around 3 years." And... even though a senior can pick up a stack in a few days, the expectation is to find someone already skilled. .... Here's the truth. When I walk onto a new jobsite, I typically don't even know the tech. I've worked for EDA companies, government departments, startups, geospatial corps, all sorts of new and antiquated stacks and tech. I'm a senior, and I can walk in, and become the subject expert extremely fast. I do so all the time, it's why people hire me. That's what being an actual senior means. Loads of market experience, which makes that learning curve flatten. $5 says the 'dislike' is an expectation that stuff can't be learned fast. I'd scoff.
  - geekbird 4y ago
    Seriously. I've been doing Linux Systems work for over 20 years. I've written code at one level or another on over 15 languages (scripting, macro and compiled) plus various forms of markdown. 90% of it I learned on the job, even on the fly. I regularly go in to a place ostensibly for one thing, and end up their SME on something else. Do I remember all the details of every language and stack that I've touched? Hell no! But there are only so many ways to do a for loop or if-then set up. There are only a few flavors of regex out there. Anything more I just look it up. Part of being a senior is knowing what to look up. What makes me a senior is my ability to learn on the fly, then become an SME, on whatever obscure stack you have. I will never know all of it coming in - there's just too much stuff out there. But there's very little that is so bad that I can't work with it in a few weeks. But I've been rejected from jobs as "not technical enough" because I didn't have recent, full time, on the tip of my brain, coding to the algorithm and obscure function level in their preferred language "X". It just meant I hadn't coded in "X" in the last month. They though the fact that I didn't do obscure fanciness without looking things up meant I didn't know anything. I wanted to scream and say "No, damnit, I just haven't coded in that for two years, I don't have an eidetic memory." This is part of why I hate whiteboards and take home crap. I do poorly at them, then get lowballed by smug jerks who think that defines what I know and have done.

throw1138 4y ago

This is a throwaway because I'm just an engineer on the team wondering if there's something obvious we're doing wrong, and I don't imagine this would be considered desirable attention by management. Would posting a job ad on AskHN requesting feedback be acceptable? I ask because I'd have expected to see it a bunch if it were. @dang would be very appreciative of your word one way or another. Thanks mattbee.

deleted 4y ago
[deleted]
mattbee 4y ago
Ohhhh OK. I'd say don't post your actual ad because we will find you and give you more help than you wanted ;) Like maybe your team page is all white men, or your defence contracts are very prominent, or your CEO is a public dong. It's a bit of a yellow flag that you don't feel you can go to your managers with this to help fix a team you're obviously invested in? But here's two tips that you might be able to implement or influence by yourself: 1) Treat incoming candidates like GOLD. Respond to them within hours, same day where at all possible. Make decisions really fast, schedule interviews within 1-2 days, drop other things to make that happen. Have future managers & engineers communicate directly, lightly backed up by HR if you have that function (and you trust them). Keep. It. Moving. Make it clear their time is more valuable than yours. 2) Document the whole interview process up-front, put it prominently on your ads, specify the damned salary, and stick to your word the whole way. If you execute on both of these points, the FAANGs will not be able to come close in a really critical part of the process. They will be unclear about what happens next, who you're meeting, how important it is, maybe it will be a week, maybe it will be 12 weeks, who knows. But they got the prestige and the big bucks, and candidates will put up with a lot for that. (fwiw, I co-designed careers.bytemark.co.uk/full-process for most of the above reasons, and my current role went from introductory chat->3 interviews->contract signed in about 10 days flat - I like fast recruitment!).
- pcthrowaway 4y ago
  > careers.bytemark.co.uk/full-process This is really cool!
- Beltalowda 4y ago
  > Have future managers & engineers communicate directly, lightly backed up by HR if you have that function (and you trust them). Keep. It. Moving. Make it clear their time is more valuable than yours. Yeah, this. Not that I dislike recruiters or HR folks or don't appreciate the work they do, but with someone with engineering experience I can talk to them on an equal level and don't need to "dumb down" describing my skills or past experiences, and I can usually be a lot more straightforward and/or have an actual conversation instead of reading my CV out loud, which is what a lot of initial screenings are like (it's okay to use the CV as a starting point for the conversation). Talking to an engineer is also a signal I'm being taken serious as a candidate. I get that people use recruiters for an initial screen, but if it's "recruiter → another recruiter → HR person → coding test → finally I talk to a damn engineer (or engineering lead)" then that's a bit of a turn-off. At this point you're expecting me to spend time to "prove" my technical skills and I don't even know if I want to work for you because I have no idea what your engineering is like beyond the buzzwords your HR people dropped (which is very little information). If you've got more candidates than you know what to do with then that's fine, but if not... Using a recruiter for the initial (short) screening is fine to go through some basic preconditions from both sides, but the second person should really be an engineering lead if you're desperate for people IMHO. If you do insist on a code test and you intent on hiring the person if nothing strange comes falling out then say so. A lot of times I have the impression these things are shotgunned to a bunch of candidates.
- bombcar 4y ago
  1) Treat incoming candidates like GOLD. Respond to them within hours, same day where at all possible. This is a huge point and something to work on. Act quickly and work out as many things in advance as you can. Don't be like unnamed company X who kept changing interview times and stretching it out so the candidate just took the offer from unnamed large company Y instead. If you get some nibbles on your pipeline treat them quite fast, and note where they drop off. Likely for the process you have the salary is too low, and people skip out to find the same money easier or more money at the same difficulty.

lostdog 4y ago

Yeah, the real answer is "something is less good than you are describing." Ask a senior engineer you've worked with in the past to take a look at your job posting and give you some honest feedback about what the problem is. There are yellow flags in your post, but it's unclear whether they are problems without details. For example: > the work requires a reasonably deep understanding of the underlying platforms which a lot of people seem to dislike. Why? > I'm wondering if the work being a higher percentage non-code is what's causing us trouble Probably. > Benefits and salary are good Are you sure? Plus, where are people dropping out of your pipeline? Is it early, suggesting that the job posting isn't great, or is it later, so part of the discussion process could be bad?

b112 4y ago
> the work requires a reasonably deep understanding of the underlying platforms which a lot of people seem to dislike. Why? Willing to bet the 'dislike' is "we have lots of mismashed, disorganized stacks, and expect seniors to have 20 years experience with all of them." coupled with "Even though some tools/stacks/etc have only been around 3 years." And... even though a senior can pick up a stack in a few days, the expectation is to find someone already skilled. .... Here's the truth. When I walk onto a new jobsite, I typically don't even know the tech. I've worked for EDA companies, government departments, startups, geospatial corps, all sorts of new and antiquated stacks and tech. I'm a senior, and I can walk in, and become the subject expert extremely fast. I do so all the time, it's why people hire me. That's what being an actual senior means. Loads of market experience, which makes that learning curve flatten. $5 says the 'dislike' is an expectation that stuff can't be learned fast. I'd scoff.
- geekbird 4y ago
  Seriously. I've been doing Linux Systems work for over 20 years. I've written code at one level or another on over 15 languages (scripting, macro and compiled) plus various forms of markdown. 90% of it I learned on the job, even on the fly. I regularly go in to a place ostensibly for one thing, and end up their SME on something else. Do I remember all the details of every language and stack that I've touched? Hell no! But there are only so many ways to do a for loop or if-then set up. There are only a few flavors of regex out there. Anything more I just look it up. Part of being a senior is knowing what to look up. What makes me a senior is my ability to learn on the fly, then become an SME, on whatever obscure stack you have. I will never know all of it coming in - there's just too much stuff out there. But there's very little that is so bad that I can't work with it in a few weeks. But I've been rejected from jobs as "not technical enough" because I didn't have recent, full time, on the tip of my brain, coding to the algorithm and obscure function level in their preferred language "X". It just meant I hadn't coded in "X" in the last month. They though the fact that I didn't do obscure fanciness without looking things up meant I didn't know anything. I wanted to scream and say "No, damnit, I just haven't coded in that for two years, I don't have an eidetic memory." This is part of why I hate whiteboards and take home crap. I do poorly at them, then get lowballed by smug jerks who think that defines what I know and have done.