If the minimalist resume is appealing, can we also bring back walk-on hiring?
In warehouse and construction work, if someone shows up at 7:30 AM on a Monday morning, odds are quite good that the foreman will have something for them to do. Maybe not that day, but maybe tomorrow, or maybe someone on the list above them won't show up that week and they'll get called. I made rent doing that in my early 20s and they even let me leave early sometimes to work on my internet business because I didn't have a family to support and maybe someone else had a bill they needed to pay and wanted my shift.
Why again does boutique startup need to interview 500 overqualified people? Hire someone right away and let them quit if they want to and hire someone else. It's just business for crying out loud.
> Hire someone right away and let them quit if they want to and hire someone else. It's just business for crying out loud.
This is missing the point of interviewing. The goal isn't to find any warm body to fill the chair, the goal is to find someone qualified to do the work who also has a history of doing good work at previous employers. You also don't have unlimited headcount and hiring budget, so it's worth making the investment to find the top 10% of your applicants rather than picking first-come first-serve.
One of the things you don't realize about the hiring market until you've been reviewing resumes for a while is that problem employees are over-represented in the candidate pool. The most qualified employees spend the least time job searching because they're given offers right away. The most problematic and underqualified employees are frequently searching for jobs after being fired or let go. If you sample applicants at random, they're far more likely to be in the underqualified and/or problematic group than in the great employee group, statistically.
The other thing that isn't obvious is just how damaging a single bad hire can be to a team. Hire someone who clashes with their peers and fails to deliver any good work and you'll find yourself losing the good team members very shortly. Nobody likes working with painful coworkers.
That said: The analogy of a "walk-on" job isn't dead in tech. If you pick a company you want to work for, find someone on LinkedIn, and send them your resume with a short pitch about why you want to work there, there's a good chance they'll at least strongly consider your resume. Nobody is guaranteed a job this way, but it's one route to getting your foot in the door even when you don't see the exact job posting you want on the website.
I actually very much agree with this comment. I was a manager for 25 years. A bad "team fit" was not good.
I never had a technical failure in my hires, but I did have a couple of "bad cultural fits." These usually weren't toxic people, but people that couldn't handle the responsibilities and pressures (we were a small, high-functioning team, and everyone's visibility was fairly high).
But this:
> who also has a history of doing good work at previous employers.
makes me wonder how LeetCode tests can tell you that, as they seem to be the single most important component of all software engineering hires, these days.
In my experience, they just drive out the qualified people that can see projects through, and leave you with ... the ones that are really well-practiced in short, academic exercises.
I'll second that. I never hired anyone who couldn't do the work. The only times things went badly were times when the person basically didn't want to do the work, due to some personal hangup. No amount of interviewing is going to weed out that guy who can code perfectly fine but deep down is yearning to be a psychologist instead. Like any other job that pays bills, you are vulnerable to paying his bills until they find what they really want.
> In my experience, they just drive out the qualified people that can see projects through, and leave you with ... the ones that are really well-practiced in short, academic exercises.
Yeah beats me how anyone thinks LC is useful, other than for weeding out the most unqualified people, like people who genuinely have never coded. I suppose what it really does is finds you people who are willing to put in the time to study all the hundreds of questions.
As opposed to putting in the time to learn how to write and release ship software.
I won't study LC, because I'm waaaaaayyyy too busy, learning Swift, UIKit, AppKit, WatchKit, SwiftUI, DocC, MapKit, SiriKit, device SDKs, networking, USB, etc.
I literally work every single day (like seven days a week), and learn something new every single day, yet I am barely keeping up. I would be nuts to sacrifice any of this time, studying schoolboy questions that have little to no relevance in the software that I write.
These technologies result in actual applications that you can sell and market.
But overall I agree with you. While I don't have the results to back it up, I do believe that ultimately Leetcode isn't that useful outside of recruiting people straight out of college. Otherwise, I think there are more domain specific methods to assess candidate fitness to a role.
Also, my giving my unsolicited opinion, I do agree with one of the Reddit posters saying that you are currently on your way to burnout. While I can sympathize with you being super interested in learning programming all the time (because it is very interesting!) be sure to not ignore your other needs, and also to take a mandatory break at least one day a week. Speaking from experience, if you don't do this you will burn out and you will have to pick up the pieces.
Well, I have been doing this for over 30 years, and going at my current pace for probably ten years (I noticed the comment about me being an enthusiastic youngster. That was cute).
But I also take breaks (and naps) whenever I want. No one wants to hire old folks, so I don’t work for anyone. I do this, because I want to.
What’s that saying? “It’s not work, if you love what you do?” For me, coding (designing solutions, in particular) is relaxing. I have some fairly serious family and extracurricular obligations that bring their own stressors. Coding is how I get away.
I’ll tell you when I was actually in danger of burning out; it was when I was a manager (which I did for 25 years). I spent a hell of a lot of time, sitting on my ass. I coded on the side, so I wouldn’t burn out. This is like Disneyland, compared to that horrible grind.
I share this position fully, but we need to consider the benefit of a standardized test despite its flaws. Other paths to success need to exist (e.g., university admissions take people on other merits besides SAT and similar) but it can be more difficult to assess the validity of any claims regarding level of experience without a well-known certificate.
When a job doesn't focus on what LC asserts, and I think we'd agree about how huge that segment is, then naturally it should be a small or non-existent consideration.
I have no problem with licensing, depending on the job.
Some stuff should definitely have a steady hand on the tiller, other jobs, not so much.
But the thought of licensing software engineers is daunting. The industry is so incredibly varied.
For example, almost none of the programming I do, involves higher math. I've pretty much forgotten all my calculus, while other jobs are almost nothing but math.
I could be writing crucial, lifesaving device control stuff, and the math person could be working on a game physics engine.
I am in awe of game programmers, but they also work on "nice to have" stuff. I know someone that writes software for medical devices. He is not a "math person," but he's also very dependable, and can be relied upon to Get The Job Done. He has many years of working on things like USB drivers, firmware, Bluetooth, and networking layers.
So, if the “licensing test” insisted on a good command of advanced math (because “everyone should know it” –the same argument given for LC), neither he, nor I, would make it, so the company would be deprived of some very good, dependable, disciplined, and talented engineers, fully capable of writing highly effective asynchronous device control code, and would, instead, prefer an inexperienced math programmer that would try to rewrite the project in haskell.
Amen to that. We hired a guy that just completely polluted the office morale. We were small and wanted to do the "right thing" so we tried to figure out how to make it work for way too long. Finally ended the relationship and the whole place felt better. He wasn't a bad guy, just didn't fit somehow. He was really big on "lanes," didn't handle code review well, and on and on... Important lesson learned. It would have been better for him and us if we had ended it much sooner.
The GP was using the proxy of "shows up at 7:30AM, ready to work" as signal for motivation and a lesser extent, competence. Not a morning person, but would prefer this to leetcode hazing.
As Seymour Cray said, "The trouble with programmers is that you can never tell what a programmer is doing until it's too late."
It can be months (at a high salary) before you really know whether a hire is likely to work out. I think it makes sense to invest more effort in screening applicants in this case.
I've hired hundreds of developers over three decades, and this is completely wrong:
> It can be months (at a high salary) before you really know whether a hire is likely to work out.
It's only that way if you make it take that long. You should know if you have a good programmer 2-3 weeks after the hire. Here a couple things that make making great hires hard:
* Making it difficult to learn and understand your system.
* Having slow and expensive employee onboarding. I've seen companies spend $3-4K (not including the actual laptop) just getting a laptop to a new employee after IT gets done with it. If it's super-expensive to make a hire, the incentive will be to keep people that aren't getting the job done.
* Not looking at work output for extended periods. In short give new people tickets that can be done in a few days at most so you are able to look at work output in six days instead of measuring at six months.
> I think it makes sense to invest more effort in screening applicants in this case
There's only so much you can really screen before error in your hiring process exceeds 50%. Every step you add to a screening process has an error rate, and some are very subjective and error prone. The more screening you do, the slower you go, and honestly, the worst candidates you have to pick from. Why? Because a good programmer will be on the job market for 1-14 days (I'm not saying you are bad if it takes you longer to get hired, it's just what we're seeing in our recruiting software right now).
I have a human conversation, make sure the expectations are clear and ask them if they think they can do it. Then I look at some of their work to verify and that's literally all.
No whiteboard, no takehome, no brainteaser, nothing like that.
Go google "how gates hires" or "how jobs hired" ... it's more or less the same. None of this I watch you implement a sliding window in a shared coding environment bullshit.
Let me put it this way. Say your candidates were all award winning scholars with phds and prestigious organizations to their name, then how would you go about it?
With respect but also, you'd still check to make sure it's the right fit, obviously.
Now here's the crazy go-nuts bananas idea - treat everyone with that level of respect. Totally wacky, I know. But hear me out - you can apparently build better teams with trust allocated to trustworthy people as your building block. That starts the day you interview and extends forever, well beyond your time working together.
Because it's self-evident that designing a quick-ramp up process and modular system/good docs makes this a lot easier. It's 2022, you should be able to review checkins on gitlab the first week with a couple of basic tickets.
If folks are too green for that then they can be put thru an internship first. If an obscure language, have them do checkins on a tutorial.
I've seen many variants of the recruiting process from the cute product feature disguised as a take-home to 6 stage interviews with two engineering(!!) interviewers per round that cost the company a few thousand per (un)successful candidate in man-hours.
Which is hilarious in an industry that is pretty binary ("you can build it") || ("you can't build it"). Doubly so when the majority of dev jobs are in web which is easily explored in the candidate's language of choice with basic CRUD / RESTful concepts.
I know a company that hired a contractor, who (probably) sat on his ass for months, then went AWOL with nothing delivered, and said company had to start over from scratch. Probably a little too much trust there.
This used to happen in the 80s. I went to interview at a startup company in Mountain View in 1987. There was some chit-chat then the interviewer asked me to wire-wrap a circuit (diagram was provided) and power it on and connect it up to the logic analyzer - he went away for about 1/2 an hour while I did that. He came back and complemented me on my neatness. Then he took me over across the room to talk to the VP of engineering who, after a few minutes of chit-chat, asked me when I would like to start. Those were the days.
Pretty much my interview process. I ask them to program a contains(string, substring), then come back 30 minutes later to code scattered all over the place, sometimes with “// 54 upvotes http://stackoverflow.com/…”, code not compiling, and I’m still wondering whether I should accept them.
I wonder what’s so hard with my interview. 5 years ago, even interns could do it, one of them could even tell the difference between UTF-8 and UTF-16.
Maybe the problem is that nobody needs to solve that problem in their jobs anymore? For the last few months I've had the joy and privilege to really get to know the TCP and TLS stack intimately, and find myself looking for the patterns that are going to be most useful for handling data bit by bit. But prior to that, I really needed to care much more about the semantics (and the engineering culture around them) and the large scale structure of my code. I might get more hung-up/distracted by `contains(string, substring)` vs `string.contains(substring)` than what the actual operations to achieve it might be. And also, "surely this problem is already solved, optimally" aligns with one of the 3 great programmer virtues: A Great Programmer is Lazy. 30 minutes is unfortunately exactly the wrong amount of time if somebody has fallen into this trap.
Anyway, I guess it depends what compute layer you're interviewing for, but it doesn't necessarily sound like your interview process is broken, exactly. Like, it could be testing for the right thing, but in the absence of that thing, maybe you just need to find another thing that is substitutable.
Our real algo: We save a bunch of objects, but some of then exist in the DB, so you need to intersect what’s in the DB with what’s in memory before saving, except you can never hold all of the db at once.
It should be our real-life test, but it’s too long. It’s our most complicated algo, and honestly it’s very simple in the end. But given all the variables scattered around in a string.contains() (I don’t even look whether the result is correct, I look whether it’s structured for intelligibility and how they debug the off-by-1 errors), I can’t suppose a more complex algo will be done cleanly.
Maybe I’m mot giving them their chance - It might have taken time for me to output clean algorithms.
`upsert`, not sure how having someone implement `contains` is going to help solve your IRL problem optimally, but I guess the interview process is more about testing cognitive strength vs. practical experience.
The joke is that the would-be worker assumes the forklift question relates to the previous question, and thus that the teapot is so large that it requires a forklift.
This make sense for highly productive labor, that foreman hiring people for just showing up generally got a positive expected return for this. In fact, this is still how a lot of (sometimes illegal) day labors go about getting work: truck comes by, picks up people ready for work, work get done and everyone makes money.
> Why again does boutique startup need to interview 500 overqualified people?
Because these startups lose money as a matter of principle. The people working there aren't actually performing productive labor. All of that hiring is about creating a large illusion in the market place.
Most of my labor has gone to waste. More projects than not never ultimately shipped, but even the most valuable projects I did, still made money for companies that ultimately lose more money than they take in. Many of my best projects are for SaaS companies that don't exist any more.
The guy picking up a bunch of people in the back of his truck is about to go build something real and is going to get paid in cash, and the more people he can get in the back of the truck the more jobs he can get done in that day, which means more cash for everyone (and if you're on the paying end, it means that project you wanted done is done faster).
> It's just business for crying out loud.
I don't think this has been true in tech for over a decade. I had a COO once excitedly proclaim that if the company made more money than it cost to run, we would have unlimited runway. The COO seriously thought he had stumbled upon some brilliant realization about a company making more than it costs to run.
The guy with the truck knows far more about business than most execs at tech companies today.
> Most of my labor has gone to waste. More projects than not never ultimately shipped
Same here and I've been in the biz for ~35 years. An architect can drive around a city and point to buildings he designed. It's a bit disillusioning to think that the vast majority of the work I've done has just sort of disappeared because either a startup didn't make it or got swallowed up into a larger organization that had other plans.
> The guy with the truck knows far more about business than most execs at tech companies today.
Yep. The guy with the truck can't lose much money for very long. A lot of tech execs have gone years without needing to worry about that because there was so much easy money around.
> An architect can drive around a city and point to buildings he designed
I was under the impression that architects also did a lot of spec work, or designs for RFPs that don't ever get built. Or maybe only get built as a model.
I'm not disagreeing with your premise -- there is a lot of programming work that is hidden, lost, or wasted. However, it's not a trait that's exclusively a programming thing.
> An architect can drive around a city and point to buildings he designed.
I don't think that the situation is really that much different for building architects.
In cities that are experiencing rapid densification, it's not unusual to see numerous buildings from the 1950s, if not much later, being demolished to make way for newer and larger structures.
Even when structures aren't totally demolished, it's not unusual for them to be so extensively modified that the original building is virtually unrecognizable, or even completely obscured by the work of other architects.
It's also quite common for building projects to be canceled before construction starts, but after designs have been prepared, and other architectural work performed.
Many projects that do eventually get built often go through numerous revisions, with the final product being almost nothing like the earlier designs.
We had a fellow just out of college walk in off the street, maybe 2015 or 2016. "I heard you guys do Clojure programming here, is that right?" We said yes. He said I'd like to interview. We interviewed him that week and hired him.
We were a small-ish startup and he had done his homework, showed interest, and could write code to our standards. He stayed for a year or two and then moved on.
This is such a terrible take worthy of not making it past Econ 101. Yes in theory a completely free labor market is cool. In practice, centuries of labor exploitation and history of workers’ right show that this will quickly devolve in employer’s favor.
I guess as long as abending of interviews is still legit, it's as viable to take walk-ins as to take electronic applications. Just be sure to act on any GTFO needs before the start date. The interview process is longer to accommodate those legal protections, but those don't start until hiring (or something that isn't the first conversations), right?
Long story short: I think we can lengthen the interview period to accommodate those legal time sinks without killing off the (now a bit of a novelty) meatspace first impression. Unless you're talking about blind selection, where the candidate's likeness (name, etc.) is redacted for DEI. In that case, I can see how witnessing the candidate's skin, gender, etc. could be problematic. TFA even explicitly included the types of things we try to leave unspoken these days: excellent health, 5'4"?!
the main point is how it is in direct contrast to how other sectors will interview for weeks and months, before any resolution at all, then require negotiating an offer, just to get to a two-week notice at a minimum and then require another 2 weeks to a month to get paid, with deposits taking several more business days (up to 5 actual days) to be available
paid instantly when you realized you might need it, versus paid 4 months from now hoping you planned and forecasted correctly
I wouldn't call entertainment work (even the craziest corners of that world) nearly as off-brand as suggesting that women dominate it. I have no idea how far from 49/49 the makeup might be, but I do know that I'm a guy who's done plenty of entertainment industry gigs (music production, fwiw) where the pay is quite reliably received before going home, and that's the important distinction here.
I was referring to women dominated crazy corners and I don't have lived experience with man's equivalent job pursuit to say so I didn't speak about them
> In warehouse and construction work, if someone shows up at 7:30 AM on a Monday morning, odds are quite good that the foreman will have something for them to do. Maybe not that day, but maybe tomorrow, or maybe someone on the list above them won't show up that week and they'll get called.
That's hard to do when there are so many strings attached to employing someone. It's a double edged sword which makes the decision to hire someone a lot bigger." Yeah, I have stuff I need help with right now" is not enough.
"Workers' rights" makes hiring and particularly firing very expensive. The same thing with "tenants' rights." I would rent to anyone with bad credit and a sob story if I could simply evict them within days for non-payment. But because of these rights now everybody has to have an 800 credit score and six figure W2.
While I’m not doubting you would personally do as you say, I would point out that as someone living somewhere with quite lax tenants rights and a nationally recognised housing emergency (Australia), landlords not renting to people because tenants rights are too onerous doesn’t seem to have a particularly large impact on housing availability.
Whereas some tenants rights seems to have a pretty large positive impact - ie all the positive effects of secure housing.
> Hire someone right away and let them quit if they want to and hire someone else. It's just business for crying out loud.
You're not hiring construction workers, you're hiring architects. It often takes more than 3 months to get used to a new codebase and understand how and why things are done the way they are.
And sometimes you are hiring construction workers, and sometimes trade-specialists. I've hired contractors to address specific tech-debt, or accelerate QA on project, to implement a CRUD type stuff for things with well-known approaches that just take time.
Well, then may be it's important to note that we are talking about two different industry niches and practices from one of them are not a good match for the other. And may be we even should come up with some kind of names for these kinds of "tech" to avoid mixing one up with the other.
We do have a variety of words that have certain connotations -- there are even essays / blog posts about the supposed hierarchy (or soup) of script kiddies, hackers, coders, programmers, developers, architects, etc. etc. etc. but the analogies to their metaphorical ancestors (very often from real construction) are neither perfect nor stable. A housing developer can more easily search for laborers than a software hiring manager can search for a code monkey who doesn't try to steer the ship!
The closest equivalent to that today, in most white-collar roles at least, is contracting. Usually not a physical walk-on hire anymore, but it is often quite a quick process (sometimes as little as a few hours), from "I need a worker", to "I can do it", to "get cracking sonny". And it's then, days / weeks / months (usually not years) later, a similarly quick process, from "we don't need you anymore" / "I'm outta here", to "don't let the door hit you".
But the contractor usually needs to be "employed by" some agency company, that guarantees his/her suitability, and that handles the (not insignificant) paperwork / legalities, and that takes a handsome cut.
We automate tons of software. That's what compilers and interpreters are. And now we're even entering the era of plausibly-deniably-stealing-other-people's-code-from-Github-as-a-service.
I worked at a place a long time ago upgrading legacy software from the 80s. I helped them update their build process from file shares, copy/pasting and manual building to Git, Jenkins and automated builds/tests/packaging. I know it's not automated code, but it certainly saved us a lot of time with about 50 assemblies. I'm sure some companies were ahead of the curve when it comes to stuff like that, but this was a really small company. Modern CI/CD software is great and saved us lots of time.
Same. It's fair to say our tooling today is far superior, but "fully automated" implies virtually zero input from humans beyond the initial configuration.
Being a bunch of engineers on HN, I get it, but that’s needlessly pedantic. My first real job was a systems and tools programmer working on scaled database systems.
Literally every aspect of that job is fully automated.
Where I work today 20+ years later, we have 1/3 of the people doing like 100x the amount of work by several measures. Little teams of developers can just crank out work.
You call it pedantry, I call it "field of work". I've managed to avoid working on apps built around databases for my entire career, instead focusing initially on operating systems, device drivers and OS-level tools; then later on software for pro-audio/music creation workflows. Literally no aspect of this work is "fully automated".
Yes, the productivity of modern day "stored-in-the-DB/presented-in-the-browser" project teams can be astounding. But that's only one type of software.
then why isn't construction automated? i think if your company's processes are so specialized and nuance, you should really take a step back and ask if they should be.
That's the convenient myth to think banks caused crisis. Money printing and credit rates lowering by government caused this. Free money? Sure, why not. Please watch princes of yen documentary where they speak about "credit window guidance" conducted by Japanese national bank for more than decades
I don't deny frauds in credit agencies. However, somebody was buying banks' CDOs? Who, ancient aliens? No, they weren't called surprime because credit agencies cheated on their rating, they were called so because they were inherently risky more than a normal mortgage ( so called ninja loans, no income, no job ). That's the people were buying this shit with the all time low rate loans. Human greed huh? That's less convenient than blaming banks for all the evil in this world
In warehouse and construction work, if someone shows up at 7:30 AM on a Monday morning, odds are quite good that the foreman will have something for them to do. Maybe not that day, but maybe tomorrow, or maybe someone on the list above them won't show up that week and they'll get called. I made rent doing that in my early 20s and they even let me leave early sometimes to work on my internet business because I didn't have a family to support and maybe someone else had a bill they needed to pay and wanted my shift.
Why again does boutique startup need to interview 500 overqualified people? Hire someone right away and let them quit if they want to and hire someone else. It's just business for crying out loud.