What’s happening is that companies want to completely remove risk from the hiring process.
In the real world, you cannot remove risk. You can manage it, but you cannot remove it. Asking candidates to go through 6 interviews before making a decision and not telling them when a decision will be made signals a risk adverse culture that cannot make decisions.
They'll miss most of the good talent if they're doing 6 interviews for a standard role. The candidates with skills and options will go elsewhere and you'll be left with the desperate dregs.
How? I have seen people with 25 years service (electrical engineer) walked out with zero notice. Unless you are unionized, you can be fired on the spot.
Increasing risk of liability for firing is real, as is increasing oversight of discrimination law. You can be fired on the spot for breaking company policy, or doing something illegal. Without more info, that’s what I might assume you saw. But getting fired for mildly low performance without notice is not normal, at least not among engineers in large companies, and assuming it’s not because a division or the company is being shuttered. Companies have to give people feedback and give them time to respond. Failure to do that can and sometimes does result in legal action compelling the company to prove the employee was failing and that the company did not unfairly discriminate even unknowingly, which is costly, difficult, and risky. Plus, most companies aren’t capricious with firing engineers, and are also aware that hiring is expensive and employee ROI can take time.
> result in legal action compelling the company to prove the employee was failing
The company doesn’t have to prove that the employee was failing. It’s perfectly legal for a company to fire an employee because they the employee likes the wrong football team.
The employee or people pursuing legal action on behalf of multiple employees has to prove that the company fires the employee(s) because they were a member of a protected class.
Assuming there are no incriminating emails stating that that was the reason, the only realistic way to do that is to show a pattern.
If an employee decides to sue, whether you had them on a documented performance improvement plan for 6 months or 6 days isn’t going to be the deciding factor.
> The company doesn’t have to prove that the employee was failing.
They do if the employee sues claiming age discrimination, for example. At least, they have to defend the accusation to show it’s not discrimination. When someone has been at the company for 25 years like in the parent’s example, and they get fired abruptly without notice for liking the wrong football team, it’s likely the stated reason is untrue and inviting a challenge.
> If an employee decides to sue, whether you had them on a documented performance improvement plan for 6 months or 6 days isn’t going to be the deciding factor.
It certainly helps show that the company isn’t discriminating arbitrarily, and gave the employee notice and a chance to improve the situation.
BTW actual legal action isn’t necessary for firing to be getting harder. The fear of legal action is all you need, and that is in fact going up.
>They do if the employee sues claiming age discrimination, for example. At least, they have to defend the accusation to show it’s not discrimination.
They don't have to show anything. The employee has to prove that it's age discrimination.
>When someone has been at the company for 25 years like in the parent’s example, and they get fired abruptly without notice for liking the wrong football team, it’s likely the stated reason is untrue and inviting a challenge.
Without a pattern of discrimination this isn't a problem. If there is pattern of discrimination then it is. However, if that's the case it doesn't matter how much documentation they have.
>It certainly helps show that the company isn’t discriminating arbitrarily, and gave the employee notice and a chance to improve the situation.
You can't discriminate arbitrarily. Discrimination in this context means firing someone because they are part of a protected class.
>gave the employee notice and a chance to improve the situation.
Whether you gave someone the chance to correct the situation or not isn't relevant.
>BTW actual legal action isn’t necessary for firing to be getting harder. The fear of legal action is all you need, and that is in fact going up.
"At the same time, FY2020 saw the lowest number of charges received from workers in more than two decades. The agency received 67,448 charges—continuing the steady downward trend since 2017 in the numbers of discrimination charges filed with the EEOC."
> The number of charges filed with the EEOC has gone down over the last 20 years
Yes that’s a compelling data point for decreasing legal actions (and it’s interesting, thanks for including it), but not all actions and not all fears end up in front of the EEOC, right? This data point alone is likely due to decreasing union membership over the last 20 years, but is also explained by the increasing prevalence of mandatory arbitration clauses. What it doesn’t explain is why HR departments nationwide are increasing efforts to educate employees about anti-harassment policies. If they are legally in the clear, why is that happening? Twenty or thirty years ago it was hardly a thing, today it’s the norm.
> They don’t have to show anything. The employee has to prove that it’s age discrimination.
You are right about the legal burden of proof in court, absolutely. Court isn’t the only possible outcome of a discrimination claim, though, and the one specific example you gave is a defense against a discrimination claim that would not hold up in court (firing a long-time employee for claiming to not like the right football team).
I agree with everything you’re saying about what is required in court, and what are the legal rights for all employers in the US, not just tech companies. That’s just not exactly what I was talking about.
Fire fast. Use that 90 day try out period. Contract-to-hire.
In the past I would never have been interested in a contract-to-hire. These days though if the company and role is right, and this an option to short-cut a ridiculous interview process, I might spring for it.
Just personally I would never accept an offer that was contract for hire and think it's downright insulting a suggestion. My family needs health insurance and the market has never been so cold that I'd be desperate enough to take such a garbage offer.
Nothing about contracting precludes having health insurance though? For the roles and situations I'm talking about this would all just be factored into the rates.
Even if they can just pay for health insurance out of pocket, they’d be switching plans twice, and each time they’d reset their deductible and possibly need to find a new doctor.
When I was an actuary we used to do “intern to hire” for unemployed recent grads, but I can’t imagine leaving a full time position for a contract-to-hire position. I think for me personally the opportunity would have to be really interesting and the comp upon converting to FTE would need to be at least double my previous comp (meaning the contracted rate would probably be something like 4x my implied hourly).
> Fire fast. Use that 90 day try out period. Contract-to-hire.
I've see that work before, but it was some time ago. The company also had a very large test department with separate management and kept to a strongly enforced waterfall-esque design routine.
Of course, it used to be a lot harder to ship out version 1.01 of the software.
I just assume it was a different world as this was in the days of US manufacturing, very limited set of software tools, high importance placed on domain knowledge as opposed to toolset, longer average stays at employer, lower wages for programmers. Probably not applicable to modern times.
The solution is to accept that shitty candidates can't always be filtered out and to have a probation period to remove them before they do too much damage to your codebase/morale.
It's a bit like the good-books/bad-movies phenomenon.
There's a quality-distribution of both books and films.
There are only so many good books. And a percentage of films end up poorly made.
Sufficiently low-quality books tend not to get made into films. The ones that succeed are notable --- there's nothing but upside.
A good book can be made into either a good or a bad film. If it's a good film, then yay, but if it's a bad film, people are aware of it (through the book's quality and popularity). This is a perception illusion called Berkson's Paradox. It's an illusion because what awareness fails to account for are all the bad films made from bad books.
In the interviewing / performance case, you have good vs. bad interviewees, and good vs. bad performers.
Someonehone who interviews poorly but performs well is a positive exception. Someon who interviews well and performs well meets expectations. It's the good interviewer/bad performer who stands out. But it's the poor-interviewer/poor-performer who is missed by this assessment.
I would also suspect that any filtering mechanism that cuts out the truly destructive people might well be either unacceptable or illegal at this point.
There's probably not a single one-size-fits-all solution - what works for FAANG and their millions of applicants is lunacy when you're a three-person startup, much like adopting Kubernetes to run an internal web app with half a dozen users. It probably starts with proper training in conducting interviews, a respect for candidates' time, a realistic appraisal of your needs and budget, and constant feedback-driven refinement of your process.
Do you have probation period where you work? i.e. if an employee doesn't live up to expectation, release with short notice? Where I am, a 3 year contract typically carries a 3 month probation period, and a 1 year contract carries a 1 month probation period.
The problem is management are often too busy or overwhelmed with other stuff to observe and provide feedback until someone's passed the probation period then releasing them becomes a bureaucratic nightmare - and when the new hire's not getting feedback, you can be sure not a lot of the rest of the team are.
Probation periods in the US are rare, especially for white collar positions like software engineers. Of course, that’s mostly because of at will employment where either side can choose to part ways at any time.
I don't think it's that at all. It's very easy to fire people in US. I think they are trying to hire cultists. The harder it is to get in the more people think they're special once they do and the less likely they are to leave.
I don't know if you've been through the firing process on either side, but after you go through a couple of dozen of these, and the hit to the morale/performance they entail, not to mention emotions involved, you tend to at least try to vet better to avoid such huge distractions in the future (a lose-lose for everyone involved!)
I left a hedgefund interview loop for this reason.
I finished the 7th on-site interview. After I left NYC and flew back home, they wanted a 8th ( phone screen ) interview because one the interviewers lost the results.
On the one hand, this space’s modus operandi is more data is always better.
On the other hand, they have to trade and make decisions in a fast paced environment with imperfect information.
funny same experience here. I interviewed for four months at a very select and under the radar fund. Once a week I would go in from 730 am to 9 am and speak with a member of the fund. I got all the way to the end, and in a bout of emotional torment, I turned the offer down. In hindsight, its one of the biggest regrets I have. Would have retired long ago
Why did you turn it down if I may ask? I’ve made the decision several times to go with lower paying offers because I ended up deciding there was more to life than just a paycheck.
Companies don't want to do job training anymore. Instead of a general background and attitude check, they need to know if the candidate has all of the individual skills that will be used on the job.
You say that and I’ve seen several companies in practice echo what you’re saying. However, I fail to understand why they don’t simply make better use of contracts and probationary periods to solve that specific problem.
Probationary periods could work but it's a coordination problem. Such periods are the norm in Europe (coz it's very hard to fire someone) but for an at-will place like the US, given that the industry doesn't really do probationary periods in general, any employer who starts doing it would be at a disadvantage.
The problem of a probationary period is that it pushes all the risk to the employee.
While I agree interviewing has gotten ridiculous with all the leetcoding and ten rounds of interviews and FAANG cargo-culting and whatnot, one small advantage - assuming I'm not desperate for a paycheck - is that it gives me, as a prospective employee, time to consider and withdraw my application if I see too many red flags or I just prefer the devil I know.
A short interview process with a probation period on the other hand is a big roll of the dice. Maybe I'm not able to ramp up on time, or make a silly mistake due to unfamiliarity with the codebase or underlying business logic. Maybe I don't get on with the team or manager. Maybe I'm going to be dumped into a doomed death march project on day 1. I could find myself unemployed a month later with an embarrassing gap in the resume. Perhaps on the other hand a better interview process (not longer, just have properly trained people and constantly improve the process with feedback) would save us all that pain.
In a world where short, high-risk interviews dominated, you could just go roll the dice again. It would be a negative signal (why is @foo interviewing after only 60 days?), but nowhere near as bad as “why is @foo still interviewing after 6 months in this job market?!”.
So the answer is to not spend the money at all? How much are you costing your company by putting candidates through 8 hours of interviews only to reject them. Rinse. Repeat.
All the while, productivity suffers as the remaining team falls further behind due to short-staffing and being pulled away from their real jobs to interview.
Professions mandate training minimums per year in order to maintain credentialled status. They're low, sure, but they at least create a need for ongoing professional education.
I literally said it isn't all about money. Most people leave because managers[0]
> In general, people leave their jobs because they don’t like their boss, don’t see opportunities for promotion or growth, or are offered a better gig (and often higher pay); these reasons have held steady for years.
And if it is about money, then this is called paying competitively.
But lastly, recognize that if everyone is training employees you're still not really losing out unless you're only hiring entry level employees. Sure, you might be training someone that leaves, but so does your competitor. But if you're only hiring junior engineers then you're probably doing something wrong that's much bigger.
Not necessarily. It's not easy to find a boss who you genuinely trust to consider your best interests, for example.
Out of curiosity, what sort of "non-monetary" benefits were you thinking about? There's usually not a reliable way to turn (small amounts of) money into the sorts of things that really build loyalty.
That works if this is a "one time game" (game theory) as opposed to a repeated game.
If an employer does do training, it means they'll probably continue to do more training over time, which helps the employee become more valuable.
If the employer doesn't do training, yes they may be able to allocate the training budget to salary, but they are not going to spend anything training you or letting you work on projects to increase your skills while you're there, unless they absolutely must.
I think people also have some human perception of how they're being treated, and prefer to work for people that invest in them.
Incredible that you're the first person I've seen mention a second-order effect in this conversation.
I don't know what it is but I feel like people have forgotten just like basic truths about how humans work. Maybe it's because managerialism has infected everything.
People change jobs at the drop of a hat for reasons that are well within companies' control. It's not like people want all that stress and hassle, they do it because they're incentivized to do so.
Sometimes. Other times they are just sampling what's out there to see what suits them the best, or playing the comp boost game until even their best face forward isn't able to garner a higher offer.
The former happens, I’m not convinced that it’s a common occurrence. Changing jobs is genuinely stressful, I don’t think people do it lightly. The latter is usually something the company could fix, but won’t.
Even still, it’s obvious that comp alone isn’t enough to retain employees. Even FAANG companies, which pay extremely well, have pretty low retention numbers. Facebook does best here, at an average job length of only 2.02 years. If comp was enough, people would stay there longer. This implies that people are changing jobs for reasons aside from “this other company will pay more”.
It’s not just about absolute comp. If google will pay you more, then maybe you leave facebook. That’s not because google pays more than facebook, just that it’s easier to get a “promotion” by taking a hire role elsewhere than it is to get an actual promotion. It doesn’t mean you don’t pay market wages, but it does mean you don’t pay that person their market wage.
That’s exactly something companies have under their control. If people are leaving because it is seen as the sure route to a promotion, then perhaps providing clear advancement opportunities internal would reduce this phenomenon and help keep your high performing talent.
The present employer and prospective employer have a different perspective on the individual. It's entirely possible, and indeed somewhat common, that individuals are hired to levels to new employers beyond what they would be able to justify promotion at their existing employer. The only way to eliminate this is prolonged and comprehensive interview process, which is what TFA is railing against.
I disagree that this is the only way to eliminate this problem. Companies could loosen promotion criteria to be more in line with what external candidates bring. Ultimately the cost of lost knowledge and backfilling is quite high, and could easily justify faster promotion cycles on a monetary basis alone.
Even if some of them genuinely get promoted before they’re ready and wash out, you’re not really that much worse off than if you’d lost them before. Besides, there’s always the risk that your new hire is unprepared too, which is a much harder thing to quantify.
That works when you're employing a bunch of Wordpress monkeys who do nothing all day but mess with CSS and install plugins. Not so much when you've got a mature SAAS product, parts of the system are tricky to work with, and stakeholders are breathing down your neck to implement new features so you don't have time to cross-train your teams.
Losing people who are experts within the domain of the software they're maintaining because you refuse to invest in them is going to cost you thousands of dollars... the only question is whether that's tens or hundreds times that amount... and in some cases it can cause you to lose your entire business.
I’m friends with a few “Wordpress monkeys,” as well as some people who “do nothing but mess with css all day.” That was extremely condescending and dismissive
Yep. Apprenticeships solved this problem in the past (and of course created many others). Actually it’s almost a fun little exercise in economics.
Basically there’s two types of efficiency, investment efficiency and allocative efficiency. (There may also be other types I don’t know about.)
Investment efficiency means people are incentivized to make positive-expected-value investments. Think about how people are incentivized to invest in their house, e.g. preventative maintenance, because if the expected value is positive then they will recoup that value when they sell the house. If you’re renting you don’t have this with respect to where you live - water damage or no, not really the renter’s problem. Investment efficiency is maximized by private property, where you know that no one will take your property without your consent.
Allocative efficiency means things go to whoever is willing/able to pay the most for them. Renting does have this property - if both of us want to rent a house, and I’m willing to pay more, in most cases I’ll end up getting the house. This is why gentrification can cause displacement - when wealthier people come into a city and are able to outbid the current renters, they win and the current renters lose. Allocative efficiency is maximized by auctions and things like them, where the good goes to whoever is willing to pay the most.
Bringing it back to your comment, job training isn’t worth it because our careers as programmers are dominated by allocative efficiency, not investment efficiency. If you can train a programmer create $50,000/year more value in general (i.e. it’s not training that would only be useful to your company), they can now get paid about that much more from any of your competitors, and you will have to pay them about that much more to stop them from leaving. So you gain nothing from giving them general-skills training.
Another way of solving this problem is with sectoral bargaining. If you have a sector-wide union, they can make all companies start training simultaneously, or assume some of the costs themselves. It’s a win-win for the industry and for the programmers, but it doesn’t happen nearly as much as it could because of that coordination problem.
So, in this hypothetical, the sector-wide union is preventing individuals who learn to create an additional $50K/yr in value from realizing the increase in pay which would otherwise accrue to them?
Yeah, or at least they aren’t able to capture the entire $50k/year in value. It kind of sounds bad but it’s a trade and there has to be something in it for both sides for it to happen.
In return for wasting training on employees that will leave for other companies, the company is getting its employees trained for free by other companies in the same way. In aggregate everyone wins because employees now get training.
The union is ensuring that no company can ruin it for everyone.
>Yep. Apprenticeships solved this problem in the past (and of course created many others). Actually it’s almost a fun little exercise in economics.
But it makes Reginald the investor angry that his ROI isn't exactly 20% each quarter, so they jettison apprenticeships and start cooking the books to make that possible.
This a hundred times over. I still remember in 2020 multiple places asking me "I see you've used .NET core, what *version* have you used?".
I had a kind of career crisis/breakdown, where I realised no one gave a shit about anything except my utility as a walking set of tech keywords. Accepting that it wasn't working for me was one of the best things I've done for my career.
It's not that I wanted them to love me for who I am as a human or anything.
It's that I firmly believe that there's more to software dev than just knowing a 'stack'. And even then, fair enough if they were curious about my .NET skills. But them asking about specific versions of .NET core really woke me up into how much of a commodity labourer they were trying to turn me into.
I think the bigger issue here is that this process has made it too random and dilutive of the candidate pool.
Many software engineers have accepted that they have to continually learn and will do so.
This process though, makes it impossible to know what to learn with an impossible random and unknown credential set. It's not the same as something like elevator attendants having an obsoleted skillset. It's a combination of not having time in a lifetime to even try to specialize in the random employer chosen skillset. When instead, employers should expect a good engineer to adapt quickly and employers should also commit to training staff.
> When instead, employers should expect a good engineer to adapt quickly and employers should also commit to training staff.
At the risk of suggesting you might be dating yourself, I think this is an outdated model. It's simply no longer realistic. I personally believe that having personal expectations of what my adversaries or those outside of my control "should" do will inevitably result in sadness on my part.
Corporations will aim to do what they must to increase profits (given, by definition). Any additional assumptions from that are liable to be faulty. Perhaps you are used to the times when they needed to train staff but that's simply a symptom of the circumstances as opposed to a duty.
Wasn't working. I was not in demand. I had to constantly reach out to people, just to get interviews at places I didn't really want to work for. And even then they'd usually reject me.
It was a wake up call that I was on the fast track to nowhere, and something had to change.
Ended up specialising in an industry and doing contract work. I'm not super successful yet, but there's a lot more interest in me. My work days are much less frustrating and I'm earning more.
Looks like I am on a similar path to you but you are a couple of steps ahead of me. Is there a place I can contact you with a few questions. I'd really appreciate it.
> where I realised no one gave a shit about anything except my utility as a walking set of tech keywords.
I am genuinely asking. Why is this objectionable?
Why do people find it so horrible that their labour is a commodity? To me that just tells me I should treat my labour like a merchant treats his goods. Always be checking the market to ensure you have something worth selling and while you might sign long term deals, periodically check for the best price to ensure you are getting it.
Why is it important to you that your employer view you as a person?
> Why is it important to you that your employer view you as a person?
Because we, generally speaking, are people and not robots ;)
That being said, I agree with your point : people would have less issues if they just felt happy about whatever makes logical sense. That's just way too hard to live by for most people.
The answer to a charitable interpretation of your question: most tech workers don't mind exchanging their labor for money, of course.
The answer to the question as written is...of course people want the entity that has outsize influence on 40 hours of their week to view them as a person instead of a mindless cog in a machine. People get treated better than cogs. Workers want their working hours to be as pleasant as possible, which is much more likely if your employer sees you as a person.
Not a mindless cog, but more as a merchant or even a labour supplying Lambda function. Just simply acknowledge that my employer and I are trading, the arrangement may end at any point for business reasons, and likely will end in a few years as our needs diverge.
Needs can include a nice workplace and you can negotiate specific details about what that means to you. I did not mean to say that it needs to be money.
A screwed hiring system is something most companies appear to be able to afford, given how many have one. When that same experience is flipped around to the employee, they can't afford it and it's a disaster. Few employees want zero job security and an expectation to be wading through the job hire swamp every couple of years.
You're not describing an employee, you're describing a consultant. Not everyone wants to be a consultant, particularly since most people don't get any training in it before they have responsibilities. If proper entrepreneurship was a subject at school, then maybe people would be willing to be their own business, but that's not what the system creates (or wants).
Fair, I can see why this might bother people. I don't think job security is a thing (career security perhaps), but I can get why its absence would be disturbing.
> expectation to be wading through the job hire swamp every couple of years.
The high level of turnover in this industry indicates that people at least tolerate it. The only people I know who make it 24 months in a role are chained by stock options.
But not all of us want to trade at that level of granularity. 'Do you have any mechanical engineering jobs' not 'Do you have any ceramic ball bearing housing design jobs'.
It’s not about humanism but mutual investment. I am investing my (very limited) time into your company to make you profit, you can invest in training me or helping me get up to speed on your specific needs.
But that is just trade and you can negotiate for those things. The employer benefits from getting you up to speed in the same way that someone might offer to send a truck to a store to get something delivered faster.
Because the buzzwords are never even coherent. "Puppet or Ansible" - well no, those are not even slightly the same thing, which one are you using? GCP or AWS or Azure - same thing. Which one are you using, not what are you imagining?
This would all be fine, but no one writes ads saying what they actually need or what they're trying to do.
Minimum four slice toaster with proven experience to deliver results and work autonomously in a fast-paced family kitchen. Ability to cook eggs a plus. Must comply with government product safety laws.
Because people have brains, can learn new things and technologists don't need experience with particular technology to be successful using or working on it.
Great response. This is why I ended up not becoming a teacher, despite everyone and their brother telling me that that's my calling (I still hear this at work constantly from people I train). I could have absolutely dedicated my life to something with low pay. What I would not do is accept an environment where I was not treated as a professional. As far as I can tell, the modern American education system treats its educators like crap and hamstrings them every step of the way. No thanks.
Because selecting candidates based on tech stack is almost universally the sign of incompetent tech management. Anybody who understands software, knows that intelligence and master of fundamentals trumps tech stack experience without exception. Linus Torvalds would unquestionably become a better Ruby on Rails developer within four weeks than 90% of people with 10 YoE in it.
Good organizations hire talented and bright people with mastery of CS and SWE fundamentals. Bad organizations think "oh we use Java, better hire Java programmers". Really bad organizations think "oh we use JUnit, Spring Boot and IntelliJ, better hire people with experience in JUnit, Spring Boot and IntelliJ"
One of the strongest signals of how good an engineering organization or a tech team is how few specific technologies they list in their job ads.
I've been hired as both a Ruby on Rails and Go developer without prior experience, and managed just fine in both case. Of course there's a bit of ramp-up time, but it's not that bad.
I'm not even an exceptionally talented programmer: just a competent one. Of course there are real differences between languages that matter, but at the end of the day ifs are ifs, ints are ints, functions are functions, etc.
That said: there are some reasonable scenarios when you want to hire someone with prior experience; for example as a first or second hire it's probably a good idea in most cases, or if you really need someone who can hit the ground running.
This makes a lot of sense. If a person has good fundamentals and understanding of engineering and CS, then they should be able to master any tech stack. I think in software development, we are in a weird position. In other engineering fields, it is expected to have a base line knowledge and the ability to learn into new processes. Most software companies seem to not want hire engineers who can do that.
Usually a language is not only a language, it is tools, paradigms, frameworks, libraries, conventions and many other bits and pieces one needs to know. So while there is some commonalities it usually takes time to get to a certain level of productivity, which is sometimes required sooner rather than later.
On the other hand, it would be nice to know the core languages in play. I have no interest in working in Java anymore, I avoid job listings for companies that would expect me to write Java. I don't want to have to go through recruiter screens etc before I can ask someone who will know what language I would be spending the next year of my life working with
I think that in the specific case of Stripe, they specifically mostly use Ruby (from answers I found online). I may be wrong, but I assume that not mentioning Ruby is a way to attract Python/Go/C/etc. developers that might otherwise think that since they don’t code in Ruby, they shouldn’t apply.
Not to pick on Stripe, but why not say this explicitly?
"We mainly use [language X], but you don't need experience in [language X] for us to consider your application" - this is a totally normal thing I've seen in many job postings.
Our solution to this is that we are clear that we're looking for Haskell programmers (as in that is what they should expect to do) but we have very modest requirements in terms of prior knowledge. I made sure to relay to HR that almost nothing is required in terms of prior knowledge (language-wise) and that we should expect to teach Haskell to people instead.
> Good organizations hire talented and bright people with mastery of CS and SWE fundamentals. Bad organizations think "oh we use Java, better hire Java programmers". Really bad organizations think "oh we use JUnit, Spring Boot and IntelliJ, better hire people with experience in JUnit, Spring Boot and IntelliJ"
You can't just go around telling people that: you are going to make hiring harder once everyone figures it out!
When you get a referral for a 10x and you're meeting at Blue Bottle you need an ice breaker; clueless community-college tier HR asking for versions of frameworks makes for an excellent one!
IMO, because the different .NET Core versions the commenter talks about aren’t that different and one can easily learn another version if they are already well-versed in one if them.
Also I am wondering: if management eventually decides (advised by external consultants of course) to switch to a newer version, then what do they plan to do? Hiring a new team?
I guess this is how I think of it. I enjoy the fruits of modern society, the airplanes and fast food and nice phones. But to make that happen, you need specialization, you need people know get really good at flying planes then just do that, and people who get good at making fast food and iphones and everything else. And inside that, you need people who specialize at every part of the supply chain, and what you end up with is people who have spent basically their whole lives fixing bugs in webservers used to sell analytics software to businesses etc. etc. and it becomes so abstract and you’re so disconnected from the feeling that you’re actually helping anyone or worth anything to society that it doesn’t really matter that intellectually you know the whole system would collapse if you don’t have people doing jobs like yours. And you should have friends outside of work, but many of us don’t really, at least not to the extent that way like, and even then work is literally most of your waking day most days of the week, and the knowledge that not even your coworkers or superiors or anyone else really cares about you in this grand societal project called modern civilization that you’re basically dedicating your life to maintaining, I can see how that would get to someone.
Dear god, that was beautiful but also depressing to read. I think this is it, exactly. I also think that it explains a large part of why so much software is bad. Specialization is a powerful thing, but without a unifying concept of the end goal, it's easy to become trapped by local maxima.
Because a Company expecting a "walking set of tech keywords" is a terrible deal for everyone but charlatans.
It is terrible for inexperienced developers eager to learn on the job as is common in other industries or was in ours in the past.
It's terrible you're an experienced developer that is able to pick technologies quickly, or just wants a proper work-life balance.
It is terrible for developers who are deeply familiar with the technology but expect to work with a team of professionals, rather than with "walking set of tech keywords".
"I am genuinely asking. Why is this objectionable?"
Software engineering is at a schizophrenic point where it is very hard to categorize in either of traditional "blue collar" vocational job (given people seem to be employed close to very little formal schooling) or as a "white collar" professional job (given some roles need a CS degree level understanding of the fundamentals).
Some roles are more the other than the other.
I'd say listing a very specific tech stack signals the employer is looking for "blue collar" "commoditized" labour.
White collar "professional" types probably feel treating their contribution as "commoditized labour" is a category error.
More than anything else software engineering most closely resembles a trade.
The majority of useful education comes from mentorship and on-the-job experience. Sure, you can get a formal education, and sure it helps, but it doesn't make you a useful software engineer. It just gives you a foundation to build upon through mentorship and experience.
In short, employers have some degree of power over you, and if you perceive people who wield power over you as wielding that power arbitrarily, that is nearly universally experienced as frustrating.
In GP's case, the arbitrariness originates from their potential employer not taking the effort to really evaluate GP's relevant skills in software engineering, but instead resorting to lazily ticking boxes on a checklist. And what's on the checklist isn't even particularly relevant.
What I imagine this does to GP's view of the world (based on what it would do to mine) is: "I believe I am competent because I've built up a set of subtle skills in software engineering over many years, and this is what I take pride in. But from an employment point of view, this is wasted time: I should instead have focused on optimizing the checklist (and I only found this out after years in the industry)."
> Why is this objectionable? [to reduce an employee to "utility as a walking set of tech keywords"]
> Why is it important to you that your employer view you as a person?
If what you mean is that it can be rewarding (intrinsically and extrinsically) to think about skill, craftsmanship, and other ways to make your labor a great value add, sure. Most of us benefit by thinking about that.
If you're really asking about why keywordification is a problem, well... keywordification of job roles indicates a way in which companies are quite possibly struggling to actually model the roles they're hiring for and identify what makes make an individual productive within them.
This happens on at least two levels:
1) Technological. Engineering decisions are sometimes "we have a specific problem, specific tech is the solution to our problem, therefore we need expertise in specific tech." In that case, the keywords regarding that tech are meaningful. But for non-trivial use cases, engineering problems are very, very rarely just that, they're commonly the aggregation of off-the-shelf + consideration of how to mix them with what tradeoffs + in-house custom solutions embedded in an organization attempting to understand and model its domain problems and fit/reshape all those solutions to those models. This is not exactly a keyword-driven process. Keywords represent the shallow end of the pool.
2) Human. While labor clearly is something bought and sold on the market, even from a point of view of a value system which is OK thinking of humans primarily as industrial inputs, it turns out that's a significantly leaky abstraction and most of us have all kinds of "compiler flags" or other inputs of our own that make us more or less productive. Some might consider this to be too warm and fuzzy; they might find it comforting that it can be approached from as a-humane and manipulative point of view as one might approach tweaking a database to get it to perform better: https://www.youtube.com/watch?v=HkFztAgK-8U
As for whether it's OK to think of humans primarily as inputs to any process on a moral level... like Terry Pratchett's character Granny Weatherwax said “Sin, young man, is when you treat people like things. Including yourself. That’s what sin is.” What are the consequences when social institutions consideration human beings primarily as inputs to institutional purposes? Generally, individual life, liberty, and pursuit of happiness become valued less, and individual suffering is more freely disregarded. Not super desirable under my value system. YMMV.
Is it possible the interviewer was asking this question because they wanted to get a sense of if you were aware of which version was being used? And as follow on, were you part of the decision to update or not update, and your thoughts on the trade offs in that kind of scenario? Just a possibility. Certainly if the recruiter is asking you that, that’s a bad sign (although recruiters are often very detached from the thinking of the teams they’re hiring for).
Yeah it could be a lazy way for an interviewer to check a requirements box that says ".NET Core 3.1 experience". But there is a chance that this is a way to determine whether any upcoming questions are relevant - like if you haven't used .NET Core 3.x, it's probably pointless to ask a question relating to some feature introduced in C# 8.0.
It's a contrived example of course (particularly if the end goal was just to check the "knows feature X from C# 8" box!) and I wasn't at those interviews so I've no way to know what their intent was. I'm occasionally on the other side of the interviewing table though so I'm just trying to reason through why this might come up. FWIW I hate the "what isn't in a linux inode" type questions, or situations designed to fuck with the interviewees.
The fact that they ask this question does show some bias but it may not be as much as you think. I can interview a person and be interested in finding out how much he/she fits like a glove for the tech stack and still put more focus on other qualities. Moreover, I expect a capable dev to not be too judgmental/unconfident and just answer something along the lines:
"No, I'm not familiar with this, but I have done [market themselves, mention relevant experience, ask relevant questions] and I'm confident I can get the job done"
I think this is a problem for the greater .NET community in general. I've participated in dozens of interviews where the "technical" interview is them asking obscure .NET or C# related questions like your some kind of technical glossary. What's worse is these questions are likely related to the one or two instances it's ever used in their entire codebase(s).
Asking what version of a tool was used, actually reveals a lot about the candidate. It's not about knowing if you know the exact same version as the company.
First probe is if the candidate doesn't have slightest clue what version they were using, that's a big red flag. This is more common than you would believe.
Second probe, candidate knows, but they only used a 25 year old version (also more common than you would believe when it comes to c++), this can be a warning flag that they are not interested in learning new things. But doesn't have to be if it was company policy, which is also interesting if they were in position to change this.
Third probe, ask follow up questions on differences since version N-1, this shows if candidate is staying up to date with latest trends or not.
If that's true, then the interview process would focus more on skills. From what I hear, faang companies are all about the leetcode on the Whiteboard oh, and they don't seem to ask specific questions about domain knowledge. In fact, you often don't know which department or project you're going to be put on when you get hired by one of those companies. And apparently the interviewers don't know either.
At least a few years ago, Google made it a point that the interview process was generic, not specific to any position or team. More like an undergraduate admissions process.
In reality nobody knows what skills will be needed for the position. Quite often not even the people who do the job. You can let them write down what skills are needed for the job, hire somebody who checks all boxes, and it could still be a catastrophic failure.
This is actually true. A bad hire, once in the door, can be very expensive and time consuming for an employer to rectify. This is what leads to all sorts of weirdness like “contract to hire”.
Almost every single tech company I've interviewed at (ranging from medium-sized startups to FAANG), I've given at least 5 interviews, going up to 7. The only exceptions were very small startups and a couple of large Chinese organizations, where they stopped at 3.
I remember interviewing for some grad roles. No hackerrank, no bullshit, very straightforward companies with "easy processes". Both had one "interview day", and five/six interviews total.
I read your comment and I was thinking in my head...wow, five seems like a lot, and then I realised that even these places I liked went pretty hard...I think they call this conditioning.
I didn't get either job btw, the work was trivial but I get terrible interview nerves so tanked both of them...in both cases, I also had a 6-hour take home...the results of which were largely ignored. Neither company is ever fully staffed...ofc.
To me, rounds imply a decision point (and delay) in between.
If I talk to HR on Monday, take a phone screen with an engineer on Wednesday, and come on-site (or Zoom now) with 4 engineers next Monday, that’s 2 rounds and 5 interviews (or 3 and 6 if you count HR)
> To me, rounds imply a decision point (and delay) in between.
My experience has been that if you clear the engineering phone screen the company asks you to go through all the rest of the (4-6) interviews, even if your performance in one or more of them has been sub-par. And at least here in India the post-screen interviews are spread out over several days to 2-3 weeks - there is no "onsite" as such, even over Zoom.
And this is why the distinction is important. You could have an offer by Wednesday. That's a 10-day turnaround, and no one was stringing the other party along. When you consider scheduling, unless both parties are desperate, the process couldn't reasonably go much faster.
I was going to say that there are tons of parallels with how some fund managers approach investment. I have met lots of people who have this trait for over-analysis, not one has ever made consistently profitable investments. Over-analysis is a failure to understand what information is important.
This is going to become more and more common though. In fund management, there has been a huge move towards "professionalisation"...which, ofc, means doing lots of pointless exams that select for the wrong thing. MBAs are the same. It is very hard to solve because the system selects for people who will play into this self-image (in my experience, this isn't solvable...you can either handle the risk of being wrong or you can't).
This also overlaps with a lot of the issues that a lot of companies are having with hiring. A company which frames hiring as a risk rather than opportunity and has these very long, negative process of hiring (be real, the point is to uncover "weakness", not learn more about someone) is going to fail to hire people of different backgrounds. The amazing thing about the "candidate shortage" is that it isn't more severe. Companies are so bad at hiring, it is surprising they end up making any decisions at all.
I think this is a problem our whole society will have to learn. Reducing risk is probably good, but we have to reach the point where trying to eliminate is universally seen as a pathology. It's already kind of a meme in consumer products ("warning labels these days, right?"), but it crops up in hiring, movie production, etc.
Salesforce have ever green roles which they casually do interviews for but never actually act on. The roles can be easily spotted as they’ll be posted and reposted on job boards like LinkedIn every 4 days.
I find attitudes towards risk in hiring very strange. Many companies seem to treat it like an opportunity for massive downside without much thought to the potential upside. I think the downside potential is mostly less than companies seem to worry (an argument against me is that a ‘bad’ employee negatively affects their teammates too). I also think the normal interview processes aren’t even very good at filtering out those feared candidates.
Instead I think companies, especially large companies where small numbers of employees aren’t a massive proportion of spending, should try to see the potential for upside more. Especially in a world where everyone does a similar interviewing process, a candidate who performs poorly at those interviews could be cheap and an excellent hire who is undervalued by the market because of their poor interviewing skills.
People are getting less and less willing to deal with bullshit when they're in massive demand and there is a talent shortage in $x industry. And they're finding out they can move around easily now too in this remote-first world.
Something is going to have to change - really a lot of things. One of them is going to be that companies need to learn to figure out how to hire people without putting them through a grind-fest. Figure out how to deal with bad hires after-the-fact, but don't let yourself get screwed not hiring good talent because you made the interview process a giant pain in the ass to catch the crap.
Oh and compensation needs to go up to make some of these interview grinds worth it.
Nothing's going to change at FAANG until average, non-FAANG companies can compete on TC (never). I doubt things will change outside of FAANG - because most companies are merely emulating the FAANGs and hoping they emulate the success.
> until average, non-FAANG companies can compete on TC (never).
And that's the rub. Not only do they struggle to value my skillset, they also can't compensate it accurately. And sadly, FAANGs don't even have the roles in a lot of niches.
When you can make 3x what a FAANG would offer, annually, but the companies building in your same niche are too immature and pay 1/3rd of what FAANGs do, its tricky to want to tolerate any of it!
Solo. Right now I can make 3x FAANG comp on a new idea annually without reaching out to my network or needing outside capital.
Given how many ways there are to do that and much more, I would like the structure of someone else’s idea to focus (aka being an employee). Doing things solo has overhead costs and liability risks, whereas employment has almost none but half to 3/4ths of your compensation is withheld the whole time. So there is a limit to what comp I’ll accept, given the opportunity costs. Would be great if that comp was FAANG level.
You know that it's pretty easy for senior engineers take make >$500k at FAANG atm, right?
Can you share some things in the past that were easy money that netted you $1.5M in a year? I'm genuinely curious.
I used to have a ton of ideas that I thought if I did everything right I could've maybe made $300-600k. But then you can just get that as a paycheck at FAANG.
None of my ideas ever were easy and could realistically generate more than that. Plus there was always a risk they would generate $0.
Yes, I am talking about $500k annual vs making at least $1.5 million in a couple of months and doing something else
Hm, worst case, people on HN debate an irrelevant understanding of what I say is possible
Best case, they copy it en masse and dilute the opportunities faster
No thanks
I would take $500k doing the same stuff for a tech employer but nobody is offering that right now. Some contracting firms do, kind of, don’t really want hourly though and also want the benefits. I want to focus on someone else's visions, get paid on days off, no risk. Also want a ton of equity I wouldn’t go and purchase myself. Or private equity that I wouldn't have the opportunity of purchasing in addition to an attractive cash compensation. (These are all things I could do in just frontend/fullstack work.)
Some smaller companies are going above the 125-150k range, to double that. But not quite and they’re still few and far between.
which obviously applies more to the person asking about what I've done because their ideas and execution made them nothing. good luck ya'll.
this is a thread about the conundrum of leveraging this experience without losing freedom or opportunity costs, not about being miffed that someone won't share how to make money, its like you all want to be scammed into purchasing an some youtuber's outdated amazon dropshipping masterclass.
> You can launch DAOs that automate anything these days and take a small percentage from the users of it. Just automate any small aspect of what people do and auto-liquidate proceeds for USD* so that you aren't accidentally speculating on anything, your users can pay for the liquidation too.
> *Your oracle server/cron job can incorporate a broker's API to get actual USD, your DAO can only get surrogates such as USDC which is redeemable 1:1 for USD at certain brokerages.
> It's a boom town. Anybody can make 3x more than what a FAANG would pay annually, and that's being generous.
One of many things you can do, Just didn’t want to people working on ads for a living to derail a conversation because they think crypto anything is a waste of time and mindshare
Consider we've had a labor shortage since BEFORE the pandemic. The gotcha here is companies have a shortage of people they can lowball into a sweatshop "startup" environment.
Nothing changed regarding that one as far as I can see so interview processes getting longer isn't all that surprising. After all that's one surefire way to optimize for getting desperate people.
A big part of what prompted me to become a contractor. When I last did this, everything was at least 3 interviews, + sometimes even the recruiters wanted to meet with you first.
Finding your own clients doesn't start looking as bad, and a discussion to see if you'll work together is much better than an interview.
>
That’s a question Mike Conley, 49, grappled with earlier this year. The software engineer, based in Indiana, US, had been seeking a new role after losing his job during the pandemic
This is ageism. I hope he realized this after 10 6 rounds of interviews.
Ageism absolutely is a problem in our field (I've seen/heard many people even openly boast of ageist hiring practices), but I don't know that ageism was the reason in that quoted case.
Not to invalidate ageism, there are many threads about younger people's interviewing experience that match this. The competition (other candidates) are doing much more than that, and also studying and practicing leetcode much longer than I am willing to.
Perhaps, but I can say that I am over 40 and I can tell when the enthusiasm for my candidacy dies after they see my face that it's not due to anything but ageism.
and I'm in an underrepresented group, we all have the ability to conform our experiences to the reason that matches what other people say will limit our opportunities. It is equally important to weigh each experience against the similar experiences. I've seen plenty of linkedin posts and blogs about people bragging about their quests to get competing offers in tech, some interviewed at 60 companies and did 100 interviews, when my tolerance is 12 companies and maybe 15 interviews. Some did 700 hours of leetcode, where my tolerance is maybe 5 hours. The dataisbeautiful and some employment subreddits have flow charts that show similar quests to get an offer, visualizing how much rejection and time is used inefficiently.
Like I said, not to invalidate anything, these experiences are so common amongst the whole pool that it has to be weighed accordingly.
It wouldnt take me 700 hours to get familiar with all the abstract problems and concepts I’ll encounter, but it would take me a very long time to, and longer to synthesize solutions that are above average, and regurgitating that on the spot for an interview in a quicker time than other candidates.
Well, one way that this works, is that older folks, that have gotten used to working in an environment of mutual respect, and have some modicum of self-respect, are less likely to put up with BS, as opposed to someone younger, who may have come from a ... less professional climate.
The idea is to drive out older, less-pliant potential employees, in favor of newer ones, who can be molded into a shape the corporation prefers.
Have you ever seen a couple that has gotten married later in life? Many times, it may be a second (or more) time for one or both of them.
They need to make massive compromises. Both have gotten used to supporting themselves, and keeping their own counsel. They generally both have a lot of property, maybe grown kids, careers, etc. Usually, they don't actually need each other, for more than emotional support. They each do fine, on their own. It's a relationship of equals.
It can be a challenge to make it work, but when it does, it's amazing. I have known many couples like that.
I understand why corporations don't want to put effort into working with older folks, but it can be well worth it.
So many times, when I see these awful, Jurassic-scale disasters, made by companies that are staffed exclusively by younger folks, I say to myself "That was a really great idea, but they completely pooched the release. Why didn't anybody raise any red flags?"
The answer is generally, that no one on staff had enough experience to understand the ramifications of many decisions, and often, they were afraid to countermand ideas put forth by their superiors.
Couple that with 20-something CEOs, who are often fearfully insecure, and you have a recipe for disaster.
I've been told by at least one manager that he disliked older devs because they are much more likely to push back against against poor management and refuse to put in overtime.
It seems to me that ageism actually has some value.
People never got any smarter, but the nature and details of group activity have changed over time.
After a career of delivering products for boutique manufacturing companies, I'd say that my ability to pass a modern interview suite is essentially nil. My last gig for a company with modern practices taught me that it's no fun in any case as design devolves into manufacturing (perhaps for good reason).
Give me a young body, and I'd look into purposefully arcane careers with little remuneration. Blacksmithing perhaps.
I think the third party screening companies will eventually win here. There will be an objective measure of skill at the job, plus some culture/fit interviews.
It does seem like the obvious efficient solution hypothetically. Right now we have proxies "Well he worked at FAANG so he's probably good enough for us" on the company side and glass-door (horribly subjective) on the individual side. But really no way for extremely-qualified individuals to say "show me all job offers within X miles that pay more than $y for position $z" (closest thing I'm aware of is indeed).
That said, for whatever reason the startups that tried to be intermediaries (and also various recruiters) tend not do very well in my experience.
If your application process starts with a human being—even better a technical human being—reaching out to me, followed by 2-3 interviews, followed by an offer, I am already on your side. If your application process starts with a HackerRank, followed by 2 phone interviews followed by on-site, followed by team matching, I will not be on your side. Oh and if there's random month long gaps in between stages, I will especially be uninterested.
I've noticed though that as I've gotten more specialized to compilers and programming languages, my application experience has improved significantly. It's not a large sample size but the last few processes I've gone through have been fewer interviews that usually involve going over a project of mine or doing a problem that's related to compilers. It's really refreshing to have an interview where I actually learn something about my field of interest during it. I know that doesn't scale because we shouldn't expect compilers knowledge for junior compilers jobs but it's a very nice change of pace for me.
I agree actually, I've had a similar experience except in the mobile engineering space.
Currently I'm going through the interview process with a ton of companies (because my company is really dumb and is forcing everyone to move back to a certain bay area city post-covid), and I have been happily surprised to find that most of my interviews are very practical, project based, ones instead of straight whiteboarding leetcode problems. I've received several take-home projects that are followed up with a simple add-on interview to sit down and explain the choices made during the take-home. They have all been specifically focused on domain knowledge to the mobile platform that I'm interviewing for. Its really nice! I hope this trend continues.
That said, I am still reviewing leetcode problems for the stupid faang interviews I have coming up as well.
I just went through this with a company. They sent me a generic packet with 3 projects to choose from. With a simple Google search I was able to find all of the answers to all 3 sample projects implemented in different languages.
This was after a 10 minute conversation with the company's recruiter. To top it off, nothing in the job listing said anything about software. Just Cloud and Devops management role.
I am absolutely ok with take home or some presentation of my skills. However, I expect to know that I am being taken seriously as a candidate by that point. I don't want to waste my time on something with no investment from the company.
As you can guess, I bowed out of the running explaining that I didn't think it was appropriate for me to give them so much of my time with no commitment from their end. I also told them I could tell their take home project took them less than 5 minutes to generate for me as it was everywhere on the internet. How can I trust a process where the answers to the interview are everywhere? How can they really know my skills as a candidate if I can just steal the answers off of GitHub? Worse, how can I know how I will stack up to someone who might be less scrupulous than I and steal those answers when I tried in earnest and actually burned an afternoon trying to solve their test?
Agree totally. I recently accepted a position where an officer reached out to me, followed by a really great discussion with them. A call with two engineers and a team call later, I was offered, and we were all confident it was a great fit. The interested was consistently maintained on all sides evenly and communication was fluid. Great experience.
compilers are 101 of CS with coding a major part of compiler being just a course project. Honestly, one of the most straightforward and simple things in the industry. At one of my previous jobs several senior undergrads (beside fresh grads which were frequently hired) were hired full-time to work on a major compiler suite. A nearby company doing a lesser known kind of bit more narrow specialized compiler suite were hiring even more of senior undergrads and fresh grads.
Is HackerRank so bad? If one does "whiteboard problems", HackerRank says, "boo, whiteboard interviews, just let me code and be able to search on Google, whiteboard is unrealistic!". Now if the company starts with a HackerRank test, that's also bad? I don't get it.
Look, a lot of people have good-looking CVs and can't code shit. I don't know about you but my experience was that one really can't hire based on CV alone. Also, I've seen "architects" that are smart and fairly knowledgeable people that failed to code very very basic stuff (as in, merge 2 sorted arrays).... I get it that at some companies you are expected to draw diagrams in Confluence as a main job, and might no longer have actual coding skills; but we want even the most senior people to actually code, and that doesn't seem unreasonable to me. So just because you're a very-senior FAANG employee doesn't automatically mean you'd be a good fit. I'm not saying they're bad employees, but maybe they just wouldn't be a good fit and wouldn't enjoy the job if they expect to just design stuff instead of actually implementing, too.
A lot of the issue with HackerRank is just how early it is in the process. I don't object to it. But there companies out there that just have every applicant do it indiscriminately.
HackerRank isn't inherently bad. It's actually pretty good. It's that receiving a 1-2 hour automated algo contest to every job application is bad.
If I applied to 10 companies, and every single one of them asked me to come onsite for whiteboarding as the first step, that would also suck tremendously, but at least it would be limited in scope by the employer's time as well. As it stands, arbitrary companies can expect a large time investment without any of their staff ever having to speak to anyone.
I'll take a calculated stab at Amazon's once every 6 months I guess, because if I pass (which I haven't) I can potentially earn a hell of a lot more than any other place. I get it, whatever. If every company is doing it (they are)? I might just leave the industry if I can't find a way to be specifically good at remembering the implementation details of every data structure and algorithm. Sucks to be someone with pointless skills I guess.
If there are teams interviewing candidates that are surprised to find that some applicants can't write basic code, then there must also be candidates that are surprised by that as well.
The longer a candidate has worked on very capable teams the more surprised they will be to have those problems presented in a job interview.
I agree it's subjective. Some people may prefer HackerRanks because it lets them do the work on their own time without someone watching them. For me, HackerRank problems almost always have nothing to do with my work, require passing an arbitrary test suite, and provide the interviewer with no insight into my problem solving ability. Who would you rather hire, someone who reasoned through the solution on their own, then dropped a hidden test case, or someone who saw this question before and just rote wrote it from memory? Perhaps both, but HackerRank won't give the former a chance.
Besides, if someone is duplicitous enough to have a good looking CV and no coding ability, what's stopping them from just cheating on the HackerRank?
TBH that's another argument I don't really get. Almost everyone agrees that basic CS knowledge trumps specific technology knowledge (I'd rather hire someone with strong CS fundamentals that didn't use Java before than someone who is a "Spring Boot expert" but lacks basic CS knowledge, even if I actually use Spring Boot right now).
But then, why complain that you don't do that in your work? Surely you need to traverse data structures from time to time, yeah it won't be the exotic tree traversal that I'd ask you to write but that's exactly the point - to test that you can be put in a novel situation that can't be directly-pasted from StackOverflow and you're able to write a recursive function that takes _a little bit_ of skill).
The hidden test case is opportunity for discussion during actual interview. And this answers your "what's stopping them" question, too - regardless of problem, I can tweak the input slightly so that your solution doesn't work - and more often than not, I don't even tweak the input, I just provide an additional testcase where your solution doesn't work. If you can quickly fix it ("oh, yeah, I forgot that URLs may have a fragment appended to it, let me quickly adjust my log-parsing condition") then it's awesome, it's exactly the signal I'm looking for, and we can go on to discuss system design and your relevant experience (but honestly, at that point my mind is likely ~80% made up, from CV + how you explain/modify your hackerrank solution).
The main problem with some of these things is that:
1) you're expected to spend 3 or 4 hours on some HackerRank test before you've even spoken to anyone. Some of these tests (outside HackerRank) can actually be projects that take a day or more to get right. The issue is that at this point I don't know if the attitude is "hey, this seems like it might be a good hire, let's check if he can actually code" or if it's "let's send anyone this test and discard anyone who doesn't pass". I suspect that in a lot of cases it's the latter. I'm not opposed to investing time, but it quickly becomes unmanageable if everyone just asks you to pass their several-hour tests just to be considered for application. There is very little time investment from the company, and it feels almost like a dDoS attack on my time.
and 2), that a lot of these tests are asking you to solve some hard problem that you will rarely face in real life and where people have quite literally won Turing awards for finding solutions to them. Many previous discussions about this on HN in the past.
I don't think it's even all that much more effective at actually weeding out bad programmers than a simple test. We used to ask people to write a CSV address book importer with some very basic requirements; nothing fancy, you could do it in 30 minutes. It worked well enough, and a lot of the results we got back were horrible.
You assume the interviewer is ideal: infinitely competent, infinitely great at judging other engineers' skills etc. This is practically never the case.
I am not one for LC type of problems, but at the least I have to admit they have the potential of being more objective than everything else during the interview process. You get the specs, you write the code and it gets tested via multiple test cases. It does not matter if the interviewer agrees your solution will work or not, and the interviewer won't have to copy&paste your code, compile and run it (like someone else mentioned in this thread).
On the other hand, what I particularly dislike about the LC problems is that many of them are essentially trick questions and brain teasers. Can't we just stick to problems that are relevant to an SWE?
I applied to a company recently whose first interview was a tech test. I turned them down before I even spoke to a human. I don't want to work for any company that puts so little value on people.
Honestly, I understand the whole send the tech test first. Having wasted time on talking to people who clearly weren't able to do the job I would rather waste their time than mines. For me, it's when I talk to their developers and it's clear they know I know what I'm talking about and they then try to tech test me. At that point, no. I just impressed the hell out of some of the people you consider to be your best and you think I can't code? Nah.
The tech test seems often like it's cargo cult. It's on Joel's list so everyone thinks it is a must do. Instead of realising that the entire point of the tech test was to make sure people could actually code. With some of the original tech tests being do FizzBuzz or do something really simple in a short amount of time. Not, build me a production ready toy project using techincal DDD aspects.
Having wasted time on talking to people who clearly weren't able to do the job I would rather waste their time than mines.
Of course. But consider how that attitude looks from the perspective of a candidate - you'd rather waste my time that yours is a really good reason for me to drop out of the interview process.
This is essentially what's wrong with hiring right now. Companies don't want to have anyone "waste their time", so they have many levels of filtering to reject candidates as early as possible while doing as little work as possible to make hiring good for candidates. In other words, companies have largely forgotten that candidates are people, and wasting anyone's time is a pretty bad idea.
Well, being the candidate I would rather they did a tech test first than talk to me and then do a tech test. Actually, if someone technical has spoken to me and then they ask me to do a tech test. I'm very likely to say no because they've already got a feel for my abilities and that is the point of a tech test.
I think sometimes people forget people working at these companies are people too and noone wants to have their time wasted. This isn't companies deciding these things. It's people. It's the person on the otherside that doesn't want their time wasted.
To be honest, I think I'd agree with you if job adverts included all the information necessary. Doing a tech test for a job when you don't even know the salary range, or what the role consists of, or what the company really even does ... that's what annoys me. If companies wrote transparent, clear job adverts I'd be a lot happier with their interview processes.
> The National Business Research Institute study shows that a bad hire can have significant costs to an
organization – between $25,000 and $300,000 5 . Asking a candidate to partake in four interviews may seem like overkill, but it seems trivial compared to the cost of a “bad hire.” Organizations that hire the best data science talent ensure they spend the time to use the best hiring practices.[0]
No one is doubting the risk mitigation, which is why the process exists in first place. But the BS of wasting someones time also needs to be addressed. The reason most companies waste peoples time is because they are too busy with abstract concepts tangentally related to the actual job, and theoretical models by some "expert" of HR management. Software engineering has become a psuedo-religious exercise in computing witchcraft.
If you want a backend engineer - book a few hours, even on a weekend, set up an IDE and get on a real world project. No bullshit. Build a small API to these requirements, using these technologies but take care of edge cases and deploy that bad boy.
Are you (or they) suggesting that the 4th interview meaningfully reduces the number of bad hires?
I’m guessing not.
It’s poorly designed and/or poorly implemented hiring strategies that lead to bad hires, mostly through a lot of noise being collected during the interview process.
This is a very solvable problem.
Edit: I will add that this is an ad for Booz hiring, so of course they want more process.
6 interviews increase the chances of a bad hire (or at least decreases the chances of a great one). It restricts your hiring pool to those who are willing to be abused by the company. That's not the top-tier talent.
That’s quite the range. It suggests a strategy: worry less about hiring false positives (with all the concomitant issues not hiring anyone brings) and worry more about reducing the cost of those false positives.
I interviewed with four companies back in May for staff engineer roles(or staff equiv). Based on that experience and my current employers process a somewhat baseline expectation can be:
* Phone screen with recruiter that reached out to you
* Screen with the hiring manager
* Behavioral interview with multiple peeps
* Code pairing session with multiple peeps
* System design session with multiple peeps
So AT LEAST 5 hours time commitment just on interviews. Add time to research the company, its employees, and etc. Maybe the code pairing is instead an at-home test of some sort. This could potentially add hours(or in the case of Teleport like 20+ hours). Just engaging with a handful of companies was a huge amount of extra work and stress on top of existing responsibilities.
I pulled out of three voluntarily and declined an offer from the last for various reasons, opting to stick out till my RSU cliff in October. For the next round of engagements I may start toying with filtering out companies based on their hiring process as well and giving push back on it to see what happens.
I had the same experience earlier in the year and ended up bailing out/declining offers because the process was giving me bad feelings about the work cultures at said companies.
I did actually tell one that the schedule of phone interviews (2) and video call rounds (4) was too much commitment without more details about the role and salary range. They responded with "if that's too much commitment the position is too".
Interviewing these days is not a technical challenge. It’s a fraternity/sorority rushing week.
Technically I was qualified and able to answer their questions. But ultimately was turned down after 6 rounds of interviewing. I think I was heavily dinged because I wasn’t entirely familiar with their product in the wild, and was never given any hint as to what product I would be working on.
I'm surprised good programmers have the time/patience for 6 interviews. I think 3, maybe 4 is my max. If you can't figure out my skills in that amount of time, your process is broken.
I also disagree that interviewing is not a technical challenge. For most programmers it is. There are very few who can breeze through FAANG-level technical interviews.
2 total interviews. Maybe 3 if they have questions. But if they have questions, they should have figured it out between the first and second interview.
For me, if the 2nd interview is not me talking to someone from their company that I might work with and if I cannot ask questions about the problems they solved, their approach to programming or building teams (depending on their role), I just say to the recruiter that I'm not interested.
The only reason why I'd come somewhere is if I like the engineers or if I'm in need of money. If I need the money, I won't ask a thing.
At one startup I did a couple rounds of phone interviews and a full day of in person interviews. Lastly I got to chatting with the co-founder. I can't remember the precise question I asked about how they were building out the team, but I clearly remember the answer. They made the interview process longer and more involved in an effort to narrow the field of candidates.
I understand the reasoning: if you think you have a special mission and want people dedicated to that mission, filter by dedication. But I'm not really sure there is a way for any one candidate to consume as much time interviewing for a role as that company could consume out of a pool of candidates. And that includes my smart-ass idea of trying to interview at Pinterest and stopping in the middle of the interview saying "please sign up to see the rest of this whiteboard solution".
If you go to an interview, you can probably suss out which are stringing you along and which want to hire quickly. Ask if they need a candidate immediately or are taking their time. Ask if your qualifications are exactly what they're looking for, and if you feel like a cultural fit for them. Ask if they have the budget and headcount to hire you immediately. Ask which teams the people interviewing you are on, to find out if they are all in different teams/departments or the same. Ask if each interviewer even knows who the the previous interviewer is in the company ("Frank who?"). Ask if they know exactly what they want you to work on. Follow up periodically to see if they are responding to you in a timely manner.
It's common for there to be some uncertainty with one or two of these things, but if there's a lot of uncertainty, you are being strung along. Best case they are waiting you out trying to find a better candidate, worst case they don't even have the budget for you and are playing politics within their company using you as leverage.
Interview multiple places in parallel, and don't cancel any interviews until you've got a signed piece of paper. But of course, prioritize the ones that aren't jerking your chain.
> Five companies told him they had to delay hiring because of Covid-19 – but only after he’d done the final round of interviews.
This is a typical HR strategy to keep themselves busy so they don't get laid off. HR is not a revenue generating department, so even if they aren't hiring, then they still need to push paper.
Next time you hear a hiring manager complain about shortage of engineers, ask them why haven't they changed the process with recruiting instead of just trying to fan out and sending automated tests and take home assignments.
It's just such a waste of time, too - you toss out so many other potential opportunities when doing these. I've heard of this being done to interns, people that only have so much time to get a job. Six interviews until a rejection. If you can't start your career without this going on I don't really know what you can do. I can't imagine the recruiters conducting these in the same position, going for six interviews to get that job. For software engineers you just need it, apparently.
In domains in which the underlying domain is complex, with an irreducible informational complexity, as well as rich and frequently highly significant interactions, there's a frequent emergence of faddish, or ritual-driven, behaviours. Both seek to reduce risks and accountability, as well as to increase credible signalling of traits.
Both sides of the technical recruiting transaction (job-seeking and recruiting) exhibit these behaviours and tendencies (what to wear, how to format resumes, presentation, side projects, for seekers, interviewing, tests and screens, and other filtering practices for hiring teams).
The consequence is a tremendous amount of friction, inefficiency, and fear-driven lore. Some years ago a senior Google staffer commented that they'd found a guaranteed hiring heuristic: "No". That is, reject all candidates.
My response was that if this was serious (and it was at least partially), that this was a profound sign of weakness within Google: an inability to seek out and onboard talent successfully.
There are other possibilities.
It could be that the notion of private firms hiring highly-skilled talent is inherently flawed.
I've speculated that one of the justifications for the ancient Egyptians to build pyramids was as a combination of a skills-development, skills-retention, skills-demonstration, and brain-drain-mitigation programme. From what I've read there's at least some independent informed speculation along similar lines.
One of the functions of writing a book, a notoriously unremunerative practice, is as a credible signalling of skill and ability. (And of book-writing capabilities, for what that's worth.) Books are very fat sales brochures.
In a tech world in which typical tenures are measured in months or single-digit years (2--3 years being typical from what I understand), and correlations between any hiring practices and actual performance ... at best weak, there's an inherent issue.
There's also the question of equitability of a process in which employers have vastly greater access to information on individual prospects than prospects do on companies or hiring managers / management teams. George Akerlof's "Market for Lemons" suggests that more information makes markets more efficient, though my fear is that highly asymmetric information access further tilts the employment market in the hiring firms' favour.
> I've speculated that one of the justifications for the ancient Egyptians to build pyramids was as a combination of a skills-development, skills-retention, skills-demonstration, and brain-drain-mitigation programme. From what I've read there's at least some independent informed speculation along similar lines.
Brain drain mitigation? Brain drain just wasn't a possibility 4400 years ago.
If you're living in a domain in which your core competency is in constructing complex stone structures, then leaking that capacity to another kingdom or empire would be a risk.
Pharonic Egypt circa 2580 was not without neighbours and there was both trade and warfare in North Africa and across the Levant and Mediterranian, notably with Syria, Canaan, Lebanon ("cedars of Lebanon" are a significant reference, as Egypt had virtually no timber), Ethiopia, and Nubia, amongst others. There's also the prospect of defection to internal factions. The Old Kingdom seems to have been generally peaceful with little internal or foreign warfare, at least until the First Intermediate Period, which was largely an internal rivalry. But it wasn't entirely without defence concerns.
I'm very happy to admit that my hypothesis is just that, and that there's no evidence and only a very little external support, though there is some. But if you're going to develop an advanced skill that would be of use throughout the region, it might be advisable to find ways to hold on to it, and as a pragmatic explanation for what was an absolutely immense effort ... there's some sense in the concept.
> If you're living in a domain in which your core competency is in constructing complex stone structures, then leaking that capacity to another kingdom or empire would be a risk.
How? The only military use of large stone structures is as fortifications; their primary feature is that they can never move.
And Egypt isn't even known for its city walls. That's the other civilization of the time, ancient Mesopotamia.
But on top of all of that, none of that is a brain drain issue. You're talking about a hypothetical issue of loss of state secrets. Brain drain is the concern that the local population of skilled workers will all emigrate, leaving the country unable to do skilled work. It's not the concern that other countries may develop the technology to do the same things that you can do.
Building pyramids isn't simply piling rocks on top of one another.
There's mathematics, surveying, architectural design, measuring, logistics, labour organisation, planning, transport, engineering, and a whole mess of related skills. If not kept in practice, they are lost (you're focusing strongly on the "brain-drain" element at the expense of "skills retention" and "skills development bits).
Too: once you've got those capabilities, there are numerous other abilities which derive from them. Large structures means civil engineering, construction, grain storage facilities, and quite probably some degree of metalworking and related crafts, again, which can prove useful in either foreign or civil war.
Take some time to think through possiblities, consequences, options, risks, and opportunities here.
> you're focusing strongly on the "brain-drain" element at the expense of "skills retention" and "skills development bits
Well, yeah. Look at my comment, in its entirety:
>>>> Brain drain mitigation? Brain drain just wasn't a possibility 4400 years ago.
If you can't defend that, then... don't? Make the argument that isn't obvious nonsense; you don't get more credible by throwing in a laundry list of "concepts that sound bad".
> There's mathematics, surveying, architectural design, measuring, logistics, labour organisation, planning, transport, engineering, and a whole mess of related skills. If not kept in practice, they are lost (you're focusing strongly on the "brain-drain" element at the expense of "skills retention" and "skills development bits).
There would have been no lost opportunities to exercise these skills in the absence of pyramidal efforts. They built temples, palaces, and cities on a continuous basis. Surveying is a constant need of anyone who collects taxes. (And it's particularly important in Egypt, where everyone's property lines move every year to match the extent of the flooding of the Nile.)
As far as I've read, the Old Kingdom pyramids stopped being built when the colossal economic strain they involved nearly collapsed the state. That doesn't suggest that they were useful in employing otherwise idle technicians. It also doesn't suggest that the system governing them was especially capable at logistics and planning. Planning would have involved noticing "this pyramid will cost X amount to build, which is more than we can afford".
> Large structures means civil engineering, construction, grain storage facilities, and quite probably some degree of metalworking and related crafts
I think this is backwards to a certain extent; I'd run causation from grain storage -> large structures, not the other way around.
I'm not interested in litigating minutia. I've addressed the point. I've admitted, repeatedly, that this is a very weakly-supported hypothesis, though not entirely without merits. Substantive proof is unlikely to emerge from a tendentious HN debate.
You're the one constructing a far more magnificant pyramid of this than I'd ever intended.
I've never been interesting enough to have gone through that many interviews.
I suspect that these companies have structural problems that inhibit their decision making. Possibly also personal problems.
I also suspect that if they can't say yes after a third interview then the candidate is non-judgmentally not a good fit, by demonstration. Both parties should consider that.
I recently agreed to go through a 5-round process which totaled to about 6 hours. I'm the first person to bitch about the ineffectiveness of leetcode/hackerrank bullshit for people with 10+ of verifiable experience, but I went through this one because it was a field I had never worked in before, and the personnel I was speaking with were truly interesting.
Sans all of those qualifiers, anything more than 3 rounds is a deal breaker for me. If you don't know if I'm the right fit after 3 hours, verifiable experience, a public body of work, and a list of references, then your company culture isn't a good fit for me.
Every bad hire costs the company $50,000 - 200,000. Sometimes more. They can also sink or demoralize teams.
Many of the people conducting interviews are new to the process and don't know how to extract signal. Sometimes scales don't line up.
When you have a revolving door of employees (because that's the way things are these days), have trouble scheduling interviews (busy engineers trying to get their own work done), and can't get enough skilled interviewers on a panel, then of course the process will be a suboptimal experience for candidates.
To a degree, companies would rather a good candidate was passed over than a bad candidate was accepted. Type I and II errors.
Companies also don't like telling candidates how they did because that opens them up to lawsuit liabilities.
You have to do enough interviews to get signal yet not piss off candidates. (Or your employees in the interview pool!)
Why is nothing done about this? As turnover soars and tenure plummets, I am willing to buy that companies do not value codebase knowledge, domain knowledge, or believe that it takes time for an engineer to get going. I can buy them seeing us engineers as replaceable widgets.
But we are at the point where a lot of companies cannot replace us and yet nothing is done about the endless parade out the door. The focus is entirely on shovelling new people in.
I think most engineers overestimate their irreplaceability. If a company actually wants you to stay, they'll fight for you. They just choose not to for >90% of engineers leaving.
Chances are, the new hire replacements will be in the same 90%, so it is a wash (minus ramp-up time), but maybe the company gets lucky and finds someone in the other 10%.
I get them being replaceable, but there must be companies would be getting to the point where there aren't replacements, or at least not good ones as the demand for engineers grows.
They least they could do is let you know up front what the interview process is going to be like. From what I've seen the candidate often has no idea if the second interview is the final interview or just the next in a long series. And I've even seen employers wait weeks befor calling back to inform the candidate they qualify for a third interview.
And if you have a revolving door of workers, that suggests something else is wrong. Maybe you should focus on retaining existing workers rather than acquiring new ones.
If someone is new to the interviewing process, then they shouldn't be doing interviews alone. If they don't know how to gather information from a resume, then they shouldn't be reading resumes alone.
You say that a bad hire is worth tens of thousands of dollars, but if that's the case, then most of what you said is irrelevant because a company that is smart enough to recognize this would be smart enough to never put a junior manager in a situation to make a terrible decision.
It's either important and expensive or it isn't. I wouldn't be "shocked" by anything. I used to be a recruiter. In my current dev position, I have absolutely nuked candidates by asking basic questions that the managers (who were eager to hire someone to fill a spot) and other devs (who would feel uncomfortable if they asked the question and hence didn't) failed to ask. A candidate who will try to bullshit me about something he doesn't actually know is someone who will waste time on projects by not using all the resources available to him to find the correct solution (this usually involves being brave enough to ask questions if you don't understand something). If my future depends on your success, then I'm going to ask questions that will make me feel like I can trust my future in your hands.
If a manager is getting paid $150K a year and it costs $200K to fire a bad employee, then "when they're ready" is the correct metric to use.
So they can learn from experienced interviewers who just make you leetcode and answer dumb stock questions (my biggest weakness is…)? What we need is for people to interview with zero experience and figure out a better way on their own, not copy a bunch of bad processes out of insecurity
If you've surrounded yourself with incompetent people, then you still shouldn't assume that everyone else is equally incompetent. Cynicism isn't wisdom.
Your response is the voice of the company. The person you're responding to, and lots of candidates, don't really care about the voice of the company. From a company's perspective, sure waste all the time you want, you want to be _sure_. But to candidates, getting dragged around sucks, and is usually a waste
The lower end of that, and honestly, the higher end, is just about complete rounding error to any FAANGM+ caliber company.
I have seen a fairly small amount of employees hit the lower end on a singular dining bill when they had a company card and were meeting with business partners they were trying to "impress"
(obviously, the joke is free nice food and drink for all involved at the companies expense)
If you were fickle you could perhaps justify that as priced in to keeping good relations... but in the same light I'd call your figures priced into the talent acquisition process.
Yes, every bad hire is really bad. However, companies generally don't put in any effort into seriously evaluating your publicly available work. I have reams and reams of open source code companies can take a look at, and I've never seen any evidence that any company I've ever interviewed at has looked at that work. That's a result of companies being completely incompetent at evaluation and disrespecting their candidates time. Its wasteful and stupid. Its honestly flabbergasting how many companies don't put in the effort to make their hiring process passible, much less anything near "good".
Being on the hiring end, it’s less out of incompetence and more of not enough time, and open source code is low signal that the candidate can actually solve problems.
If I submit some “open source” code as some proof that I can code, how do you know I didn’t copy the code from somewhere?
Also, writing code for the sake of writing code doesn’t tell a hiring manager if the person can take requirements and translate that to an automated process. It just say that person isn’t that busy and can, excuse my language, shit out code for the sake of appearing productive.
Writing code can be a hobby, sure, but that’s only a small part of a software job and no amount of open source code can tell a company if the candidate can work with others and solve problems.
> no amount of open source code can tell a company if the candidate can work with others and solve problems.
Balderdash.
When was the last time an interview task involved working with others? I'd offer that open source PRs show this way better, and in an appropriate context (as a collaborator) rather than what we have now: adversarial interview{er,ee}s.
> how do you know I didn’t copy the code from somewhere?
You can ask your candidate to explain the code... Is that not obvious?
> writing code for the sake of writing code doesn’t tell a hiring manager if the person can take requirements and translate that to an automated process
Kind of sounds like you don't know what open source software is.
> excuse my language, shit out code for the sake of appearing productive
I won't excuse your language. You sound like you're part of the problem buddy. I don't think you have any idea how to evaluate a programmer.
> You can ask your candidate to explain the code... Is that not obvious?
Asking about projects is the obvious thing, but only substantial and interesting projects really provide any interview value. Yet another Todo app doesn’t fit that criteria. Neither is another scaffolded crud app.
A PR to fix a bug in a semi-popular library is worth. But saying “I have a lot of repos” is def not.
I don't know why you're assuming my or most good programmers' githubs are filled up with todo apps and other worthless garbage.
> saying “I have a lot of repos” is def not.
When did I say that? I didn't. They should be looking at the repos and asking about them, not just taking your number of repos and using that as some kind of metric.
I agree on your open source comments as far as, the only open sourced code a person has is personal pet projects. However, if you see someone has PRs and commits into something like the Linux repository or a major well known project, then their open source contributions could be very meaningful. As an example. If you are hiring for a position for a developer to work on garage band at Apple, if an applicant is an audio dev for FreeBSD, that is a pretty good sign the candidate knows what they are doing.
> It just say that person isn’t that busy and can, excuse my language, shit out code for the sake of appearing productive.
It sounds like you have a serious misunderstanding of open source at a basic level. It would have been questionable enough in 2000 but I’m not sure why anyone in 2021 would think that way.
I’d argue the other way - open source in 2000s to central libraries were of decent quality. The quantity of code now these days is so much and of questionable quality - everyone and their bootcamp writes code to GitHub and call it open source, just to show they have open source.
Hell, I have public code on GitHub, but I’d never put it on my resume.
There may be a signal-to-noise problem, but the amount of useful open source projects and the extent to which we rely upon them has only increased in the past 20 years. “Open source” includes projects like Go and NodeJS, which are hardly trivial, disposable projects like you’re referring to. Pretty much all crypto is open source and people have invested tens of billions in that ecosystem. I could continue and list at least half a dozen projects that are considered critical infrastructure which are developed in that fashion.
Well the obvious issue here is...how do they truly know you wrote the code? Its pretty much impossible to source where OS code comes from, and it sure wouldn't be hard to find an obscure OS project and pass off the code as yours, if you were that sort of person.
And this takes me to my 2nd point, and that is they current hiring model totally leads to companies hiring people who are good at interviewing not necessarily people who are good at doing the work required. There is no doubt t that interviewing for a job is a skill that can be learned and improved upon, and lots of crappy programmers have learned to be damn good at being I interviewed.
If a person has a history of giving talks, writing books, or creating content around code they've written there's probably a high likely hood they are capable workers and can code.
This is mostly management speak for: don't blame us, we're just incompetent.
If you run a company and you have a "revolving door of employees" (ie: we can't retain talent), your managers "are new to the process" and don't know what they're looking for (ie: we hire inexperienced managers), and you "can't get enough skilled interviewers on a panel" (ie: "we don't hire enough engineers and we're too cheap and shortsighted to put them on tasks like hiring")... then yeah, you should expect your hiring costs to go up, have a revolving door of employees (because you don't know how to hire), and your teams to be demoralized.
The consequences of that are your (company's) fault. You should own up to your shortcomings and work on your hiring process... don't just punish the candidates indefinitely so that you can ignore your problems.
(I say this as a serial founder, and hopefully never need to be on the other end of the hiring process.)
A lot of IT positions at Universities. To the point where it can be a problem as in a Junior Position, it can be really hard to be promoted internally unless someone decides to leave, which they rarely do because people in Senior level Uni positions get good pay and they tend to be very chill environments.
I’d like to add time aspect as well. If selected, candidate will spend next 12-18 months with the team, 5 days a week. I look at those 5-6 hrs as worth an upfront investment from both the sides just ensure those days months aren’t miserable and you don’t end up parting ways on bad terms.
I’m saying this as an interviewee as well as hiring manager who has conducted more than a thousand interviews.
Nothing frustrates a team and hiring manager more than a mishire. It’s the same for candidate, they have to go through the charade of interviewing at tens of places again.
It's interesting to hear of these experiences because my own job applications have usually taken four steps:
* See the advert online, and send an email/fill out a form to apply.
* Have a quick phone-chat with a HR-person, where they ask about salary, history, and try to decide if I'm a chancer, or I have some somewhat useful skills.
* Have a 30-60 minute interview with some technical people, in-person.
* Optionally have a second interview with a tech-lead, or somebody else higher up the chain.
* Receive offer, rejection, or get ghosted.
Smaller companies sometimes have different processes. More than once I've sent an email/CV in to apply and been invited out for beer/food, and received a verbal offer the following morning. No other interviews, or tests.
Yes, same for me. I was going through my past interviews, and the most I’ve had before an offer has been two, both scheduled on the same day. And I’ve worked in agencies and big orgs, in both private and public sector. Maybe we’ve just been lucky?
Thought your comment was interesting, so went to check out your profile.
That was also clean and well made, so followed through to your website.
Found this:
"I published a simple tool to all your repository details from Github, self-hosted Github Enterprise installations, and other compatible systems."
Do you mean:
...to [pull] all your repository details
Since you have such a nice profile and everything I thought maybe you intended to include this word in there.
Hope this is helpful.
Somewhat related to interviewing and getting hired.
If it's in an appropriate comment for this threat then please remove it. @admin
I do research assistant work in biology. The best way to get one of these rare jobs is to email the professor directly. They then have a "chat" with you (don't be fooled, this is the formal interview!) and then several weeks later they get around to bypassing the Uni's hiring process and you get a job.
I really am not looking forward to going through a formal interview process, because it will be so jarring compared to what I am used to!
Fwiw I also work in molecular biology and did a recent round of interviews (summer 2020).
Started with applications over a web form on the university careers website, then chatted over email with the hiring manager. Eventually got set up with some interviews with current lab people, and eventually the PI.
Mirrored in industry, although that was back in 2018. So all in all the “regular” route at least for this level of work in biotech/biology is pretty sane.
That being said, I’ve used your method in the past as well to great success, and is one of my secret techniques to get more traction when I’m looking ;)
I wonder if this is a way to crowd out competitors. Take up so much of a candidate's time that they can only interview at a handful of places successfully. Either the candidate goes all in on you or they pass without using your resources. Kinda the grocery store shelving model of competition.
And it’s to weed out people who value their own time and who won’t take part in pointless company mandated bullshit.
If someone sits though 6 hours of interviews and pointless exercises that should instead be solved by consulting the documentation, they will probably just do what they are told without fuss, will work overtime for free and will let the company walk all over them with regards to sick pay, holidays, etc.
I interviewed with a company out of SV that did this. They started with 3, added another 3, one hour interviews and finally another 3. 9 interviews over the course of almost a month.
I was being interviewed for a principal engineer. I was very clear and kept saying I wanted a management track position. They kept saying we love your background we can work with you on this. Ninth interview was with the CTO. He said the same. Them ghosted. Wouldn't answer my emails or calls. 9 hours, plus prep time wasted.
The company I ended up getting hired by also did a large number of interviews, 8. And they took even longer. Just over three months from initial contact. They're fantastic to work for, but I do think there comes a point where if you keep digging you're going to find something you don't like.
I'm too shy to name and shame, but my former company would ask us to advertise and interview for jobs, but only after countless hours of interviews decide they didn't want to increase headcount. I lost about 1 day week for months doing our best to find great people. We would fly them in from all over the place. This happened multiple times. I think I left to make indie games after the third time.
Yeah it really bugs me when companies reach out to experienced people, put you through multiple rounds, only to ghost and ignore you after. I'm looking at you Glassdoor.
I talked to a company for three weeks — I went over and would talk to a couple of people, a couple of times a week — and then decided they wouldn’t get their act together.
I didn’t mind the way it unfolded — people were busy, I wasn’t working, and it was only a couple of minutes away from me, so really it was only perhaps 8 hours. But after three weeks I felt I wasn’t getting the answers I needed and they didn’t seem to be making progress on the hire. So I said no thanks.
This was a company with 50 or so people — I have no idea how they managed to hire them.
Google took 3 months. 1 month was from the virtual onsite final interviews to the Hiring Committee decision. It was a miserable month and even my wife hated Google by the end.
Second was for a Director of Engg position at a mid sized company. It took 2 months and finally I had to force them to answer. It was a company with weak leadership and it showed in their inability to make a decision.
It's odd. I'm tending to think going through recruiters is the answer. The recruiter can be the bad guy and actually get a yes or no by putting pressure on otherwise I'm emailing multiple times and lucky to even get a response. If you weren't sure what the next steps were then why are you even hiring?
For everyone saying that it's risk mitigation, I recently asked about something similar[0] for a junior position, and the process still hasn't finished. For context, the company is a medium-size tech company with presence mostly in Europe and Asia.
I don't know these things well enough but it makes no sense to me. For starters, in the tech sector in my country the salary for fresh grads like me actually come mostly from the government. Moreover, these companies are all secretive about compensation, and they probably think they can get away with it by dangling their "reputation" in front of you like a carrot. In most cases the salary is about the same as a small startup because, again, they get the money from the government.
People can argue about spending time and resources on training and what not but basically every job ad, from "top" companies to the web dev garage down the road, expects us to learn by ourselves anyway?
It's frustrating for early career starters that most of my friends and I are going through. It's such a huge waste of everyone's time and people are just churning because of this crap. Please get rid of non-technical HR and interviewers.
Sorry for the emotional rant. I would really like to know what risks (other than useless non-technical HR keeping their jobs) there are after candidates have past a certain threshold for quality, particularly for junior positions.
> I would really like to know what risks (other than useless non-technical HR keeping their jobs) there are after candidates have past a certain threshold for quality, particularly for junior positions.
It's harder to deal with emotional kids than it is to deal with incompetent engineers. Maybe that's why those non-technical HRs might not be as useless as you think.
> You made the mistake to assume that we are idiotic enough to be emotional for job interviews.
And that's a risk that could potentially be spotted by a competent HR.
> It's harder to deal with people who think they are competent and know it all than emotional kids.
Maybe, but juniors are (unfortunately) seen as a commodity by the market. Commodities are about uniformity and adherence to some standard, rather than uniqueness.
> And that's a risk that could potentially be spotted by a competent HR.
It's a risk that could only be spotted be HR, don't know about the "competent" part. There would be no emotional-kid risks to speak of if it weren't for useless HR.
> Maybe, but juniors are (unfortunately) seen as a commodity by the market. Commodities are about uniformity and adherence to some standard, rather than uniqueness.
It's making even less sense now. If we are commodities and it's all about uniformity and standard, why do we see senior engineers complaining about this, too? It also makes no economic sense to spend so much time and effort on elaborate bullshit on "commodities". I don't mind being a commodity if the standards that you speak of exist, and I don't want to be unique. But guess what? It's the HR that wants us to be the unique commodities.
The most difficult people I've worked with were not because of technical reasons, but due to reasons outside of that: inability to disagree constructively, unwillingness to compromise, or just general assholes. That kind of stuff.
Someone without the required technical chops can be useless, which isn't good, but these people can be worse than useless as they can derail and/or demoralize an entire team. I've seen it happen; it's not pretty.
This isn't unique to younger people, but in my experience the risk is quite a bit higher in younger people. I say this also as someone who, in hindsight, was quite difficult to work with when I was younger for various reasons. As I've grown older, I've learned a thing or two and I think that now I'm actually a fairly nice person to work with (I hope so, anyway...)
Everything else being equal, I'd rather take someone with a 9 (out of 10) on soft skills and a 6 or 7 on technical skills, than someone with a 3 or 4 on soft skills but a 10 on technical skills.
> Everything else being equal, I'd rather take someone with a 9 (out of 10) on soft skills and a 6 or 7 on technical skills, than someone with a 3 or 4 on soft skills but a 10 on technical skills.
I agree, I've even had to reverse my own team's policy on this at work : I used to think the technical stuff was the most important and pushed my team towards hiring exclusively the technically smart people, but I have been proven wrong over and over again by those "smart" engineers I vouched for.
"Smart" isn't just technical skills anyway. You can have all the technical chops in the world, but if you never listen to anyone else, insist on doing things the One True Right Way™, and are unable to admit that you're wrong, then effectively you're not actually all that smart, are you? "Smart" is really a combination of skill and attitude.
Indeed, the smartest people I've met are the nicest people to chat with and always ask questions instead of affirming themselves. As you point out, skills + attitude is the smart way since everyone wants to be around a nice and skilled person.
On all job responses you should spell out your minimum salary requirements before you agree to the interview, unless you are ok with wasting time on interviews only to get low balled on the salary side or it doesn't match your minimum requirements.
Most of us don't have the privilege to negotiate, we are fresh grads. Who doesn't want to work for larger companies in the hope for a better career path? And don't forget about power asymmetry.
1,202 comments
[ 3.1 ms ] story [ 534 ms ] threadIn the real world, you cannot remove risk. You can manage it, but you cannot remove it. Asking candidates to go through 6 interviews before making a decision and not telling them when a decision will be made signals a risk adverse culture that cannot make decisions.
The best teams embrace and level up their low performers and make the whole team better.
The delta can’t be too big.
The company doesn’t have to prove that the employee was failing. It’s perfectly legal for a company to fire an employee because they the employee likes the wrong football team.
The employee or people pursuing legal action on behalf of multiple employees has to prove that the company fires the employee(s) because they were a member of a protected class.
Assuming there are no incriminating emails stating that that was the reason, the only realistic way to do that is to show a pattern.
If an employee decides to sue, whether you had them on a documented performance improvement plan for 6 months or 6 days isn’t going to be the deciding factor.
They do if the employee sues claiming age discrimination, for example. At least, they have to defend the accusation to show it’s not discrimination. When someone has been at the company for 25 years like in the parent’s example, and they get fired abruptly without notice for liking the wrong football team, it’s likely the stated reason is untrue and inviting a challenge.
> If an employee decides to sue, whether you had them on a documented performance improvement plan for 6 months or 6 days isn’t going to be the deciding factor.
It certainly helps show that the company isn’t discriminating arbitrarily, and gave the employee notice and a chance to improve the situation.
BTW actual legal action isn’t necessary for firing to be getting harder. The fear of legal action is all you need, and that is in fact going up.
They don't have to show anything. The employee has to prove that it's age discrimination.
>When someone has been at the company for 25 years like in the parent’s example, and they get fired abruptly without notice for liking the wrong football team, it’s likely the stated reason is untrue and inviting a challenge.
Without a pattern of discrimination this isn't a problem. If there is pattern of discrimination then it is. However, if that's the case it doesn't matter how much documentation they have.
>It certainly helps show that the company isn’t discriminating arbitrarily, and gave the employee notice and a chance to improve the situation.
You can't discriminate arbitrarily. Discrimination in this context means firing someone because they are part of a protected class.
>gave the employee notice and a chance to improve the situation.
Whether you gave someone the chance to correct the situation or not isn't relevant.
>BTW actual legal action isn’t necessary for firing to be getting harder. The fear of legal action is all you need, and that is in fact going up.
The number of charges filed with the EEOC has gone down over the last 20 years https://www.eeoc.gov/statistics/charge-statistics-charges-fi...
https://www.natlawreview.com/article/eeoc-roundup-part-i-10-...
"At the same time, FY2020 saw the lowest number of charges received from workers in more than two decades. The agency received 67,448 charges—continuing the steady downward trend since 2017 in the numbers of discrimination charges filed with the EEOC."
Yes that’s a compelling data point for decreasing legal actions (and it’s interesting, thanks for including it), but not all actions and not all fears end up in front of the EEOC, right? This data point alone is likely due to decreasing union membership over the last 20 years, but is also explained by the increasing prevalence of mandatory arbitration clauses. What it doesn’t explain is why HR departments nationwide are increasing efforts to educate employees about anti-harassment policies. If they are legally in the clear, why is that happening? Twenty or thirty years ago it was hardly a thing, today it’s the norm.
> They don’t have to show anything. The employee has to prove that it’s age discrimination.
You are right about the legal burden of proof in court, absolutely. Court isn’t the only possible outcome of a discrimination claim, though, and the one specific example you gave is a defense against a discrimination claim that would not hold up in court (firing a long-time employee for claiming to not like the right football team).
I agree with everything you’re saying about what is required in court, and what are the legal rights for all employers in the US, not just tech companies. That’s just not exactly what I was talking about.
Honestly, I don't have a good solution to the problem.
In the past I would never have been interested in a contract-to-hire. These days though if the company and role is right, and this an option to short-cut a ridiculous interview process, I might spring for it.
When I was an actuary we used to do “intern to hire” for unemployed recent grads, but I can’t imagine leaving a full time position for a contract-to-hire position. I think for me personally the opportunity would have to be really interesting and the comp upon converting to FTE would need to be at least double my previous comp (meaning the contracted rate would probably be something like 4x my implied hourly).
I've see that work before, but it was some time ago. The company also had a very large test department with separate management and kept to a strongly enforced waterfall-esque design routine.
Of course, it used to be a lot harder to ship out version 1.01 of the software.
I just assume it was a different world as this was in the days of US manufacturing, very limited set of software tools, high importance placed on domain knowledge as opposed to toolset, longer average stays at employer, lower wages for programmers. Probably not applicable to modern times.
There's a quality-distribution of both books and films.
There are only so many good books. And a percentage of films end up poorly made.
Sufficiently low-quality books tend not to get made into films. The ones that succeed are notable --- there's nothing but upside.
A good book can be made into either a good or a bad film. If it's a good film, then yay, but if it's a bad film, people are aware of it (through the book's quality and popularity). This is a perception illusion called Berkson's Paradox. It's an illusion because what awareness fails to account for are all the bad films made from bad books.
Hannah Fry of Numberphile does a much better job than I of explaining this: https://youtube.com/watch?v=FUD8h9JpEVQ
In the interviewing / performance case, you have good vs. bad interviewees, and good vs. bad performers.
Someonehone who interviews poorly but performs well is a positive exception. Someon who interviews well and performs well meets expectations. It's the good interviewer/bad performer who stands out. But it's the poor-interviewer/poor-performer who is missed by this assessment.
The problem is management are often too busy or overwhelmed with other stuff to observe and provide feedback until someone's passed the probation period then releasing them becomes a bureaucratic nightmare - and when the new hire's not getting feedback, you can be sure not a lot of the rest of the team are.
I've never understood this given that the hiring is so often at will.
It's a huge risk on the other side as well. Not to mention that management usually gets to control the narrative and not the employees.
I finished the 7th on-site interview. After I left NYC and flew back home, they wanted a 8th ( phone screen ) interview because one the interviewers lost the results.
On the one hand, this space’s modus operandi is more data is always better.
On the other hand, they have to trade and make decisions in a fast paced environment with imperfect information.
yeah, no. You dodged a bullet with that one.
Probationary periods could work but it's a coordination problem. Such periods are the norm in Europe (coz it's very hard to fire someone) but for an at-will place like the US, given that the industry doesn't really do probationary periods in general, any employer who starts doing it would be at a disadvantage.
In the sense of offering signing bonuses for term lengths that get repo’d if the contract length is broken.
While I agree interviewing has gotten ridiculous with all the leetcoding and ten rounds of interviews and FAANG cargo-culting and whatnot, one small advantage - assuming I'm not desperate for a paycheck - is that it gives me, as a prospective employee, time to consider and withdraw my application if I see too many red flags or I just prefer the devil I know.
A short interview process with a probation period on the other hand is a big roll of the dice. Maybe I'm not able to ramp up on time, or make a silly mistake due to unfamiliarity with the codebase or underlying business logic. Maybe I don't get on with the team or manager. Maybe I'm going to be dumped into a doomed death march project on day 1. I could find myself unemployed a month later with an embarrassing gap in the resume. Perhaps on the other hand a better interview process (not longer, just have properly trained people and constantly improve the process with feedback) would save us all that pain.
All the while, productivity suffers as the remaining team falls further behind due to short-staffing and being pulled away from their real jobs to interview.
> In general, people leave their jobs because they don’t like their boss, don’t see opportunities for promotion or growth, or are offered a better gig (and often higher pay); these reasons have held steady for years.
And if it is about money, then this is called paying competitively.
But lastly, recognize that if everyone is training employees you're still not really losing out unless you're only hiring entry level employees. Sure, you might be training someone that leaves, but so does your competitor. But if you're only hiring junior engineers then you're probably doing something wrong that's much bigger.
[0] https://hbr.org/2016/09/why-people-quit-their-jobs
Out of curiosity, what sort of "non-monetary" benefits were you thinking about? There's usually not a reliable way to turn (small amounts of) money into the sorts of things that really build loyalty.
If an employer does do training, it means they'll probably continue to do more training over time, which helps the employee become more valuable.
If the employer doesn't do training, yes they may be able to allocate the training budget to salary, but they are not going to spend anything training you or letting you work on projects to increase your skills while you're there, unless they absolutely must.
I think people also have some human perception of how they're being treated, and prefer to work for people that invest in them.
Sometimes they leave. By that time they've used what they've learned and passed some of it on to the next person.
I don't know what it is but I feel like people have forgotten just like basic truths about how humans work. Maybe it's because managerialism has infected everything.
Even still, it’s obvious that comp alone isn’t enough to retain employees. Even FAANG companies, which pay extremely well, have pretty low retention numbers. Facebook does best here, at an average job length of only 2.02 years. If comp was enough, people would stay there longer. This implies that people are changing jobs for reasons aside from “this other company will pay more”.
Even if some of them genuinely get promoted before they’re ready and wash out, you’re not really that much worse off than if you’d lost them before. Besides, there’s always the risk that your new hire is unprepared too, which is a much harder thing to quantify.
Losing people who are experts within the domain of the software they're maintaining because you refuse to invest in them is going to cost you thousands of dollars... the only question is whether that's tens or hundreds times that amount... and in some cases it can cause you to lose your entire business.
Basically there’s two types of efficiency, investment efficiency and allocative efficiency. (There may also be other types I don’t know about.)
Investment efficiency means people are incentivized to make positive-expected-value investments. Think about how people are incentivized to invest in their house, e.g. preventative maintenance, because if the expected value is positive then they will recoup that value when they sell the house. If you’re renting you don’t have this with respect to where you live - water damage or no, not really the renter’s problem. Investment efficiency is maximized by private property, where you know that no one will take your property without your consent.
Allocative efficiency means things go to whoever is willing/able to pay the most for them. Renting does have this property - if both of us want to rent a house, and I’m willing to pay more, in most cases I’ll end up getting the house. This is why gentrification can cause displacement - when wealthier people come into a city and are able to outbid the current renters, they win and the current renters lose. Allocative efficiency is maximized by auctions and things like them, where the good goes to whoever is willing to pay the most.
Bringing it back to your comment, job training isn’t worth it because our careers as programmers are dominated by allocative efficiency, not investment efficiency. If you can train a programmer create $50,000/year more value in general (i.e. it’s not training that would only be useful to your company), they can now get paid about that much more from any of your competitors, and you will have to pay them about that much more to stop them from leaving. So you gain nothing from giving them general-skills training.
Another way of solving this problem is with sectoral bargaining. If you have a sector-wide union, they can make all companies start training simultaneously, or assume some of the costs themselves. It’s a win-win for the industry and for the programmers, but it doesn’t happen nearly as much as it could because of that coordination problem.
The union is ensuring that no company can ruin it for everyone.
But it makes Reginald the investor angry that his ROI isn't exactly 20% each quarter, so they jettison apprenticeships and start cooking the books to make that possible.
I had a kind of career crisis/breakdown, where I realised no one gave a shit about anything except my utility as a walking set of tech keywords. Accepting that it wasn't working for me was one of the best things I've done for my career.
It's that I firmly believe that there's more to software dev than just knowing a 'stack'. And even then, fair enough if they were curious about my .NET skills. But them asking about specific versions of .NET core really woke me up into how much of a commodity labourer they were trying to turn me into.
Many software engineers have accepted that they have to continually learn and will do so.
This process though, makes it impossible to know what to learn with an impossible random and unknown credential set. It's not the same as something like elevator attendants having an obsoleted skillset. It's a combination of not having time in a lifetime to even try to specialize in the random employer chosen skillset. When instead, employers should expect a good engineer to adapt quickly and employers should also commit to training staff.
At the risk of suggesting you might be dating yourself, I think this is an outdated model. It's simply no longer realistic. I personally believe that having personal expectations of what my adversaries or those outside of my control "should" do will inevitably result in sadness on my part.
Corporations will aim to do what they must to increase profits (given, by definition). Any additional assumptions from that are liable to be faulty. Perhaps you are used to the times when they needed to train staff but that's simply a symptom of the circumstances as opposed to a duty.
- going on $JOB_BOARD
- sending out CV & Cover letter
- talking to recruiter
- going to 3 interviews
- rinse and repeat
Wasn't working. I was not in demand. I had to constantly reach out to people, just to get interviews at places I didn't really want to work for. And even then they'd usually reject me.
It was a wake up call that I was on the fast track to nowhere, and something had to change.
Ended up specialising in an industry and doing contract work. I'm not super successful yet, but there's a lot more interest in me. My work days are much less frustrating and I'm earning more.
I am genuinely asking. Why is this objectionable?
Why do people find it so horrible that their labour is a commodity? To me that just tells me I should treat my labour like a merchant treats his goods. Always be checking the market to ensure you have something worth selling and while you might sign long term deals, periodically check for the best price to ensure you are getting it.
Why is it important to you that your employer view you as a person?
Because we, generally speaking, are people and not robots ;)
That being said, I agree with your point : people would have less issues if they just felt happy about whatever makes logical sense. That's just way too hard to live by for most people.
The answer to the question as written is...of course people want the entity that has outsize influence on 40 hours of their week to view them as a person instead of a mindless cog in a machine. People get treated better than cogs. Workers want their working hours to be as pleasant as possible, which is much more likely if your employer sees you as a person.
Is that really surprising to you?
Needs can include a nice workplace and you can negotiate specific details about what that means to you. I did not mean to say that it needs to be money.
You're not describing an employee, you're describing a consultant. Not everyone wants to be a consultant, particularly since most people don't get any training in it before they have responsibilities. If proper entrepreneurship was a subject at school, then maybe people would be willing to be their own business, but that's not what the system creates (or wants).
Fair, I can see why this might bother people. I don't think job security is a thing (career security perhaps), but I can get why its absence would be disturbing.
> expectation to be wading through the job hire swamp every couple of years.
The high level of turnover in this industry indicates that people at least tolerate it. The only people I know who make it 24 months in a role are chained by stock options.
This would all be fine, but no one writes ads saying what they actually need or what they're trying to do.
It's not about being viewed as a person. It's about being viewed as a professional.
Good organizations hire talented and bright people with mastery of CS and SWE fundamentals. Bad organizations think "oh we use Java, better hire Java programmers". Really bad organizations think "oh we use JUnit, Spring Boot and IntelliJ, better hire people with experience in JUnit, Spring Boot and IntelliJ"
One of the strongest signals of how good an engineering organization or a tech team is how few specific technologies they list in their job ads.
I'm not even an exceptionally talented programmer: just a competent one. Of course there are real differences between languages that matter, but at the end of the day ifs are ifs, ints are ints, functions are functions, etc.
Relevant old joke: https://www.reddit.com/r/ProgrammerHumor/comments/4k994j/if_...
That said: there are some reasonable scenarios when you want to hire someone with prior experience; for example as a first or second hire it's probably a good idea in most cases, or if you really need someone who can hit the ground running.
Case in point: a Stripe job listing I picked at random
https://stripe.com/jobs/listing/backend-api-engineer-core-mo...
No single language is named! And this specific sentence is a really great sign (unsurprisingly)
“Languages can be learned: we care much more about your general engineering skill than knowledge of a particular language or framework.”
I think that in the specific case of Stripe, they specifically mostly use Ruby (from answers I found online). I may be wrong, but I assume that not mentioning Ruby is a way to attract Python/Go/C/etc. developers that might otherwise think that since they don’t code in Ruby, they shouldn’t apply.
Your main point (re: Java) remains of course.
"We mainly use [language X], but you don't need experience in [language X] for us to consider your application" - this is a totally normal thing I've seen in many job postings.
Stripe is sometimes more explicit about it:
https://stripe.com/jobs/listing/infrastructure-engineer-ruby...
"Our most popular language in the company today is Ruby, and we are building a new Ruby services practice in support of this."
... but that job is also an openly Ruby-centric job.
You can't just go around telling people that: you are going to make hiring harder once everyone figures it out!
When you get a referral for a 10x and you're meeting at Blue Bottle you need an ice breaker; clueless community-college tier HR asking for versions of frameworks makes for an excellent one!
It doesn't matter :-) such organizations aren't good at finding out if someone is "talented and bright people with mastery of CS and SWE" in any case
Learnability is totally ignored.
It is terrible for inexperienced developers eager to learn on the job as is common in other industries or was in ours in the past.
It's terrible you're an experienced developer that is able to pick technologies quickly, or just wants a proper work-life balance.
It is terrible for developers who are deeply familiar with the technology but expect to work with a team of professionals, rather than with "walking set of tech keywords".
Software engineering is at a schizophrenic point where it is very hard to categorize in either of traditional "blue collar" vocational job (given people seem to be employed close to very little formal schooling) or as a "white collar" professional job (given some roles need a CS degree level understanding of the fundamentals).
Some roles are more the other than the other.
I'd say listing a very specific tech stack signals the employer is looking for "blue collar" "commoditized" labour.
White collar "professional" types probably feel treating their contribution as "commoditized labour" is a category error.
The majority of useful education comes from mentorship and on-the-job experience. Sure, you can get a formal education, and sure it helps, but it doesn't make you a useful software engineer. It just gives you a foundation to build upon through mentorship and experience.
In GP's case, the arbitrariness originates from their potential employer not taking the effort to really evaluate GP's relevant skills in software engineering, but instead resorting to lazily ticking boxes on a checklist. And what's on the checklist isn't even particularly relevant.
What I imagine this does to GP's view of the world (based on what it would do to mine) is: "I believe I am competent because I've built up a set of subtle skills in software engineering over many years, and this is what I take pride in. But from an employment point of view, this is wasted time: I should instead have focused on optimizing the checklist (and I only found this out after years in the industry)."
If what you mean is that it can be rewarding (intrinsically and extrinsically) to think about skill, craftsmanship, and other ways to make your labor a great value add, sure. Most of us benefit by thinking about that.
If you're really asking about why keywordification is a problem, well... keywordification of job roles indicates a way in which companies are quite possibly struggling to actually model the roles they're hiring for and identify what makes make an individual productive within them.
This happens on at least two levels:
1) Technological. Engineering decisions are sometimes "we have a specific problem, specific tech is the solution to our problem, therefore we need expertise in specific tech." In that case, the keywords regarding that tech are meaningful. But for non-trivial use cases, engineering problems are very, very rarely just that, they're commonly the aggregation of off-the-shelf + consideration of how to mix them with what tradeoffs + in-house custom solutions embedded in an organization attempting to understand and model its domain problems and fit/reshape all those solutions to those models. This is not exactly a keyword-driven process. Keywords represent the shallow end of the pool.
2) Human. While labor clearly is something bought and sold on the market, even from a point of view of a value system which is OK thinking of humans primarily as industrial inputs, it turns out that's a significantly leaky abstraction and most of us have all kinds of "compiler flags" or other inputs of our own that make us more or less productive. Some might consider this to be too warm and fuzzy; they might find it comforting that it can be approached from as a-humane and manipulative point of view as one might approach tweaking a database to get it to perform better: https://www.youtube.com/watch?v=HkFztAgK-8U
As for whether it's OK to think of humans primarily as inputs to any process on a moral level... like Terry Pratchett's character Granny Weatherwax said “Sin, young man, is when you treat people like things. Including yourself. That’s what sin is.” What are the consequences when social institutions consideration human beings primarily as inputs to institutional purposes? Generally, individual life, liberty, and pursuit of happiness become valued less, and individual suffering is more freely disregarded. Not super desirable under my value system. YMMV.
How did you pivot after this?
It's a contrived example of course (particularly if the end goal was just to check the "knows feature X from C# 8" box!) and I wasn't at those interviews so I've no way to know what their intent was. I'm occasionally on the other side of the interviewing table though so I'm just trying to reason through why this might come up. FWIW I hate the "what isn't in a linux inode" type questions, or situations designed to fuck with the interviewees.
"No, I'm not familiar with this, but I have done [market themselves, mention relevant experience, ask relevant questions] and I'm confident I can get the job done"
First probe is if the candidate doesn't have slightest clue what version they were using, that's a big red flag. This is more common than you would believe.
Second probe, candidate knows, but they only used a 25 year old version (also more common than you would believe when it comes to c++), this can be a warning flag that they are not interested in learning new things. But doesn't have to be if it was company policy, which is also interesting if they were in position to change this.
Third probe, ask follow up questions on differences since version N-1, this shows if candidate is staying up to date with latest trends or not.
https://clairehu.com/2014/02/18/a-little-bit-of-slope-makes-...
At least a few years ago, Google made it a point that the interview process was generic, not specific to any position or team. More like an undergraduate admissions process.
I read your comment and I was thinking in my head...wow, five seems like a lot, and then I realised that even these places I liked went pretty hard...I think they call this conditioning.
I didn't get either job btw, the work was trivial but I get terrible interview nerves so tanked both of them...in both cases, I also had a 6-hour take home...the results of which were largely ignored. Neither company is ever fully staffed...ofc.
If I talk to HR on Monday, take a phone screen with an engineer on Wednesday, and come on-site (or Zoom now) with 4 engineers next Monday, that’s 2 rounds and 5 interviews (or 3 and 6 if you count HR)
My experience has been that if you clear the engineering phone screen the company asks you to go through all the rest of the (4-6) interviews, even if your performance in one or more of them has been sub-par. And at least here in India the post-screen interviews are spread out over several days to 2-3 weeks - there is no "onsite" as such, even over Zoom.
This is going to become more and more common though. In fund management, there has been a huge move towards "professionalisation"...which, ofc, means doing lots of pointless exams that select for the wrong thing. MBAs are the same. It is very hard to solve because the system selects for people who will play into this self-image (in my experience, this isn't solvable...you can either handle the risk of being wrong or you can't).
This also overlaps with a lot of the issues that a lot of companies are having with hiring. A company which frames hiring as a risk rather than opportunity and has these very long, negative process of hiring (be real, the point is to uncover "weakness", not learn more about someone) is going to fail to hire people of different backgrounds. The amazing thing about the "candidate shortage" is that it isn't more severe. Companies are so bad at hiring, it is surprising they end up making any decisions at all.
Instead I think companies, especially large companies where small numbers of employees aren’t a massive proportion of spending, should try to see the potential for upside more. Especially in a world where everyone does a similar interviewing process, a candidate who performs poorly at those interviews could be cheap and an excellent hire who is undervalued by the market because of their poor interviewing skills.
Something is going to have to change - really a lot of things. One of them is going to be that companies need to learn to figure out how to hire people without putting them through a grind-fest. Figure out how to deal with bad hires after-the-fact, but don't let yourself get screwed not hiring good talent because you made the interview process a giant pain in the ass to catch the crap.
Oh and compensation needs to go up to make some of these interview grinds worth it.
And that's the rub. Not only do they struggle to value my skillset, they also can't compensate it accurately. And sadly, FAANGs don't even have the roles in a lot of niches.
When you can make 3x what a FAANG would offer, annually, but the companies building in your same niche are too immature and pay 1/3rd of what FAANGs do, its tricky to want to tolerate any of it!
Given how many ways there are to do that and much more, I would like the structure of someone else’s idea to focus (aka being an employee). Doing things solo has overhead costs and liability risks, whereas employment has almost none but half to 3/4ths of your compensation is withheld the whole time. So there is a limit to what comp I’ll accept, given the opportunity costs. Would be great if that comp was FAANG level.
Can you share some things in the past that were easy money that netted you $1.5M in a year? I'm genuinely curious.
I used to have a ton of ideas that I thought if I did everything right I could've maybe made $300-600k. But then you can just get that as a paycheck at FAANG.
None of my ideas ever were easy and could realistically generate more than that. Plus there was always a risk they would generate $0.
Hm, worst case, people on HN debate an irrelevant understanding of what I say is possible
Best case, they copy it en masse and dilute the opportunities faster
No thanks
I would take $500k doing the same stuff for a tech employer but nobody is offering that right now. Some contracting firms do, kind of, don’t really want hourly though and also want the benefits. I want to focus on someone else's visions, get paid on days off, no risk. Also want a ton of equity I wouldn’t go and purchase myself. Or private equity that I wouldn't have the opportunity of purchasing in addition to an attractive cash compensation. (These are all things I could do in just frontend/fullstack work.)
Some smaller companies are going above the 125-150k range, to double that. But not quite and they’re still few and far between.
this is a thread about the conundrum of leveraging this experience without losing freedom or opportunity costs, not about being miffed that someone won't share how to make money, its like you all want to be scammed into purchasing an some youtuber's outdated amazon dropshipping masterclass.
> You can launch DAOs that automate anything these days and take a small percentage from the users of it. Just automate any small aspect of what people do and auto-liquidate proceeds for USD* so that you aren't accidentally speculating on anything, your users can pay for the liquidation too. > *Your oracle server/cron job can incorporate a broker's API to get actual USD, your DAO can only get surrogates such as USDC which is redeemable 1:1 for USD at certain brokerages.
> It's a boom town. Anybody can make 3x more than what a FAANG would pay annually, and that's being generous.
Nothing changed regarding that one as far as I can see so interview processes getting longer isn't all that surprising. After all that's one surefire way to optimize for getting desperate people.
Finding your own clients doesn't start looking as bad, and a discussion to see if you'll work together is much better than an interview.
This is ageism. I hope he realized this after 10 6 rounds of interviews.
https://news.ycombinator.com/item?id=19507732
Like I said, not to invalidate anything, these experiences are so common amongst the whole pool that it has to be weighed accordingly.
(Not everything people say online is true.)
It wouldnt take me 700 hours to get familiar with all the abstract problems and concepts I’ll encounter, but it would take me a very long time to, and longer to synthesize solutions that are above average, and regurgitating that on the spot for an interview in a quicker time than other candidates.
The idea is to drive out older, less-pliant potential employees, in favor of newer ones, who can be molded into a shape the corporation prefers.
Have you ever seen a couple that has gotten married later in life? Many times, it may be a second (or more) time for one or both of them.
They need to make massive compromises. Both have gotten used to supporting themselves, and keeping their own counsel. They generally both have a lot of property, maybe grown kids, careers, etc. Usually, they don't actually need each other, for more than emotional support. They each do fine, on their own. It's a relationship of equals.
It can be a challenge to make it work, but when it does, it's amazing. I have known many couples like that.
I understand why corporations don't want to put effort into working with older folks, but it can be well worth it.
So many times, when I see these awful, Jurassic-scale disasters, made by companies that are staffed exclusively by younger folks, I say to myself "That was a really great idea, but they completely pooched the release. Why didn't anybody raise any red flags?"
The answer is generally, that no one on staff had enough experience to understand the ramifications of many decisions, and often, they were afraid to countermand ideas put forth by their superiors.
Couple that with 20-something CEOs, who are often fearfully insecure, and you have a recipe for disaster.
People never got any smarter, but the nature and details of group activity have changed over time.
After a career of delivering products for boutique manufacturing companies, I'd say that my ability to pass a modern interview suite is essentially nil. My last gig for a company with modern practices taught me that it's no fun in any case as design devolves into manufacturing (perhaps for good reason).
Give me a young body, and I'd look into purposefully arcane careers with little remuneration. Blacksmithing perhaps.
https://reddit.com/r/dataisbeautiful/comments/p1ba3t/oc_visu...
That said, for whatever reason the startups that tried to be intermediaries (and also various recruiters) tend not do very well in my experience.
I've noticed though that as I've gotten more specialized to compilers and programming languages, my application experience has improved significantly. It's not a large sample size but the last few processes I've gone through have been fewer interviews that usually involve going over a project of mine or doing a problem that's related to compilers. It's really refreshing to have an interview where I actually learn something about my field of interest during it. I know that doesn't scale because we shouldn't expect compilers knowledge for junior compilers jobs but it's a very nice change of pace for me.
more competition = worse time for you
Currently I'm going through the interview process with a ton of companies (because my company is really dumb and is forcing everyone to move back to a certain bay area city post-covid), and I have been happily surprised to find that most of my interviews are very practical, project based, ones instead of straight whiteboarding leetcode problems. I've received several take-home projects that are followed up with a simple add-on interview to sit down and explain the choices made during the take-home. They have all been specifically focused on domain knowledge to the mobile platform that I'm interviewing for. Its really nice! I hope this trend continues.
That said, I am still reviewing leetcode problems for the stupid faang interviews I have coming up as well.
This was after a 10 minute conversation with the company's recruiter. To top it off, nothing in the job listing said anything about software. Just Cloud and Devops management role.
I am absolutely ok with take home or some presentation of my skills. However, I expect to know that I am being taken seriously as a candidate by that point. I don't want to waste my time on something with no investment from the company.
As you can guess, I bowed out of the running explaining that I didn't think it was appropriate for me to give them so much of my time with no commitment from their end. I also told them I could tell their take home project took them less than 5 minutes to generate for me as it was everywhere on the internet. How can I trust a process where the answers to the interview are everywhere? How can they really know my skills as a candidate if I can just steal the answers off of GitHub? Worse, how can I know how I will stack up to someone who might be less scrupulous than I and steal those answers when I tried in earnest and actually burned an afternoon trying to solve their test?
Look, a lot of people have good-looking CVs and can't code shit. I don't know about you but my experience was that one really can't hire based on CV alone. Also, I've seen "architects" that are smart and fairly knowledgeable people that failed to code very very basic stuff (as in, merge 2 sorted arrays).... I get it that at some companies you are expected to draw diagrams in Confluence as a main job, and might no longer have actual coding skills; but we want even the most senior people to actually code, and that doesn't seem unreasonable to me. So just because you're a very-senior FAANG employee doesn't automatically mean you'd be a good fit. I'm not saying they're bad employees, but maybe they just wouldn't be a good fit and wouldn't enjoy the job if they expect to just design stuff instead of actually implementing, too.
If I applied to 10 companies, and every single one of them asked me to come onsite for whiteboarding as the first step, that would also suck tremendously, but at least it would be limited in scope by the employer's time as well. As it stands, arbitrary companies can expect a large time investment without any of their staff ever having to speak to anyone.
I'll take a calculated stab at Amazon's once every 6 months I guess, because if I pass (which I haven't) I can potentially earn a hell of a lot more than any other place. I get it, whatever. If every company is doing it (they are)? I might just leave the industry if I can't find a way to be specifically good at remembering the implementation details of every data structure and algorithm. Sucks to be someone with pointless skills I guess.
The longer a candidate has worked on very capable teams the more surprised they will be to have those problems presented in a job interview.
Besides, if someone is duplicitous enough to have a good looking CV and no coding ability, what's stopping them from just cheating on the HackerRank?
TBH that's another argument I don't really get. Almost everyone agrees that basic CS knowledge trumps specific technology knowledge (I'd rather hire someone with strong CS fundamentals that didn't use Java before than someone who is a "Spring Boot expert" but lacks basic CS knowledge, even if I actually use Spring Boot right now).
But then, why complain that you don't do that in your work? Surely you need to traverse data structures from time to time, yeah it won't be the exotic tree traversal that I'd ask you to write but that's exactly the point - to test that you can be put in a novel situation that can't be directly-pasted from StackOverflow and you're able to write a recursive function that takes _a little bit_ of skill).
The hidden test case is opportunity for discussion during actual interview. And this answers your "what's stopping them" question, too - regardless of problem, I can tweak the input slightly so that your solution doesn't work - and more often than not, I don't even tweak the input, I just provide an additional testcase where your solution doesn't work. If you can quickly fix it ("oh, yeah, I forgot that URLs may have a fragment appended to it, let me quickly adjust my log-parsing condition") then it's awesome, it's exactly the signal I'm looking for, and we can go on to discuss system design and your relevant experience (but honestly, at that point my mind is likely ~80% made up, from CV + how you explain/modify your hackerrank solution).
1) you're expected to spend 3 or 4 hours on some HackerRank test before you've even spoken to anyone. Some of these tests (outside HackerRank) can actually be projects that take a day or more to get right. The issue is that at this point I don't know if the attitude is "hey, this seems like it might be a good hire, let's check if he can actually code" or if it's "let's send anyone this test and discard anyone who doesn't pass". I suspect that in a lot of cases it's the latter. I'm not opposed to investing time, but it quickly becomes unmanageable if everyone just asks you to pass their several-hour tests just to be considered for application. There is very little time investment from the company, and it feels almost like a dDoS attack on my time.
and 2), that a lot of these tests are asking you to solve some hard problem that you will rarely face in real life and where people have quite literally won Turing awards for finding solutions to them. Many previous discussions about this on HN in the past.
I don't think it's even all that much more effective at actually weeding out bad programmers than a simple test. We used to ask people to write a CSV address book importer with some very basic requirements; nothing fancy, you could do it in 30 minutes. It worked well enough, and a lot of the results we got back were horrible.
I am not one for LC type of problems, but at the least I have to admit they have the potential of being more objective than everything else during the interview process. You get the specs, you write the code and it gets tested via multiple test cases. It does not matter if the interviewer agrees your solution will work or not, and the interviewer won't have to copy&paste your code, compile and run it (like someone else mentioned in this thread).
On the other hand, what I particularly dislike about the LC problems is that many of them are essentially trick questions and brain teasers. Can't we just stick to problems that are relevant to an SWE?
The tech test seems often like it's cargo cult. It's on Joel's list so everyone thinks it is a must do. Instead of realising that the entire point of the tech test was to make sure people could actually code. With some of the original tech tests being do FizzBuzz or do something really simple in a short amount of time. Not, build me a production ready toy project using techincal DDD aspects.
Of course. But consider how that attitude looks from the perspective of a candidate - you'd rather waste my time that yours is a really good reason for me to drop out of the interview process.
This is essentially what's wrong with hiring right now. Companies don't want to have anyone "waste their time", so they have many levels of filtering to reject candidates as early as possible while doing as little work as possible to make hiring good for candidates. In other words, companies have largely forgotten that candidates are people, and wasting anyone's time is a pretty bad idea.
I think sometimes people forget people working at these companies are people too and noone wants to have their time wasted. This isn't companies deciding these things. It's people. It's the person on the otherside that doesn't want their time wasted.
It's a risk mitigation strategy.
[0] Data Science Playbook, Booz Allen Hamilton https://www.boozallen.com/s/insight/publication/data-science...
If you want a backend engineer - book a few hours, even on a weekend, set up an IDE and get on a real world project. No bullshit. Build a small API to these requirements, using these technologies but take care of edge cases and deploy that bad boy.
I’m guessing not.
It’s poorly designed and/or poorly implemented hiring strategies that lead to bad hires, mostly through a lot of noise being collected during the interview process.
This is a very solvable problem.
Edit: I will add that this is an ad for Booz hiring, so of course they want more process.
* Phone screen with recruiter that reached out to you
* Screen with the hiring manager
* Behavioral interview with multiple peeps
* Code pairing session with multiple peeps
* System design session with multiple peeps
So AT LEAST 5 hours time commitment just on interviews. Add time to research the company, its employees, and etc. Maybe the code pairing is instead an at-home test of some sort. This could potentially add hours(or in the case of Teleport like 20+ hours). Just engaging with a handful of companies was a huge amount of extra work and stress on top of existing responsibilities.
I pulled out of three voluntarily and declined an offer from the last for various reasons, opting to stick out till my RSU cliff in October. For the next round of engagements I may start toying with filtering out companies based on their hiring process as well and giving push back on it to see what happens.
I did actually tell one that the schedule of phone interviews (2) and video call rounds (4) was too much commitment without more details about the role and salary range. They responded with "if that's too much commitment the position is too".
Dodged that bullshit!
Technically I was qualified and able to answer their questions. But ultimately was turned down after 6 rounds of interviewing. I think I was heavily dinged because I wasn’t entirely familiar with their product in the wild, and was never given any hint as to what product I would be working on.
I also disagree that interviewing is not a technical challenge. For most programmers it is. There are very few who can breeze through FAANG-level technical interviews.
The only reason why I'd come somewhere is if I like the engineers or if I'm in need of money. If I need the money, I won't ask a thing.
I understand the reasoning: if you think you have a special mission and want people dedicated to that mission, filter by dedication. But I'm not really sure there is a way for any one candidate to consume as much time interviewing for a role as that company could consume out of a pool of candidates. And that includes my smart-ass idea of trying to interview at Pinterest and stopping in the middle of the interview saying "please sign up to see the rest of this whiteboard solution".
https://www.linkedin.com/posts/mike-t-conley_jobhunt2021-lea...
(Not previously discussed on HN best I can tell.)
It's common for there to be some uncertainty with one or two of these things, but if there's a lot of uncertainty, you are being strung along. Best case they are waiting you out trying to find a better candidate, worst case they don't even have the budget for you and are playing politics within their company using you as leverage.
Interview multiple places in parallel, and don't cancel any interviews until you've got a signed piece of paper. But of course, prioritize the ones that aren't jerking your chain.
This is a typical HR strategy to keep themselves busy so they don't get laid off. HR is not a revenue generating department, so even if they aren't hiring, then they still need to push paper.
If candidates have less time for interviews, they will have less offers/counter offers to use as leverage
Both sides of the technical recruiting transaction (job-seeking and recruiting) exhibit these behaviours and tendencies (what to wear, how to format resumes, presentation, side projects, for seekers, interviewing, tests and screens, and other filtering practices for hiring teams).
The consequence is a tremendous amount of friction, inefficiency, and fear-driven lore. Some years ago a senior Google staffer commented that they'd found a guaranteed hiring heuristic: "No". That is, reject all candidates.
My response was that if this was serious (and it was at least partially), that this was a profound sign of weakness within Google: an inability to seek out and onboard talent successfully.
There are other possibilities.
It could be that the notion of private firms hiring highly-skilled talent is inherently flawed.
I've speculated that one of the justifications for the ancient Egyptians to build pyramids was as a combination of a skills-development, skills-retention, skills-demonstration, and brain-drain-mitigation programme. From what I've read there's at least some independent informed speculation along similar lines.
One of the functions of writing a book, a notoriously unremunerative practice, is as a credible signalling of skill and ability. (And of book-writing capabilities, for what that's worth.) Books are very fat sales brochures.
In a tech world in which typical tenures are measured in months or single-digit years (2--3 years being typical from what I understand), and correlations between any hiring practices and actual performance ... at best weak, there's an inherent issue.
There's also the question of equitability of a process in which employers have vastly greater access to information on individual prospects than prospects do on companies or hiring managers / management teams. George Akerlof's "Market for Lemons" suggests that more information makes markets more efficient, though my fear is that highly asymmetric information access further tilts the employment market in the hiring firms' favour.
https://www.jstor.org/stable/1879431
http://libgen.rs/scimag/10.2307%2F1879431 Some of my earlier fad/information theoretic musing here:
https://old.reddit.com/r/dredmorbius/comments/62uroa/clothin...
Brain drain mitigation? Brain drain just wasn't a possibility 4400 years ago.
Pharonic Egypt circa 2580 was not without neighbours and there was both trade and warfare in North Africa and across the Levant and Mediterranian, notably with Syria, Canaan, Lebanon ("cedars of Lebanon" are a significant reference, as Egypt had virtually no timber), Ethiopia, and Nubia, amongst others. There's also the prospect of defection to internal factions. The Old Kingdom seems to have been generally peaceful with little internal or foreign warfare, at least until the First Intermediate Period, which was largely an internal rivalry. But it wasn't entirely without defence concerns.
https://en.wikipedia.org/wiki/Ancient_Egyptian_trade
https://www.worldhistory.org/Egyptian_Warfare/
I'm very happy to admit that my hypothesis is just that, and that there's no evidence and only a very little external support, though there is some. But if you're going to develop an advanced skill that would be of use throughout the region, it might be advisable to find ways to hold on to it, and as a pragmatic explanation for what was an absolutely immense effort ... there's some sense in the concept.
How? The only military use of large stone structures is as fortifications; their primary feature is that they can never move.
And Egypt isn't even known for its city walls. That's the other civilization of the time, ancient Mesopotamia.
But on top of all of that, none of that is a brain drain issue. You're talking about a hypothetical issue of loss of state secrets. Brain drain is the concern that the local population of skilled workers will all emigrate, leaving the country unable to do skilled work. It's not the concern that other countries may develop the technology to do the same things that you can do.
There's mathematics, surveying, architectural design, measuring, logistics, labour organisation, planning, transport, engineering, and a whole mess of related skills. If not kept in practice, they are lost (you're focusing strongly on the "brain-drain" element at the expense of "skills retention" and "skills development bits).
Too: once you've got those capabilities, there are numerous other abilities which derive from them. Large structures means civil engineering, construction, grain storage facilities, and quite probably some degree of metalworking and related crafts, again, which can prove useful in either foreign or civil war.
Take some time to think through possiblities, consequences, options, risks, and opportunities here.
Well, yeah. Look at my comment, in its entirety:
>>>> Brain drain mitigation? Brain drain just wasn't a possibility 4400 years ago.
If you can't defend that, then... don't? Make the argument that isn't obvious nonsense; you don't get more credible by throwing in a laundry list of "concepts that sound bad".
> There's mathematics, surveying, architectural design, measuring, logistics, labour organisation, planning, transport, engineering, and a whole mess of related skills. If not kept in practice, they are lost (you're focusing strongly on the "brain-drain" element at the expense of "skills retention" and "skills development bits).
There would have been no lost opportunities to exercise these skills in the absence of pyramidal efforts. They built temples, palaces, and cities on a continuous basis. Surveying is a constant need of anyone who collects taxes. (And it's particularly important in Egypt, where everyone's property lines move every year to match the extent of the flooding of the Nile.)
As far as I've read, the Old Kingdom pyramids stopped being built when the colossal economic strain they involved nearly collapsed the state. That doesn't suggest that they were useful in employing otherwise idle technicians. It also doesn't suggest that the system governing them was especially capable at logistics and planning. Planning would have involved noticing "this pyramid will cost X amount to build, which is more than we can afford".
> Large structures means civil engineering, construction, grain storage facilities, and quite probably some degree of metalworking and related crafts
I think this is backwards to a certain extent; I'd run causation from grain storage -> large structures, not the other way around.
You're the one constructing a far more magnificant pyramid of this than I'd ever intended.
I suspect that these companies have structural problems that inhibit their decision making. Possibly also personal problems.
I also suspect that if they can't say yes after a third interview then the candidate is non-judgmentally not a good fit, by demonstration. Both parties should consider that.
Sans all of those qualifiers, anything more than 3 rounds is a deal breaker for me. If you don't know if I'm the right fit after 3 hours, verifiable experience, a public body of work, and a list of references, then your company culture isn't a good fit for me.
Every bad hire costs the company $50,000 - 200,000. Sometimes more. They can also sink or demoralize teams.
Many of the people conducting interviews are new to the process and don't know how to extract signal. Sometimes scales don't line up.
When you have a revolving door of employees (because that's the way things are these days), have trouble scheduling interviews (busy engineers trying to get their own work done), and can't get enough skilled interviewers on a panel, then of course the process will be a suboptimal experience for candidates.
To a degree, companies would rather a good candidate was passed over than a bad candidate was accepted. Type I and II errors.
Companies also don't like telling candidates how they did because that opens them up to lawsuit liabilities.
You have to do enough interviews to get signal yet not piss off candidates. (Or your employees in the interview pool!)
It's a hard problem for companies too.
Why is nothing done about this? As turnover soars and tenure plummets, I am willing to buy that companies do not value codebase knowledge, domain knowledge, or believe that it takes time for an engineer to get going. I can buy them seeing us engineers as replaceable widgets.
But we are at the point where a lot of companies cannot replace us and yet nothing is done about the endless parade out the door. The focus is entirely on shovelling new people in.
Chances are, the new hire replacements will be in the same 90%, so it is a wash (minus ramp-up time), but maybe the company gets lucky and finds someone in the other 10%.
And if you have a revolving door of workers, that suggests something else is wrong. Maybe you should focus on retaining existing workers rather than acquiring new ones.
You say that a bad hire is worth tens of thousands of dollars, but if that's the case, then most of what you said is irrelevant because a company that is smart enough to recognize this would be smart enough to never put a junior manager in a situation to make a terrible decision.
You would be shocked how many people blatantly lie or overstate their roles on resumes. Senior, junior, it happens all over.
A good practice is to ask candidates to go in depth about recent resume items and explain the technicals, business needs, etc.
> If someone is new to the interviewing process, then they shouldn't be doing interviews alone.
Most don't. But are you really calibrated after five interviews? Ten? And what about all the other folks that need to shadow / train?
If a manager is getting paid $150K a year and it costs $200K to fire a bad employee, then "when they're ready" is the correct metric to use.
I have seen a fairly small amount of employees hit the lower end on a singular dining bill when they had a company card and were meeting with business partners they were trying to "impress"
(obviously, the joke is free nice food and drink for all involved at the companies expense)
If you were fickle you could perhaps justify that as priced in to keeping good relations... but in the same light I'd call your figures priced into the talent acquisition process.
If I submit some “open source” code as some proof that I can code, how do you know I didn’t copy the code from somewhere?
Also, writing code for the sake of writing code doesn’t tell a hiring manager if the person can take requirements and translate that to an automated process. It just say that person isn’t that busy and can, excuse my language, shit out code for the sake of appearing productive.
Writing code can be a hobby, sure, but that’s only a small part of a software job and no amount of open source code can tell a company if the candidate can work with others and solve problems.
Balderdash. When was the last time an interview task involved working with others? I'd offer that open source PRs show this way better, and in an appropriate context (as a collaborator) rather than what we have now: adversarial interview{er,ee}s.
You can ask your candidate to explain the code... Is that not obvious?
> writing code for the sake of writing code doesn’t tell a hiring manager if the person can take requirements and translate that to an automated process
Kind of sounds like you don't know what open source software is.
> excuse my language, shit out code for the sake of appearing productive
I won't excuse your language. You sound like you're part of the problem buddy. I don't think you have any idea how to evaluate a programmer.
Asking about projects is the obvious thing, but only substantial and interesting projects really provide any interview value. Yet another Todo app doesn’t fit that criteria. Neither is another scaffolded crud app.
A PR to fix a bug in a semi-popular library is worth. But saying “I have a lot of repos” is def not.
> saying “I have a lot of repos” is def not.
When did I say that? I didn't. They should be looking at the repos and asking about them, not just taking your number of repos and using that as some kind of metric.
If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html and taking the intended spirit of the site more to heart, we'd be grateful.
Usually it’s “I wrote some code and put it on GitHub, call it open source”.
> writing code for the sake of writing code
> It just say that person isn’t that busy and can, excuse my language, shit out code for the sake of appearing productive.
It sounds like you have a serious misunderstanding of open source at a basic level. It would have been questionable enough in 2000 but I’m not sure why anyone in 2021 would think that way.
Hell, I have public code on GitHub, but I’d never put it on my resume.
And this takes me to my 2nd point, and that is they current hiring model totally leads to companies hiring people who are good at interviewing not necessarily people who are good at doing the work required. There is no doubt t that interviewing for a job is a skill that can be learned and improved upon, and lots of crappy programmers have learned to be damn good at being I interviewed.
If you run a company and you have a "revolving door of employees" (ie: we can't retain talent), your managers "are new to the process" and don't know what they're looking for (ie: we hire inexperienced managers), and you "can't get enough skilled interviewers on a panel" (ie: "we don't hire enough engineers and we're too cheap and shortsighted to put them on tasks like hiring")... then yeah, you should expect your hiring costs to go up, have a revolving door of employees (because you don't know how to hire), and your teams to be demoralized.
The consequences of that are your (company's) fault. You should own up to your shortcomings and work on your hiring process... don't just punish the candidates indefinitely so that you can ignore your problems.
(I say this as a serial founder, and hopefully never need to be on the other end of the hiring process.)
I’d like to add time aspect as well. If selected, candidate will spend next 12-18 months with the team, 5 days a week. I look at those 5-6 hrs as worth an upfront investment from both the sides just ensure those days months aren’t miserable and you don’t end up parting ways on bad terms.
I’m saying this as an interviewee as well as hiring manager who has conducted more than a thousand interviews.
Nothing frustrates a team and hiring manager more than a mishire. It’s the same for candidate, they have to go through the charade of interviewing at tens of places again.
You have two ways to solve this problem:
1. Figure out what makes your employees keep leaving.
2. Hire people who are not good enough to work elsewhere.
2 things that line hits me.
1. Remuneration. If I can jump ship and come back later to much more money, why not?
2. I work to make myself replaceable. This is what good documentation, code comments, architecture is for!
* See the advert online, and send an email/fill out a form to apply.
* Have a quick phone-chat with a HR-person, where they ask about salary, history, and try to decide if I'm a chancer, or I have some somewhat useful skills.
* Have a 30-60 minute interview with some technical people, in-person.
* Optionally have a second interview with a tech-lead, or somebody else higher up the chain.
* Receive offer, rejection, or get ghosted.
Smaller companies sometimes have different processes. More than once I've sent an email/CV in to apply and been invited out for beer/food, and received a verbal offer the following morning. No other interviews, or tests.
Thought your comment was interesting, so went to check out your profile.
That was also clean and well made, so followed through to your website.
Found this: "I published a simple tool to all your repository details from Github, self-hosted Github Enterprise installations, and other compatible systems."
Do you mean: ...to [pull] all your repository details
Since you have such a nice profile and everything I thought maybe you intended to include this word in there.
Hope this is helpful.
Somewhat related to interviewing and getting hired.
If it's in an appropriate comment for this threat then please remove it. @admin
I'll fix the entry you mention - as you suspected a missing word there.
Thought the beginning of your comment was interesting, so went to check out the middle of your comment.
That was also clean and well written, so followed through to the end.
Found this: "If it's in an appropriate comment for this threat then please remove it."
Do you mean: If it's in an inappropriate comment for this thread then please remove it.
Since you have such a nice comment and everything I thought maybe you intended not to make these typos.
Hope this is helpful.
I really am not looking forward to going through a formal interview process, because it will be so jarring compared to what I am used to!
Started with applications over a web form on the university careers website, then chatted over email with the hiring manager. Eventually got set up with some interviews with current lab people, and eventually the PI.
Mirrored in industry, although that was back in 2018. So all in all the “regular” route at least for this level of work in biotech/biology is pretty sane.
That being said, I’ve used your method in the past as well to great success, and is one of my secret techniques to get more traction when I’m looking ;)
If someone sits though 6 hours of interviews and pointless exercises that should instead be solved by consulting the documentation, they will probably just do what they are told without fuss, will work overtime for free and will let the company walk all over them with regards to sick pay, holidays, etc.
I was being interviewed for a principal engineer. I was very clear and kept saying I wanted a management track position. They kept saying we love your background we can work with you on this. Ninth interview was with the CTO. He said the same. Them ghosted. Wouldn't answer my emails or calls. 9 hours, plus prep time wasted.
The company I ended up getting hired by also did a large number of interviews, 8. And they took even longer. Just over three months from initial contact. They're fantastic to work for, but I do think there comes a point where if you keep digging you're going to find something you don't like.
I didn’t mind the way it unfolded — people were busy, I wasn’t working, and it was only a couple of minutes away from me, so really it was only perhaps 8 hours. But after three weeks I felt I wasn’t getting the answers I needed and they didn’t seem to be making progress on the hire. So I said no thanks.
This was a company with 50 or so people — I have no idea how they managed to hire them.
Google took 3 months. 1 month was from the virtual onsite final interviews to the Hiring Committee decision. It was a miserable month and even my wife hated Google by the end.
Second was for a Director of Engg position at a mid sized company. It took 2 months and finally I had to force them to answer. It was a company with weak leadership and it showed in their inability to make a decision.
I don't know these things well enough but it makes no sense to me. For starters, in the tech sector in my country the salary for fresh grads like me actually come mostly from the government. Moreover, these companies are all secretive about compensation, and they probably think they can get away with it by dangling their "reputation" in front of you like a carrot. In most cases the salary is about the same as a small startup because, again, they get the money from the government.
People can argue about spending time and resources on training and what not but basically every job ad, from "top" companies to the web dev garage down the road, expects us to learn by ourselves anyway?
It's frustrating for early career starters that most of my friends and I are going through. It's such a huge waste of everyone's time and people are just churning because of this crap. Please get rid of non-technical HR and interviewers.
Sorry for the emotional rant. I would really like to know what risks (other than useless non-technical HR keeping their jobs) there are after candidates have past a certain threshold for quality, particularly for junior positions.
[0] https://news.ycombinator.com/item?id=27881668
It's harder to deal with emotional kids than it is to deal with incompetent engineers. Maybe that's why those non-technical HRs might not be as useless as you think.
It's harder to deal with people who think they are competent and know it all than emotional kids.
And that's a risk that could potentially be spotted by a competent HR.
> It's harder to deal with people who think they are competent and know it all than emotional kids.
Maybe, but juniors are (unfortunately) seen as a commodity by the market. Commodities are about uniformity and adherence to some standard, rather than uniqueness.
It's a risk that could only be spotted be HR, don't know about the "competent" part. There would be no emotional-kid risks to speak of if it weren't for useless HR.
> Maybe, but juniors are (unfortunately) seen as a commodity by the market. Commodities are about uniformity and adherence to some standard, rather than uniqueness.
It's making even less sense now. If we are commodities and it's all about uniformity and standard, why do we see senior engineers complaining about this, too? It also makes no economic sense to spend so much time and effort on elaborate bullshit on "commodities". I don't mind being a commodity if the standards that you speak of exist, and I don't want to be unique. But guess what? It's the HR that wants us to be the unique commodities.
Someone without the required technical chops can be useless, which isn't good, but these people can be worse than useless as they can derail and/or demoralize an entire team. I've seen it happen; it's not pretty.
This isn't unique to younger people, but in my experience the risk is quite a bit higher in younger people. I say this also as someone who, in hindsight, was quite difficult to work with when I was younger for various reasons. As I've grown older, I've learned a thing or two and I think that now I'm actually a fairly nice person to work with (I hope so, anyway...)
Everything else being equal, I'd rather take someone with a 9 (out of 10) on soft skills and a 6 or 7 on technical skills, than someone with a 3 or 4 on soft skills but a 10 on technical skills.
I agree, I've even had to reverse my own team's policy on this at work : I used to think the technical stuff was the most important and pushed my team towards hiring exclusively the technically smart people, but I have been proven wrong over and over again by those "smart" engineers I vouched for.