The developer job market is insane
old.reddit.com
old.reddit.com
1. There's a lot of risk aversion in corporate culture these days, the cost of a bad hire can be very high and nobody wants to be held responsible. By having multiple rounds - which in turn requires a lot of people involved - responsibility is diluted so if there's a bad hire you can blame the process rather than one manager.
2. It's an endurance test. Someone who can power their way through round after round of interviews, home projects, online tests and so on shows good "work ethic" or at least a genuine interest in the job.
3. Cargo-culting FAANG. If Google or Meta do this, then we should too (even though we're a tiny startup). It's a bit like picking microservices or Kubernetes: there's good use cases, but for a lot of projects they are overkill.
4. Concern about discrimination: companies are scared of showing bias (whether against or for certain ethnic groups, genders etc) and a formal process should in theory be meritocratic than the old days of "let's just have a quick chat and hire based on gut feeling".
There's good reasons here, but it's probably gone to extremes, particularly for positions at smaller companies with corresponding smaller salaries and benefits.
While all valid points i do dislike how often those tests and interviews focus a lot on areas that you will not be doing in the role. This is where I see the biggest frustrations. When we hire we do try to tailer the interview process in a related to the work involved as possible. It adds confidence that we have hired the right candidate for the job.
Also, even with a probation period, a bad hire can damage morale and waste a lot of the team’s time.
If I'm unemployed and I have bills to pay, a paid probation period is the better option - even if I get fired after 90 days, that's still 3 months' salary. On the other hand, if I already have a job, joining another company is a big risk - I'm giving up a comfortable position for a job I might lose in 90 days if it doesn't work out - maybe I'll be in over my head, maybe I don't get along with the manager or the team, whatever. A long interview process gives me plenty of opportunity to gauge my prospective employers and back out at any point.
Also onboarding is expensive: even an experienced developer who has all the skills you need still has to learn your codebase, processes, business logic etc. while drawing a salary, and all that goes to waste if they leave before they can start becoming a net positive to your company.
Probation in Germany goes both ways. Recently I worked there at a (small end of medium sized) company where work and pay was just so-so (nice, smart colleagues though). Then in a meeting the superior or my superior mentioned that there was some redundancy. Aha, I thought, I take that as a sign and promptly resigned some two weeks before the end of the probation period. They still expected me to come in 'til the last day, which I didn't mind too much, but still found a bit silly, since both parties agreed about the separation (also given the finite funds of that company).
Laws that benefit the company, such as "right to work", mean that employers will often win lawsuits from former employees for things like wrongful termination suits, however companies would prefer to not be sued at all- even if they have a strong case. Court is expensive and a hassle.
That said, I did some moonlighting work for an employment law firm, and they say that they take less than 5% of the prospective clients who contact them, because they (and most law firms who only get paid if the client wins) want to be as sure as possible they will win the case. Of course if the prospective client were willing to pay up-front regardless of the case outcome, I'm sure most law firms would oblige. In such cases, I expect the former employers like to settle out of court to save time and money, even if the odds are good that they'd win in court.
I’ve only seen this approach fail once, and it wasn’t that big a deal, because very little time was sunk in to hiring the employee that had to be let go. At most a day or two was lost on-boarding.
If among promising looking and speaking candidates, few are actually good, then what will the current employees think about people getting hired, fired, replaced a lot
The 100% virtual hiring process means that it is much easier to sub out your interview as there’s no point in the process where you show up for an on-site, present your government issued ID, and then interview.
This is nothing new, it's just a media blitz by status quo lovers.
But what exclusive right does your employer have to your labor? That depends on your contract of course.
So if you signed away exclusive access to your labor, it's fraud. And that's not uncommon - there's often at least a "you will disclose other employment" clause in developer at-will contracts. That said, I think the only consequence of not disclosing is potentially getting fired with cause if you get found out. IANAL but I don't know of precedent for clawing back pay (which would be fitting for actual fraud).
If you didn't, then it's your employer trying to get more than they signed. And in that case, the lie is a necessary evil.
Full-time employees are salaried. They cost the same no matter how much work they do. So full-time employers want them to do as much work as possible. They view time as zero-sum, so any hours you spend on another job are hours you could have spent on them. Even if - as we all know - there are diminishing returns on hours and those hours at job 2 would not produce the same output if pumped into job 1.
So, as always, full-time employers resort to soft power and psychological tricks to exert control over salaried employees. And I'd say it's increasing lately because remote work as shifted the power imbalance and employers are realizing the other side of at-will, salaried employment is that employees can work as little for them as they can get away with so long as they are good enough to remain willfully employed.
They're all very similar, American salaried at-will agreements.
They say that
1. I must disclose any prior agreement that may affect my eligibility to be employed by Employer.
2. I must disclose any outside activities.
3. I am employed at-will.
(2) doesn't mean I can't have another job, but combined with (3) it does in practice.
Constantly acting confused after acing the interview. Never getting anything done and insisting on pairing with somebody else who just did the work for them.
Essentially the goal seemed to be to collect a paycheck for as long as possible until somebody noticed and you ended up fired. I heard variations of this from a few people and saw one first hand.
Asking a 21 year old about a recursive O(nlogn) algorithm solution or how many ping pong balls fit on an airbus because you heard Google asks it when all you need is someone who can write a good integration test suite, use springboot, and create documentation for the clients to make the API useable and scalable is such a weird way to go about it.
And it seems entirely based on "if FAANG does it, it must be right".
Been a while since I've been in an interview but everything has been cake since.
The only reason not to accept the first offer is because one of the other companies is that much better to work for. So the companies with the most onerous processes lose out on the best candidates or have to offer double the compensation to keep them in the maze.
The reality is that most companies can do fine with average employees. Bad hiring practices that lower the talent or increase costs don't kill them.
And the OP's own point "responsibility is diluted so if there's a bad hire you can blame the process rather than one manager" would be needless if the process actually did avoid bad hires.
So does that actually reduce bad hires (or increase good to excellent hires)? Probably not, but that's not really the purpose of all this theatre. The purpose is that if there's a bad hire, do I, personally, get the blame?
But the silly thing it, the convoluted interviews don't avoid the risk of a bad hire because they test for the wrong things.
The analogy I use is that it's like a hospital trying to hire a heart surgeon by extensively grilling candidates on trick questions about organic chemistry. I mean sure, the surgeons probably took that class a few decades ago prior to medical school. So they end up with surgeons that are wizards in organic chemistry but might well not know how to use a scalpel or know where the heart is.
If candidates can get an offer after only a half day, they may as well have a dozen options, and you only have a 1/N chance of getting picked.
Let me guess, are you an actual hiring manager?
That's an interesting take I haven't heard emphasized before, but it seems plausible.
From the company point of view that might make sense if they don't think about the consequences. But for the person, since we all know that usually any such projects are silently rejected without explanation it's totally not worth the effort.
Having been on the inside watching some people review take-home projects and arbitrarily reject them for the most random reasons ("I don't like the way he writes comments, what a loser") I also have zero faith on them being evaluated fairly.
The only way I'd ever consider doing any kind of endurance project for an interview is if the company guarantees results if I put in the effort. Could be something like: Write code to interact with and/or provide these well-documented APIs, it'll be run against a test suite where I can see the results and it needs to meet xyz performance criteria and if you can deliver it in X hours or less we guarantee a competitive offer. Only then would it be worth the work.
But to spend a lot of time just to be ghosted? Big no to that.
Companies should be hiring people on a contract basis to perform REAL WORK. This work should ideally be the very type of work they would be doing if they were hired full time.
If they do a good job, then great! Hire them on full time.
If they don't do a good job, but they meet the acceptance criteria of the contract, then they get paid, but don't get hired full time.
If they don't complete the contract requirements, then they don't get paid at all.
This arrangement is completely fair to both parties, and doesn't waste anyone's time. It's a win/win scenario.
Unfortunately, most companies are too lazy to set up a hiring process that looks like this.
I’ve worked in software for 40 years, had exactly one of these ridiculous interviews. Despite years of relevant experience I bombed it because I couldn’t guess something stupid like how many tennis balls fit into Chicago. Recruiter told me they hired a more qualified candidate. Then two months later I got a desperate call asking me to start tomorrow. The person who aced the interview couldn’t actually do anything. I told them to stuff it, I had already found a better gig.
I have refused garbage personality tests by saying those violate the ADA. Think about what position that puts the company in. And I’ve had offers even after flatly refusing Myers-Brigg or similar nonsense.
This shit keeps happening because people put up with it and play along.
Companies fear one thing even more than making a bad hire, and that's getting sued for their shoddy interviewing/HR practices. A complaint can trigger investigations and lawsuits from the state, not from the candidate. The ADA is sufficiently vague and comprehensive at the same time that it's a bogey-man for HR people.
Some US states already prohibit pre-employment background checks and credit checks. States should prohibit employers from casting nativities and reading entrails during the interview process as well.
When asked my Myers-Briggs "Type Indicator" I always say "Scorpio." Weird how so many rational and educated people fall for that bullshit. And yes, that's exactly how a Scorpio would behave.
That being said, I wonder how much of this is just that people who have a bad interview experience are more likely to post about it than someone who has a "normal" experience.
Like you, I had one interview, when I was fairly new out of college, where they asked me how many golf balls it would take to fill a school bus. I've had a handful of interviews where I've been asked to do some live-coding; these were all less than two hours.
I've never been asked to go through six rounds of interviews, or do a take-home test, or tell them which color dragon my code is. Of course, I intentionally avoid FAANG, which is where I hear about a lot of this dumb-assery.
Interviewer: "How much water flows through the Thames?"
Me: "Well, I sat next to the Thames once, and it's maybe 50 m across. Depth... I dunno 10 meters? Speed..."
Interviewer: "Actually... It's 100 m across and..."
I could see the interviewer realizing this wasn't the most relevant question to ask to someone not from the area. Perhaps they wanted that interaction, I don't know. A silly question that just dealt with local knowledge, and (in the end) very little modeling.
I played along, then sat in my hotel room and shook my head.
However, one of my hard rules is that I don't spend more time on the hiring process than the company does. I'll happily sit and talk to an employee for four hours, but I'm not going to do a "take-home test" for more than 10 min.
What a stupid thing to ask in an interview. Answering that would prove... what? That you can multiply and make some wild guesses about a geographic detail you aren't familiar with?
I interviewed for a job in Sweden a long time ago (I'm a US citizen). The hiring team took me to dinner, and I got the impression my future at the company (or not) depended on my willingness to eat every kind of fermented fish offered at the restaurant. They didn't ask me how many liters of water Lake Mälaren holds.
And if you are from Sweden you can ask back: how many IT people does it take to eat a single can of surströmming? It is at least as relevant to doing the job well and to mix with locals, isn't it?
"Where on the Thames do I measure the flow? And what time of day and day of the lunar month?
"What? I don't know that!" Then the interviewer plunges into the gorge of eternal peril.
Yeah, it was just weird. The interviews by the team in California were better, to be fair. (Though I still don't understand why they had to fly me there. The day after a 15 h flight across timezones, they spent 8 h giving me brain teaser questions. I was toast after that.)
> my willingness to eat every kind of fermented fish
That would have been my cup of tea!
At work you may be asked to spec out and implement a poorly-defined defined request.
They expected you to have asked clarifying questions rather than steaming ahead in the assumption that the Thames is 50m metres wide at all point.
The interviewer stating “actually it’s 100m” shows that they didn’t understand this point either though, and was probably repeating the answer they were told to give if the candidate asks this clarifying question
If you're a recent grand or early in your career, though, you just don't have that kind of clout. You're going to jump through these hoops because you need the job, and you're going to be competing with people in a similar position doing the same.
Developers trying to get a break early in their career should remember that companies want to hire people they perceive as adding value and fitting in to their team and organization. Lots of people can crank out code. Just knowing a programming language or framework is not a competitive advantage in the job market. You need to communicate good people and team skills, and either domain expertise or curiosity about the business domain. I've interviewed too many inexperienced programmers who have focused solely on technical skills that, while hard for them to acquire, don't actually stand out much in the field of candidates. Some time learning to speak to a group without anxiety (Toastmasters, for example) can have more value than learning how to traverse a tree in Python.
Early in my own career companies commonly hired people with little experience, fresh out of school or eager self-taught programmers, and then trained and mentored them. Companies had to do that because of short supply, and because every computer system was proprietary and unique. Now companies won't put any effort into growing someone into a career, they want interchangeable people they can slot into a job and get work out of right away. To differentiate yourself in those conditions you need contacts and reputation, or you need to come across as someone who can add value and commit to the organization. A good recruiter (admittedly not easy to find) can help a lot because good recruiters have contacts inside companies and can coach the candidate and maybe get around some internal roadblocks.
I have some articles about job hunting and interviewing, more tilted to freelancing but possibly valuable for f/t job hunters, on my site typicalprogrammer.com. Opinionated, free, no ads, signups, popups, or affiliate links.
It's such a completely bizarre practice, and honestly insulting to a degree. I get that there's a huge influx of applicants at larger companies, however it's absurd to comply with this garbage structure where you can't even ask important questions to decide if you actually want to work there. I applied to a different job afterwards and once they told me they used that company as well, I refused to continue the interview process.
Worked out in my case, I ended up somewhere far better than either of those companies. I just can't bring myself to respect companies that treat prospective employees in this manner, it's crap.
Back when I had to interview for jobs I would try to turn the tables as early as possible. I would do my research on the company and their business. I would ask questions about the job, the company, the people. I would try to get the interviewer(s) to tell me about their job. People generally like to talk about themselves so I'd try to get them going on that. Of course you have to get in front of the right people -- an outsourced screening team probably can't even talk about the details of the job.
I get why companies do this. They want to screen out unqualified candidates early in the process, because big companies get lots of applicants. I don't think the way many companies go about this works. I've been in the position of hiring at places that get hundreds of applicants for a job, and there's no way we could interview all of them face-to-face. I don't think brain teasers or algorithm questions are useful, though. I used to prepare questions relevant to the job for screening and interviewing. And I would ask questions to determine if the applicant had done any research -- astonishing how many people get to an interview without knowing the first thing about the company or what kind of work they might do there.
I had a hiatus from work in 2016 and when I tried to get back to the job market it was impossible to find anything, even when I was over qualified for many of the positions I applied to and was even willing to take a considerable pay cut just because I was switching business domains (although the stack and many of the required soft skills to do the job remain the same)
The vast majority of the interviewers I faced had no idea what they were doing or trying to measure.
Loop interviews were the worst because it generally takes just one guy out out five to dislike you even if you had a great time with the other four.
I mean I bet most of these guys in loop interviews would not even hire themselves
It became so dreadful and time consuming that I had to tell recruiters right away I would not be doing any whiteboarding or solving puzzles. Pair programming and short take home projects were fine.
That helped filtering companies but my leads dropped by 90%.
I'm employed right now, for about 1 and half years, but there was a time that I tried to switch path from Web/Mobile developer to full backend developer, and in this attempt I got a job interview for a digital bank; I had everything checked out and expected to continue to step 2, even a friend of mine who works there thought I'd pass the process easily, but to our surprise, I didn't make it to the next step, and when I asked the interviewer for feedback they gave me a bullet list with just one bullet saying that I didn't "explore business logic much"! It didn't make any sense! I found it preposterous and insulting, to say the least.
When I ask for feedback, I want to know what are you looking for and why I wasn't compatible with your position.
Making up a BS reason is expected if somebody's personality was really off-putting. Nobody is ever going to give you honest feedback about that.
The reason people don't give concrete feedback is because there often just isn't a clear one beyond "I don't like it".
It doesn't matter if you wrote a library 15 years ago still being used today by hundreds of thousands of developers around the world some even working for the company interviewing you.
Were you responsible for designing and building QA systems used by Boeing and NASA? That's cool, now please write a bubble sort algorithm on a whiteboard and then guess how many cars there are in the US (explain your thought process).
Imagine how ridiculous and insulting it would be for a seasoned lawyer, a doctor or a CPA, to endure this nonsensical, pointless scrutiny when interviewing for a job.
But somehow in tech this is not only common but accepted by job seekers as normal.
These interviews are a good way to filter (and even discourage) older applicants, since the cultural fit for the task IS someone recently in college.
Good examples, because lawyers, doctors, and CPAs all have formal exams and licensures, and a board that certifies that you have the qualifications to do your job. So when a hospital interviews a doctor, they don't have to go over first year anatomy to understand whether the doctor knows where the appendix is. The process certifies a base standard of knowledge.
Software engineers don't have this, and every time it's brought up in conversation, it gets poo-poo'ed. So, 1. Companies have no idea if you know how to even turn on a computer, and 2. Candidates have to start from scratch every time explaining what a linked list is.
Wouldn't it be great, both from an employer's POV and from the candidate's POV, if you could show that you passed the exam and received your license from the Coding Board, therefore you have some very basic set of skills? Then, you could both skip the fizzbuzz part of the interview and interview about more domain-specific questions. It would cut the interview time by probably 50-75%. But for reasons, HN commenters hate this idea, it's imposing "gatekeeping" and infringing on their freedom to pick up a Raspberry Pi and call themselves an engineer. So..... we all have to live with these incredibly inefficient and capricious hiring processes.
It'd be great to have CS and software engineering board tests that can be taken once and then do away with all the interview nonsense like other professional fields.
There are some certification authorities in the US, but as far as I'm aware, the top programs haven't even bothered with it (MIT, Stanford, CMU...).
The main issue is that all CS degrees aren't created equal. Someone can graduate without much programming at certain schools (where the degree is way more math focused). That's completely fine in itself, it's ok to have an option to focus on theoretical math, but it's not necessarily what employers are looking for.
Abroad, like in France and Switzerland, they seem to have some certification body that checks the course curricula and determines if it passes the bar to be called engineering. Perhaps not the best example as these two countries are smaller and, at least for France, way more centralized than the US.
To be completely honest, I fast track interviews for new grads of certain institutions because I'm familiar with their programs and I know what they studied.
and also severely underpaid, and demonized if they try to organize.
Programmers, sure. Engineers? Everyone seems to be fighting to hire them.
Writing code from a detailed spec is the easy part. Back in the days, people were doing it directly in assembly before someone came up with a compiler. When the great offshoring craze started, suddenly everyone was now an "architect" writing these specs and submitting them to an "AI" (called a programmer in India) to be translated into (sometimes working!) code.
So the coding part was cheap and easy, but getting the detailed spec hasn't gotten any easier than it was. And the industry learned (mostly thanks to FAANG) that the best people to write these specs were also capable of coding them faster than by splitting teams in two and having the actual programming be done elsewhere.
> At the same time there are professions like child care, education, healthcare where personnel is always needed and overworked.
Then maybe they should make these jobs more like engineering. Where's the Google of child care?
Seriously, one of the big caveat of education and child care is that comp is on a pay scale, voted by the public, and you get paid for years of services and not results. So the teacher that can't get fired because of union rules, that keeps getting complains after complains and doesn't care will get more money than you and will get first pick for any assignments.
Thanks to over-regulation, healthcare is by far the most dysfunctional field of work in the western hemisphere. Turf wars between professions, bloated administrations and out of control spending is the norm. Most of the overwork is due to completely dysfunctional management.
Not sure I follow this distinction. Who are all the people companies like Meta, Alphabet, Amazon are firing? Are you talking about civil engineers?
When you see it, you'll know it.
> Who are all the people companies like Meta, Alphabet, Amazon are firing?
A lot of them were in "tech-adjacent" positions. PM, tech recruiters or evangelists, community managers, DEI folks... At one point one layoff announcement had "returning to a healthy ratio of engineers to non-engineers" as a goal.
> Are you talking about civil engineers?
No. Software engineers.
Do you have more info on that? Of course a lot of tech adjacent were let go but R&D was cut back as well as far as I can tell.
[0] https://www.bloomberg.com/news/articles/2023-01-24/tech-layo...
[1] https://www.computerworld.com/article/3690309/about-those-te...
[2] https://www.gartner.com/en/newsroom/press-releases/2023-03-0...
[3] https://techreport.com/news/3493451/microsoft-layoffs-ethics...
Steve Yegge famously described Google's "interview anti-loop" where you got two interviewers in the pipeline that wouldn't have hired each other, so whatever pleases one interviewer would get you rejected by the other (and viceversa). In those cases there's no way to win. I suppose the length of the interview process increases the chance you'll hit this anti-loop.
On the flip side, I’m interviewing candidates with a decade of experience (per their resume) that can’t discern the difference between basic data types and how they are stored with the very language they claim expertise.
Once upon a time the stereotype was that hiring developers is hard because they can’t communicate. Now candidate after candidate is able to communicate like they are a professional podcaster but they can’t seem to solve problems well.
If you’re skilled, don’t despair. Most companies are terrible at hiring and terrible at business as well. Those rejections from the gauntlet of flaming hoops they make your jump through are doing you a favor.
Rejection is God’s protection and all that. And I like to think that’s right.
On my LinkedIn I have the following: what I currently get paid by my current employer (!!!), what I am looking for in my next role, both regularly ignored by recruiters of course, and then I have links to my StackOverflow, Medium and Github profiles, any of which ought to demonstrate my “expertise” as well or better than an interview ever could. Heck if you just read some of my answers to StackOverflow questions, I think you’d see I am capable of writing code for your company…
i cant remember who said it but many people with 10 years experience really have 1 year of experience and 9 years performing tasks doing the same thing over and over.
First of all, software frameworks and technology evolve. Second, it's pretty hard to find someone who worked for 10 years at the same company with the same software project doing CRUD actions.
On the other side, if you meet linux kernel engineer who maintained kernel for the past 10 yers, this argument fails short. Same for someone who worked on Postgres internals.
I mean that's what experience is.
If I want an expert in x, I want someone who has being doing x for ten years. I don't want someone who has dabbled in ten different things in ten years, thus having very superficial exposure to ten things and expertise in nothing.
If I need a heart surgeon, I want the doctor who has been doing only heart surgeries for a couple decades. That's an expert. I certainly don't want some doctor who has been switching from heart surgery to podiatry to dentistry and on and on without specializing in anything.
No.
Interviews have 0 context that's needed for anyone to perform. Usually you can't use your IDE, your settings or your ways of working and you've never paired up with the interviewer so might not feel comfortable.
To make matters worse the interview topic is 90% chance not what you do on a day-to-day basis. No 1 is answering leet code questions at work. We're going to be using a library or tool and not to try write an analytics algorithm.
I still look back to a FAANG interview a decade ago being the most difficult thing I've ever done in my life, and I've worked my way up from a shit mining town to the middle class, developed a complete complex software product starting from an empty text file, gotten an advanced degree, built a single engine airplane, and managed to stay married for 20 years. But out of all that, a stupid FAANG interview was the most difficult. It's just ridiculous what companies put people through.
I've never had a problem in a real world setting or writing code.
Im sure i looked like a novice. But in my day to day code... i flip between maps and conditionals and switch statements all the time, with ease. Its natural. But while interviewing? It just doesn't come out of me.
And there are developers who say things like "[other programmers] can’t discern the difference between basic data types and how they are stored with the very language they claim expertise"
That's not the actual job we do. Unless you happen to write libraries or crazy high performance code.
Most of the time it doesn't actually matter how the data is stored in the language, it actually matters how it's stored in the DB. Because that's where the performance problems are.
Most of us don't even have to remember that, even if we ever learnt it. It simply doesn't matter.
Most of our jobs are to turn business requirements into working programs. That makes us an expert, not knowing a language spec verbatim. That doesn't matter at all. It's a meaningless metric.
It reminds me of a colleague who could tell you all the performance problems of += vs StringBuilder but shipped sweet FA for 6 months. And do you know what the difference actually is? Nanoseconds. NANO.
Or the person who seemed to be able to quote the entire SQL manual, yet typed with one finger and spent 3 months building a 10 line SQL statement.
Or the colleague who could give you text book definitions of every design pattern you can imagine, but when asked why they'd implemented a complicated mediator pattern for saving simple forms couldn't explain, "that's how it's done!".
And when I ripped out the several thousand line monstrosity and rewrote it in 100 lines or so, they still admantantly said it was better even when presented with load tests that showed the new code was orders of magnitude faster.
What are you recruiting? Language experts, or coding experts? As you seem to be confusing the two. Sometimes they intersect. Sometimes they don't.
Many developers find themselves in a position of being a subject matter expert in a particular business or industry, and that becomes the primary value they deliver. They remember where that error message originates or why that column in the database is named so strangely. They know the lingo and business quirks inherent to their industry.
Over time they lean more and more on that knowledge and the extent of their software development is mostly spotting patterns in the existing codebase and regurgitating those patterns repeatedly. Their programming muscles atrophy while their subject matter expertise grows. But that knowledge doesn't always transfer well.
I've fallen prey to this trap (personally) on more than one occasion, getting lost in what I was doing instead of seeking to better understand what I do.
> What are you recruiting? Language experts, or coding experts? As you seem to be confusing the two.
I'm recruiting problem solvers, and I think it's necessary to understand the tools you are using to solve problems at least one level deeper than autocomplete shows.
Frankly, I think developers are getting good at combining Google search results into a codebase that reads more like a ransom note of copied-and-pasted snippets than a deliberate engineering effort. When I ask a candidate to convert an input string of digits to its output integer (e.g. "001234500" to 1234500) equivalent and they don't seem to discern that's an important distinction, it raises red flags.
Sure, tools and language (e.g. Javascript) often abstracts much of the details away, but my experience is that those developers with a familiarity of those details and why they matter (even if they might need an occasional reminder from a search engine) are a cut above.
Why do you feel this is important? To clarify, what are you testing here?
It shows that you understand how equality relates to values and data types, and that changing the type of something can make the same conceptual operation behave differently. This is the kind of fundamental technical understanding and precise thinking you want a developer to be absolutely familiar with.
That's what I assume the GP is referring to.
They changed it in ECMAScript 5.
More details here:
That's what the majority of all the industries on the planet are doing. Repeating the correct patterns in the right place and right time. The value is knowing the right patterns and repeating them at the right time and place.
And it makes sense - how many different ways are there to iterate and manipulate a given set of data that contains customer/user records, orders, social post meta or whatever is commonly used in modern tech? Aside from very specialized organizations that are working on the cutting edge of the tech in this or that specific sub-specialization, most of what we are doing is juggling data in the same way everyone does. The chances of anybody bringing a totally new way to juggle that data through exemplary and precise knowledge of the language are ultra slim. And if that ever happens, everyone would soon know and start using that method anyway. Which brings us to the point below:
> I'm recruiting problem solvers, and I think it's necessary to understand the tools
The problem solvers would know that we are living in 2023, and not only the abstractions that we use, but also the stacks and languages that we use have evolved to handle as much as they can to make our work easier, including data types and their manipulation. The memory space inside a developer's mind that is allocated to knowing those data types and manipulating them manually is memory space that is wasted and not being used for remembering other things and increasing his or her impact.
If your logic held out, we would still be manually allocating memory in our programs. We dont. Those who need to know allocating memory on a daily basis and needing to not letting that knowledge atrophy are those who work on hardware, low level hardware-softare interfaces, those who build and maintaing languages, packages, or stacks for industry-wide use. Not the developer who solves !business! problems.
> Frankly, I think developers are getting good at combining Google search results into a codebase that reads more like a ransom note of copied-and-pasted snippets than a deliberate engineering effort
Yes. And that's what enables them to take on the ownership of increasingly broader features and systems. In the same way it enables even fewer founders to bootstrap or launch more complex startups. Everything we do in tech is for automating, optimizing and making easier a given level of problems to be able to rely on that automation to move on to the next level.
> Sure, tools and language (e.g. Javascript) often abstracts much of the details away
Yes. They do. Every stack, language, framework does. That's what amplifies productivity. Not holding on to knowledge you will rarely ever use.
...
The difficulty of modern tech is in creating reliable, user-friendly and cheap systems that bring advanced technology to the masses. Anything that prioritizes specialized knowledge on what is already handled by the existing technology stack is more academic than anything practically engineering related. Such approaches could exist inside gigantic old-school organizations like IBM when they had their heyday, and they did exist inside tech gians which literally made themselves a continuation of the colleges which their founders graduated from, fueled and floated by zero-interest investor money, prioritizing only 'growth' without paying attention to the business fundamentals. But in the new, non-zero-interest economy, they can hardly be justified.
And that discernment, at least in part, comes from understanding what that code is really doing.
I get 45 minutes face-to-face to develop an opinion as to whether or not a candidate can do the job well. I value candidates who’ve not only asked “what?” but have also asked “why?”
I’ve no doubt my approach has filtered out people who would have done good work. I’ve certainly passed people through that didn’t work out for various reasons. But generally, my approach has served me well so far.
It does come from understanding the !business code! that is involved. Not the rarely important features of the underlying language that the stack, the framework or the models handle.
Which makes that argument further moot - you should not be messing with how the models or the framework handle those data types. There is a reason why they were built and deployed.
LOL I've noticed this too! Somebody must be out there teaching people to do this! I mean I interview people, and they are so over-prepared with their sound bites and their canned speeches, and they deftly try to steer all conversations back to topics they are prepared with. Their style, body language and communication tactics are polished and sophisticated. They sound very pleasing. Their slick enunciation, cadence, and confidence make them sound like 20 year NPR veterans. But the content itself is a millimeter deep. It probably fools the exec class, but it doesn't fool a practicing engineer or technical manager in the trenches.
Got me!
I'm not a dev anymore, but even when I was decent to good with multiple languages over the years, I would not have known this.
I do remember being in interviews where one smart person on the other side of the table asked me some piece of tech that was mostly specific to their daily use, and when I didn't know it, they were shocked -- shocked, I tell you.
:-D
Get a simple kata or problem - that the interviewer AND interviewee haven't seen before.
Set up a "code with me" session. Pair program.
See what happens in two pomodoro - have a chat in-between. Swap roles.
1) Do you see tests? 2) Do the tests pass? 3) Did anyone lose their cool? 4) Does the code look good?
Have a score - keep the scores of all interviews (anonymize them of course) - and as you go along see where a candidate fits on the curve.
The problems have to fit into two pomodoros - you have to try this against one of your junior devs and a lead to verify.
I do pair programming sessions with people as part of my job. This has made me a substantially better at pair programming as part of interviewing (on both sides). Perhaps it would be worthwhile for you to time to work with some colleagues to build some of these muscles.
I do agree that alternatives should be offered if someone is uncomfortable.
My mother told me I spoke very little as a child, but in the evening she could hear me practising words outside my bedroom door. I suppose this is some deeply seated neuroticism.
We see how the candidate approaches problems from their initial solution, and then we get to see how they react to being asked to extend things. We get to talk to them about how easy their code is to change, how their tests helped support the changes. We get to see them work through a problem under slight pressure, and hear them communicate with a partner about the problem.
As an example of the level of problem we're looking at, here's an AoC problem we've used before: https://adventofcode.com/2021/day/2.
A couple of notes:
* We keep the problem easy like the one above because we're not trying to see if a person is a genius or has memorized a lot of algorithms. We just want to get a basic pulse on their skill level. For a junior dev, this kind of problem is doable but might take a little while. For a senior, this should be basically trivial.
* When I mention that a candidate is under some pressure, I don't mean that we add any artificial pressure - that would be dickish. I just mean that interviews are naturally a bit of a high-pressure situation, so we get to see if they keep their cool, etc.
* The candidate drives, but we try to approach the problem as a real pairing situation, so the candidate should talk through ideas with the interviewers, the interviewers can and should _actually help_ solve the problem, etc.
* The "take-home" portion is designed with the intent of not taking up more than an hour or so of the candidate's time, and is really there just to give us a starting point to talk about. It also ensures that the candidate has a project set up and ready to go for the interview in the language of their choice, which eliminates a lot of churn from the beginning of the interview.
I helped design the process so I'm biased, but I think it's extremely effective.
This is a cultural thing. Don't expect me to become a new person to fit into your work flow.
Now I know that buddies of mine did great work like that as teenagers creating games (and some sold reasonably well), so yes this can work beautifully. Thing is just, you're not my buddy and I'm no teenager any more.
Most companies aren't willing to invest these kind of resources into the preparation of each interview.
It gave them a chance to see how I worked as part of a team. Even if day to day I'm not pair programming, it starts off the relationship saying "If you need help on a problem, you can be comfortable working with your teammates."
The great thing about the setup is that it doesn't have to be a unique or complex problem. "Write a function to reverse a string. We'll write unit tests in parallel with that."
Or one of the thousand other problems. You're not testing algorithms here, you're testing whether the candidate is arrogant. Or talks too much. Or doesn't ask for help. What happens when they get stuck?
You're right, it's a lot of effort. But the resources spent on a bad hire can be even more expensive.
If I need to have a conversation with you to figure out if you know what you're doing, I'm wasting your and my time. I'd rather have a conversation about whether you're a good fit.
I interviewed at one place that used my work and ran my code in production. Still had to do a take home test.
Which is fine, I quite enjoy them.
Proceeds to ask me to solve random leetcode questions anyway.
I look for code style, commit messages (both proxies of quality of work), following standards, good code orga and tests. Show me that you understand why clean code is important basically
1. Having a web portfolio which has system designs, images, or gif videos of my apps, and points to my github code which interviewers can view.
2. Then walking interviewers through a project during the interview.
Whereas 3 months ago, I had a call w/ a "Director" of Engineering for a small startup (5-10 engineers, about 10-20 other staff). He wanted me to do a take home project. "it's just a 2 hour project: a CLI tool to lookup data via REST API, based on arguments passed in. And expose a gRPC endpoint, writte in Go or your favorite language, but we want to see it ready for production with tests". Everything except the REST API part was new to me: a CLI framework, gRPC, protobuf typing stuff.
Three hours in, I realized I crossed my self-imposed timebox and that the project would really take about 8 hours (or perhaps 16 if I wanted to polish it and have a higher rate of getting hired). However, I was on my vacation and the purpose was to spend time away from technology.
The whole thing felt a bit silly. Learned a new framework though so that was cool (yargs -- https://www.npmjs.com/package/yargs ).
The place I'm currently at is hiring a principle engineer. I've performed a few tech interviews so far. We just started the process less than a month ago.
We have (2) interviews. The first is more of a soft skill analysis (casual conversation) that the engineering manager does and the second is a tech interview. Each are 1 hour long and are usually scheduled on different days. There's no algorithms, whiteboarding, puzzles, take home tests or desktop sharing. We just video chat about a range of tech topics for an hour and ~20% of the time is left to ask us questions.
In the past I've mentioned that if I were ever in a position to hire someone I think it's possible to accurately identify someone's skill sets with a casual conversation and I still believe that[0]. No matter how good of a speaker you are you can't BS your way through certain kinds of practical tech questions. You either know them and can explain them in detail or you can't. There's a million little things to pick up on through out the conversation which weigh in on being a hire or not-hire in the end.
[0]: There's exception of course, my specific case applies to fairly standard web apps (something comparable to GitHub or Shopify in scope). Exceptions would be hardcore low level programming.
Developer hiring is exceptionally awful for lots of reasons, but there are wider problems now.
https://careers.walmart.com/results?q=software&page=1&sort=r...
CVS has 492
https://jobs.cvshealth.com/job-search-results/?keyword=softw...
The non-tech Fortune 500 companies are still hiring. Go down the list
He now says that this has been the most fulfilling job he's had. This retailer was working on ancient systems that, while old, were exceptionally well-designed. Moving these systems over to a modern tech stack was challenging but also incredibly rewarding.
On the other hand, I really enjoy working on things that benefit non-tech users and solve "real-world" problems.
If you're still there after a year you'll probably spend your career there.
Unfortunately they wanted on-site presence in a different state than where I live so couldn't go forward with it. Otherwise might well have taken it, to my surprise.
Throwing shit around is a red flag, though.
If the compensation was lower - no one would bother. This is why you see companies that do these practices but don't pay FAANG wages having a much harder time hiring - while FAANG never has any problems hiring ever.
/edit: but I agree that wages need to increase in Europe overall for developers!
IMO that's because they (employers) too have no idea what they are looking for. It's a mess and only getting worse.
My 2 cents is just say yes to that rare proposal that comes after one or 2 interviews. And yes, they do exist but almost everyone passes them because "if it was so easy the role must suck". Well, the possibility of role sucking is exactly the same if you went through 10 hoops to get the job.
Places that treat candidates poorly tend to treat employees badly, and companies that drag out the interview process tend to miss out on in-demand talent.
As a result, places that respect your time and well-being have been more likely to have good engineers who have stuck around. Places that are toxic and/or bureaucratic tend to combine bad hiring with high turnover and create a terrible environment.
The personality tests can fuck right off, though. Agree with that.
When I see an error, it bothers me.
Mostly agree
Somewhat agree
Neither agree or disagree
Somewhat disagree
Mostly disagree
Of course I support the organization, and I think being honest with superiors is the best way to do that.
In the end, these things are so imprecise that you have to get to know somebody to know which parts are accurate (some were) and which aren't. By †he time you know how accurate it was, you know the person well enough to not need the test.
Openness - how easily you are willing to accept new ideas
Conscientiousness - how careful and how hard working you are
Extraversion - how quickly you are to engage with the outside world
Agreeableness - how quickly you are to agree versus disagree
Neuroticism - easily experienced negative emotions
Most people aren't a point on the spectrums, they have a range. For example a lawyer might be very disagreeable at work when talking with opposing counsel, but very agreeable when dealing with their children.
I had one job that was absolutely awful, and to be brutally honest my attitude sucked. I wasn’t as nice to my coworkers as I wish I had been. I wasn’t a complete asshole or anything, and my behavior was never raised with me as being problematic, but I’m not proud of how I acted through that time.
But over the course of a fairly long career I’ve gotten a lot of comments about how laid back and friendly I am, and how I tend to go out of my way help people. I like to think that’s who I really am, but I can definitely be unpleasant if I’m miserable.
First, the trait examined is a range and is also situational. Second, your self knowledge of your ranges and situations is also variable and introduces more error. Third, the test introduces more error, it seems. Nobody on this thread has given any evidence this is a useful hiring tool.
My impression is hiring is difficult and there's no shortage of companies pretending to solve it with science, but it's not solved and it's not science.
In fact stability is the strength of Big5. People's personalities seem to be stable over their lifetime. See the 3rd paragraph [0].
The weakness of Big5 is it may/probably does not capture everything. It seems to completely miss abnormal personality traits. Which in a job interview... I hope has been ruled out with initial screening.
Until risk to the business increases, a possibly worthless speedbump on the hiring path doesn't hurt hiring and effectively makes more work for the HR manager's team, which means team growth - HR win!
As a rule of thumb, if it involves psychology, the answer is always no. Humans do not have the ability to do valid experiments to verify claims, so it is all BS.
As someone else mentioned here, Walmart apparently has over 1000 software related openings right now. I know a few companies outside the traditional 'Silicon Valley' company ecosystem trying to hire developers and I can promise you they're not getting 100s of applications within a few hours. The jobs are definitely out there, they're just not where most people are looking and perhaps not in a field, company or geographic location that are most people's first choice.
> The personality tests can fuck right off, though.
I agree that personality is an important thing to consider in interviews. But trying to gauge it with tools like that is at best a waste of time and at worst actively misleading.
No, neuroticism isn't what you are looking for either, neither is conscientiousness. It can be argued that for an academic position you would want high conscientiousness, but I think many would argue that you want some of your professors to have disorganized, messy offices.
This is because the "Myers-Briggs" is hogwash, with as much predictive power of personality as astrology. i.e. none.
If the people administering them are using them for the intended purpose, they're rejecting candidates on nothing more than a roll of the dice. If not, then as others suggest, they are covert way of "screening for neurodivergent people""
So: This _personality test_ can fuck right off.
I doubt that any other quick multiple choice questionnaires are much better. If anyone wants to claim that they're worth anything, show the proof please.
https://www.vice.com/en/article/bjv8y5/the-myers-briggs-pers...
https://amanda-obryan.medium.com/9-reasons-the-myers-briggs-...
https://www.businessinsider.com/most-personality-tests-junk-...
A reminder that your pay corresponds with your expected skills, hiring a top 1% de offering market average, is a delusion. But the interview process is out of control for devs, and basically non-existent for managers.
Ps: I'm a manager, so I can say that I'm overpaid for what I deliver, while devs are underpaid and the expectation on them is out of reality.
If you are able to recognise this, surely you have the power and the incentive to change this?
As a rule, people are not paid "what they are worth", they are either paid market rates or convince the company they have a differentiated skillset that warrants compensation beyond what is normal in the market (usually by tying their performance to some important metric). No one has yet found a way to change this from within a corporate structure.
Except in the tiniest of startups, managers and even directors have just about zero say in compensation ranges.
From your POV what do you think we should do?
> Do not post here unless you have minimum 3 years experience.
It is most likely to avoid it becoming like CS Career Questions
https://www.reddit.com/r/ExperiencedDevs/comments/10b4x3e/is...
I once interviewed where they gave me a big assignment to complete. I must have spent about 8 hours on it. Since I wanted them to see my thought process along with code examples; I gave them something that was about half pseudo-code and half real working code. The hiring manager said they couldn't accept it until I had converted all the pseudo code into working code as well, along with a set of tests that exercised the code. I estimated that the assignment would take me an additional 20 hours or so to complete.
I told them that I had spent enough time working for free and if they wanted to pay me for the work I was doing, I would be happy to complete it. They declined, which told me all I needed to know about the company.
Freelance market is awesome these days with more businesses reducing in-house staff and outsource whatever they can to cut operational costs.
This single question can save you hours of your life and weeks of waiting to hear back.
During the course of a single interview I describe what we are building and how we are building it, and invite the candidate to explain if/how they could participate in that. One or two senior guys from the team will ask them some smart questions about real-world problems and complexities to get a sense that they know their stuff. No quizzes or puzzles or abstract questions. No homework. No second or third or fourth interview.
I held out for something better.
followed with key requirements, locations(and if remote is OK)
followed by your interview process steps.
that's all I need, I don't need schedule a 20-30 minutes call for each recruiter for info I can filter in a 2-minute read, in fact a twitter-size job post can cover all the essentials before any meaningful talk, why making a lengthy process longer than necessary.
and, if you're asking for many years experience for a junior position, or you're asking a senior developer to be great at leetcode challenges, you might be doing something wrong.
For months it's been hard to get any response to an application, let alone an interview. And when I do get responses, they are often strange. One company where I would have been a perfect fit claimed that my code sample had "scary" SQL injection vulnerabilities. It did not, I have been doing this for decades, and I know how to sanitize my inputs.
I asked for specific file name and line number, and they sent back a vague non-response on how to identify vulnerabilities, so I stopped pursuing it. It was a lost cause, even if I showed them how they were mistaken, it wouldn't work out. I suspect they were using some kind of automated scanner that flagged some false positives.
I don't want to stop making software professionally, but that decision may not be in my hands.
You hire a responsible experts when you want to trust them with full decision authority. You can only do this if there's no real risk of failure.
But when you're producing software with real risks, you have a QA-first process that details, validates, and verifies all requirements. You have a large team, cross-checking (and helping) each other. The key virtue of a developer in this context is diligence and honesty.
It's a great gig. In FAANG and software-only products, you're always on the critical path. For medical devices, it's typically the chemistry or device that sets the schedule, so software can proceed at an even pace.
Plus, you're building something meaningful!
They had an online test to take that I had to pass in order to actually have an interview (or more, I don't know how it worked with them).
Anyway, the task they sent me was estimated to take 8 hours of work and couldn't be paused.
I was on vacation, I didn't want to bother so I just declined.
Once I was given a task to create some validation code for given criteria and integrate it in the given project.
They then invited me to an in person interview. At one point, I had to pair program with one of their developers and what I saw kind of shocked me. They integrated my code from the interview into their production code and their developer had an issue with it and asked me to help getting it working and write a couple of extra tests. So I did and they seemed very happy.
I didn't get the job though. They said I am not a "cultural fit".
I asked them if they actually used my code and if so they would have to pay me for the whole day, but they never responded afterwards.
I decided it wouldn't be worth to legally pursue, but since then I decided to not do any pair programming or coding tests.
I aced it, they were more than pleased, yet in the end they did not hire me as they said that they are actually closing the position because of the market downturn. At least they gave me a 50€ amazon gift card..
That's a codeword to cover racism, sexism, and/or ageism.
They solicit a huge amount of applications but very rarely hire people who make it beyond a year.
Although I'm on the Java side, I've yet to see a leetcode interview in CH, maybe I got lucky so far, but most of the interviews I had before were completely reasonable, maybe even too easy. The one that I failed miserably was an architecture discussion, in which I got an empty paper with a pen, and was expected to come up with the design of their existing system (I was allowed to ask questions). But even from that I learned so much, so no hard feelings. I will know much better what to do next time :)
- Don't aim too big (there will be way more competition if you're trying to build a world-changing product).
- Don't go into any sector where big tech corporations are already offering products (no matter how bad those products are, you will not be able to compete on marketing; nobody will find out that your product exists).
- Find a niche. The more boring and tedious the niche, the more likely you are to succeed.
Basically, base your entire strategy around minimizing competition at all costs. Do not underestimate competition. Do not underestimate the power of a great big pile of capital in the hands of your competitors; no matter how terrible they are.
This is not capitalism. This is crony-capitalism. NEVER FORGET THAT. As you rise up the ranks, prepare for less ass kicking and more ass kissing.
With rejections and applicants who finally turn off the offer, it must be quite significant, especially for a 6 month contract.
There are still 1000s of open developer jobs.
That said, without a link to the resume, it's not even an anectdote, it's just venting out.
What happens to HN when software engineering is just viewed as a typical job no longer associated with startup culture?
As for decision making - like every other field, I think that has more to do with the individual then anything else. Some people are good at it sorta naturally gravitate that way, others have no interest or skill in it. I know I'm much happier as an IC/team lead/etc. Sitting in meetings and paperwork really aren't my thing :-/
It seems there is a mismatch currently in the market, between what companies are demanding, and what employees are offering.
I am honestly thinking of creating a service, where I would create a database full of developers looking for work, and then only give access to companies seriously looking to hire, so basically like LinkedIn but minus the trash and spam.
But I think it's only going to get worse now that the market is getting flooded with people coming from rounds of lay-offs, and the VC market tightening, etc.
I'm still getting offers to interview daily. I've helped people land jobs, but all of mine have been posted online and applied to by me.
Just another data point.
(Horrible, it turns out).
What's insane is the hiring market during the longest bull run in history, which has now ended.
There's no interview, just turn up, fix something, hope it gets accepted.