I always find it strange that people who talk about tech interviewing inexplicably overlook what seems to me to be a core defining characteristic: they are highly traumatic. You take some poor bastard and have him struggle at coding puzzles in front of someone he very much wants to impress and then watch as he fails miserably. They are left feeling like they are biologically inadequate to their job. It's a direct assault on egalitarian sentiment - a load bearing pillar of civilization - even if it is more or less a noble lie.
By definition, they only take the top 1%, and 99% of people get to eat shit. Inspiring existential resentment in the vast majority of people who interact with you is obviously not a recipe for good karma.
Stress I'll grant you. But what's your alternative to selectiveness? Is your expectation that companies, who are spending a substantial amount of money to hire someone, should not try to hire the best person they can get for their buck?
Like, I'm enough of a leftie to agree with the idea that one's ability to contribute in the workplace shouldn't determine your ability to live a decent life. But that doesn't mean companies should hire someone who can't do the job, it means being unemployed shouldn't be a virtual death sentence, which isn't fundamentally a problem of hiring processes.
I do not have an alternative and agree that this type of screening is necessary.
I just think the fundamental problem here is not procedural as the post seems to suggest - but rather social-psychological. Making the experience less painful to the losers is the key problem to solve.
That would fix the candidate pipeline problem because people would be less terrified of failure.
I don't know how to solve it.
To quote Leonard Cohen:
It's coming from the sorrow in the street
The holy places where the races meet
From the homicidal bitchin'
That goes down in every kitchen
To determine who will serve and who will eat
I do not envy anyone in the position of making this determination!
Yeah, the psychology of it is rough. Mental health is something I care a lot about, because in another life it damn near killed me [1], and it's something I plan to write a lot about at least. I'm not sure I have much of a concrete solution, though.
I remember once I worked at a company that was being acquired by another. As part of the screening we all had to go over to the other company to do an algorithms interview. Everyone - including my boss. Our company had a pretty softball interview process and most of our engineers hadn't been through a real gauntlet before.
I knew what to expect, had practiced these things, and made it through. I tried to warn my colleagues that they were in for something a lot more difficult than what they were expecting. But yeah, as you might expect, almost everyone failed.
I remember my boss talking about it, shaking his head slightly, his mouth screwing up into that familiar chagrined smirk so many people get after performing poorly at these things. I told him that these technical interviews are purposely difficult, that most people fail. That it's much better for them to miss a good candidate than hire a bad one. That failing is normal. I could see some of the tension in him subside after I said that. I repeated, "It's normal." He calmed down some more. The word "normal" seemed to help a lot.
I wonder if bringing in elements from psychotherapy might help a surprising amount here. I've found that software engineers highly value rational thought - to a point that they neglect the emotional side of things. A little development of their softer side can go a long way.
Like having a pre and post interview counseling session with a therapist would maybe be a little absurd. But maybe something along those lines would work. Maybe GPT4 could do it.
None of this is a surprise to me, but the specific framing of trying to build these things into the interview is really interesting. It's already something I wanted to write about a lot, but it hadn't occurred to me to put it specifically into the process.
Honestly, having mental health people writing some content doesn't sound like a bad idea at all. I'm sure they hear it all the time; work is one of the biggest stressors in most peoples' lives.
This is true, but the flaw in your reasoning, and in the raison d'etre of NFT's in general, is that social consensus is the be all, end all.
There isn't really the problem of acquiring a 100% perfect copy of an asset in the real world. You can approximate an item, but you can't literally get the same exact thing down to the molecular composition. On the internet, this is absolutely possible (replace molecules with bytecode), and is I'd argue, one of the defining features of it.
The true secret sauce behind modern property rights is the enforcement through legal authority. In the event of a dispute, courts have potentially a few hundred years' worth of precedence. Following that, there are proven legal procedures to remove a person from unlawful possession of another's property, which hold penalties ranging from monetary fines to loss of freedom.
And the driving force behind that is social consensus, but on a case by case basis. There will be no such thing with NFT's. It's simply impossible to build it in.
The NFT is the property. Social consensus is why people want to own it. The blockchain enables the creation of an ownable digital record. Our legal system continue to function and will still arrest you if you steal an NFT.
Most people don’t understands existing IP laws (see what results you get when searching YouTube for “no copyright intended”); adding a new one isn’t likely to improve the situation, so I don’t accept that there is (nor that there is likely to be) a real social consensus in favour of NFTs.
Sure, most things are 'just' social constructs if you reduce them to that, but notice how the state will literally kill you if you break some laws in some ways. Essentially, legal authority comes from a perceived violence monopoly.
> The legal edifice maintaining property rights also requires maintenance.
Hey, just want to point something out here. The quoted sentence is really important. Civil society doesn't just happen, we all (or at least most of us) have a vested interest in maintaining the legal edifice.
So tomorrow, be nice to someone in traffic. And show good grace and community when faced with one of the social frictions (like waiting in line).
Alright. So I go to the clinic and check in with my wife. They take her off to get ready to "receive the sample". A few minutes later they call me up to the desk. The nurse looks at me, pulls something out of the desk, hands it to me with a cup, at tells me to go to room two.
To clarify, since it's relevant, I'm a white guy, my wife is Asian, and the nurse that checked me in is Black. What she handed me was a porn DVD of hardcore Asian porn. I guess she just assumed since my wife was Asian, that's what I was into. I saw in the drawer and there was a variety of choices, but I was never asked.
So I get into the room. To the left is a sink for hand washing with a small counter next to it. In front of me is a very standard office chair, but with a fresh absorbent pad on it (like what you put down when you're house training a puppy). In front of the chair is a 20 inch old-school CRT (this was in 2014, so it was old even then) with a built in DVD player. To the left of the chair is a huge rack with porn magazines.
I evaluate my situation, and decide I'm not going to use the chair, or touch it, or touch anything in the room that I don't have to, because I don't know why it just didn't seem right. Luckily I was smart and brought my laptop with me, so I pop that open and set it on the counter. Attach to the wifi and... all the porn sites are blocked. Apparently they use the same filter as all the other medical offices.
Luckily, being the enterprising engineering that I am, I bounce an SSH session through my home server.
So I start doing my business. I'm standing there with hand occupied, facing the door, when it opens! Apparently the nurse forgot to flip the sign to say "occupied" and also forgot to warn me to lock the door (protip: Always lock the door!). She turned back around and ran out, but I had to start over so to speak.
I finished up, sealed up the sample, washed up, rang the little bell, and the nurse collected my specimen. She was the consummate professional and didn't say anything about the walk-in.
I then went and sat in the waiting room while the doctor impregnated my wife.
ps. This story is a lot better when told in person after a few drinks.
Amusing side note, the doctor was a woman and devout Christian, who believed that she was simply a conduit for God's work, and if you got pregnant it was because God guided her hands well.
Also interesting was that she had the highest success rate of all the doctors in the clinic.
So after having a vasectomy, you also provide a sample to ensure the tubes are really tied. There's a few stories one can tell about vasectomy prep, procedure, and recovery, none of which I'll share here. Anyone who's had the procedure probably has the same stories.
Anyway, generating that sample was something I did at home, but it was still an odd experience driving it to the doctor's office, ringing the bell for the receptionist, and handing over the sample (inside approved collection container which was inside a brown lunch bag as I recall).
Weird for me, but if your a medical office receptionist, you're used to receiving all sorts of samples.
Hey guys. I wanted to see if I could invest my money in a better way than just sticking it in a Vanguard account. I decided to just try buying a bunch of stocks following a bunch of different investment ideas.
I then made a spreadsheet, dumped all my stock purchases into it, tagged each purchase with a strategy, and then averaged together the return on investment for each purchase within each strategy.
The tool helps you see what's working and what's not, and verify that your stock picking ideas are actually playing out well in the real world.
It's nice because it goes under your mattress so you don't have to wear anything. The results seem to be accurate, at least when it comes to detecting tossing and turning vs sleeping.
> they haven't transitioned from SVN to git solely because of the logistical challenge of migrating 30 years of commits
lol, I don't think that's the reason. At the only place I worked that used SVN the real reason was that the old guys didn't want to learn something new.
It may well be the reason. I don't know the parent commenter but speaking from my own experience I recently tried to migrate a legacy code base from svn to git and the common tools all failed for me. One of them ran for ~72 hours before falling over for "reasons".
That was only ~6 years of commit history too. I could imagine 30 years is a whole extra logistical challenge. Not to mention making sure the whole developer base is aware of the change, prepared for it and willing to either update documentation where it refers to revision numbers or write some instructions on how to find a new commit reference from an old revision number.
The tag model is also different between svn and git.
It's not out of ignorance that the switch can be difficult, we've had some projects on git for years and we're comfortable with it.
Just because you've switched easily from svn to git doesn't mean everyone has the same experience.
Same. We have a 20 year old code base we migrated from Perforce to svn about 10 years ago. Now they want to migrate to git. Unfortunately, we can't get it to work either. Same thing - after many hours of running it just fails with typical useless git messages that nobody comprehends. It's quite frustrating.
(And personally, I hate git. I've used it professionally, and while it works, it's very difficult to use compared to svn or p4. Between it's utterly incomprehensible made-up terminology and horrid syntax, and hashes for commit numbers instead of just an incrementing integer, it's quite a bit less useful than svn was for us. But it's being forced on us, unfortunately.)
Maybe the old guys didn't think there was a good reason to switch from SVN to git, if SVN had been working for them. It sounds like switching just because git became more popular.
Of course if you're young, it's no big deal since you haven't been using SVN for decades, and what's the big deal with learning something new? But when you've been around the block a few times, sometimes there's needs to be a better reason than the new and shiny.
I used to be one of the "old guys" fighting against git because subversion is "good enough" and I didn't want to relearn a new tool. I finally had to learn git because a project I contributed to made the migration and I could no longer postpone it. I'd never, ever, go back.
At this point I'd go as far as saying that git is objectively superior to SVN because it does everything SVN can and then more. One caveat being potentially very large repositories and especially repositories containing sub-repositories, git was terrible at that and while it's improved over the past decade it's still a bit messy. Unfortunately in my experience these types of repositories are fairly common in proprietary codebase where people often don't hesitate to commit big binary files alongside the source code.
Still, I'd say that as a rule of thumb if a codebase is still in active use it's probably worth taking a week or so to migrate it to Git unless there's a very good reason not to.
SVN has its limitations, but having used Perforce in my last job and now using Git, I wouldn't mind going back. It's a judgment call, as the two systems have different strengths and weaknesses, but I don't find Git to be an overwhelming improvement. For instance, in Git, if you merge from branch A to branch B while work is underway on both, then merge A to master — and assuming you're using squash merges, as is pretty much essential to get a readable commit history — and then merge from master to B, you're in merge hell, because Git doesn't remember that the squash-merge commit contains some of the changes that were already merged to B. Perforce gets this right: it gives you an equally clear master history, with a single merge commit each time you merge from a branch, but doesn't lose the relationship of that to the individual commits in the branch.
Write down the nicknames. In 15 years git is ripe for next gen source control and then the same ppl will complain who are now advocating what is so hard on migrating
> But when you've been around the block a few times, sometimes there's needs to be a better reason than the new and shiny.
I went through periods where I had to use CVS, then SVN, and then git. The transition period between each one was a little problematic since I had to constantly refer to the documentation in order to learn the new source control commands, but, in my opinion, one should be capable of learning new technologies.
> Why did founders tie themselves in knots doing the wrong things when the answer was right in front of them? Because that was what they'd been trained to do.
Maybe I'm overly cynical, but I see another possibility: They want to create the appearance of running a hot startup without actually having to do the work. Why make something people want when you can just dazzle some investors and get them to dump a million dollars in your lap, no strings attached?
I wonder if that also might explain why such a tiny fraction of startups generate essentially all the wealth -- most of them aren't really trying.
By definition, they only take the top 1%, and 99% of people get to eat shit. Inspiring existential resentment in the vast majority of people who interact with you is obviously not a recipe for good karma.