3 ms·

There are a few options I can see: The primary way is to pay more. Technical skills are in a (global) marketplace, and right now it is a sellers marketplace. I

by jen20 6y ago

There are a few options I can see: The primary way is to pay more. Technical skills are in a (global) marketplace, and right now it is a sellers marketplace. If demand outstrips supply, this is the natural path. That said, if you can’t match the pay of the top bidders, you need to provide an environment they can’t or won’t, and how you go about this is specific to individual target developers. Some things I might consider being worth accepting a lower offer - the range of things others will consider are different, and I’ll be interested to read the other responses to this thread as they come up! - Be up front about pay and benefits. The number of times I’ve seen “competitive market rates!!11!!” in an ad only to discover they are absolutely nothing of the sort is simply infuriating, and I won’t engage with any recruiter that won’t give an up front range, and concrete measures of how to be at the top end of it. - Don’t use third-party recruiters. This is variable by country, but in the UK recruiters have a _terrible_ reputation. I’ve personally blocked over 100 of them by email and phone, and as a rule do not respond to them. - Don’t do “dog and pony show” interviews. If I have to write code on a whiteboard, or even in an editor live on a call, or look at an extensive take-home test (anything more than a 15-30 minute task), I’m highly likely to pass for anything except an a top shelf package at a company I’m highly motivated to work for. - Eliminate barriers to work being done. I can’t count the number of places I’ve seen where developers spend more time in irrelevant meetings designed to boost the sense of importance of a B team middle manager than pairing, or even getting individual tasks done. - Have an altruistic mission, or at least one aligned with the ethics of the candidate. If your business reduces to “invade privacy to sell ads”, I’d be unlikely to be interested even at top end rates. If it’s something less sociopathic, it may be worth a second look even if the explicitly stated salary range is lower. - Don’t attempt to control employee behaviour outside of working hours. This includes open source contributions without getting tied up with legal review, and over-reaching IP agreements. - Don’t expect me to go to an office, and have top notch IT support for remote employees, whether that’s VPNs that work without screwing about, or a BeyondCorp-type model. Others may want to go to an office, and it’s important to support both models. The days of “you must be in the office weekdays from 9-5” are gone though.

bennyelv 6y ago
>Don’t do “dog and pony show” interviews. If I have to write code on a whiteboard, or even in an editor live on a call, or look at an extensive take-home test (anything more than a 15-30 minute task), I’m highly likely to pass for anything except an a top shelf package at a company I’m highly motivated to work for. I'm always interested in this point of view, because I understand why candidates don't like it but as a hiring manager myself I also know that there's a fairly large proportion of candidates who look good on paper but can't actually do the most fundamental thing that a developer needs to do: solve an abstract problem with code. What's the alternative to filter those people out?
- jen20 6y ago
  That largely is a case-by-case decision I think. Perhaps via open source work, perhaps via a short take-home assignment. Since work in most of the US is “at will”, it’s an easy problem to solve if it turns out someone has exaggerated their abilities. My problem is not with _any_ coding to be clear. It’s mostly the Google gotcha questions designed to make the interviewer look smart, and where the primary takeaway is that the candidate has or has not seen that question before. Things like “let’s refactor this thing collaboratively and discuss trade offs” are fine - and discussing trade-offs gives you far more of a feel for a senior engineer than whether they can implement some trivially Googleable algorithm for which “use a library” is almost certainly the actual correct answer. This is the style of question I personally use when doing technical interviewing.
  - veets 6y ago
    I always find this argument of "Google gotcha" questions weak. I agree 100% that tricky questions around dynamic programming, linked lists, etc. are a terrible choice. However, I think a lot of these questions do a good job of measuring how well the candidate understands basic data structures. It amazes me how many "seasoned engineers" do not understand when to use things like hash sets/maps (just look at the monthly blog posts about how you shouldn't use `in` in Python on lists because it is O(n)!! It blows my mind this is blog-post worthy). Also, I would far rather have a company not hire me because I failed a programming assessment than have them hire me and then fire me a week later because they were finally able to assess my skills.

by jen20 6y ago

bennyelv 6y ago

>Don’t do “dog and pony show” interviews. If I have to write code on a whiteboard, or even in an editor live on a call, or look at an extensive take-home test (anything more than a 15-30 minute task), I’m highly likely to pass for anything except an a top shelf package at a company I’m highly motivated to work for. I'm always interested in this point of view, because I understand why candidates don't like it but as a hiring manager myself I also know that there's a fairly large proportion of candidates who look good on paper but can't actually do the most fundamental thing that a developer needs to do: solve an abstract problem with code. What's the alternative to filter those people out?

jen20 6y ago
That largely is a case-by-case decision I think. Perhaps via open source work, perhaps via a short take-home assignment. Since work in most of the US is “at will”, it’s an easy problem to solve if it turns out someone has exaggerated their abilities. My problem is not with _any_ coding to be clear. It’s mostly the Google gotcha questions designed to make the interviewer look smart, and where the primary takeaway is that the candidate has or has not seen that question before. Things like “let’s refactor this thing collaboratively and discuss trade offs” are fine - and discussing trade-offs gives you far more of a feel for a senior engineer than whether they can implement some trivially Googleable algorithm for which “use a library” is almost certainly the actual correct answer. This is the style of question I personally use when doing technical interviewing.
- veets 6y ago
  I always find this argument of "Google gotcha" questions weak. I agree 100% that tricky questions around dynamic programming, linked lists, etc. are a terrible choice. However, I think a lot of these questions do a good job of measuring how well the candidate understands basic data structures. It amazes me how many "seasoned engineers" do not understand when to use things like hash sets/maps (just look at the monthly blog posts about how you shouldn't use `in` in Python on lists because it is O(n)!! It blows my mind this is blog-post worthy). Also, I would far rather have a company not hire me because I failed a programming assessment than have them hire me and then fire me a week later because they were finally able to assess my skills.