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.
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!
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.
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.
> 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.
It should be stated that the flip side of not giving up is incurring the massive opportunity cost of years of lost compensation. That can easily be over a million dollars for a good software engineer.
If you're a genius, then sure, not giving up makes a lot of sense. But if you're just pretty smart, you better think two, three, or four times before committing to do a startup. It's really easy to end up over thirty and broke.
> add each number in a list x to each number in the corresponding row of a two-dimensional array y
I mean, I could write a function `add(x, y)` that does that in any language. You could even inspect the data or type to make it polymorphic. I believe NumPy does this, for example.
Skimming the rest of the article, I don't get how this is different from any other language. The primary difference seems to be the function names are all one or two characters long for some reason. I must be missing something...
> "These planets are much, much too far away. Even in the very optimistic case of a livable planet that is not too far, say a few dozen light years...We are talking about hundreds of millions of days using the means we have available today. We must take care of our planet, it is very beautiful and still absolutely liveable."
That's actually a good point and one I hadn't really thought about.
The only way I can think of for humanity to get to these other planets would be to build a network of self sustaining space station colonies. And if we can do that we don't really need planets any more.
And in software development, the primary bottleneck is thinking. Anything you can do to enable greater clarity of thought is going to have huge leverage. So I think this is a super promising angle.
Bret's actively developing his ideas at DynamicLand: http://dynamicland.org But clearly it will be quite some time before that tech becomes viable in the real world.
Now I'm wondering if there are simpler ways to use the rest of my body to facilitate thinking. Like, I can't mount lasers and network connected cameras on the ceiling... but maybe there's some software that can use a webcam to do simple gesture recognition mapped to bash scripts or something like that.
It was a Flask app using SqlAlchemy (so Python). I'm not sure functional programming would have changed the situation much. I imagine there would still be repeated patterns involving reading and writing to the database in slightly different ways, and it would still make sense to use some sort of library. But I haven't used functional languages much, so I can't say for sure either way.
This was my position for a while. ORMs introduce a layer of magic which obscures what's actually going on under the hood. I decided I would just make raw SQL queries and handle mapping data explicitly.
I quickly ended up with a lot of duplicated code. So then I thought, "Well ok, I should add a bit of abstraction on top of this..." I started coding some simple functions to help map the tabular data to objects. One thing led to another and suddenly I looked at what I had done and said, "Wait a minute..."
According to the Amazon summary from the linked book:
"a major shift in prosecutor behavior that occurred in the mid-1990s, when prosecutors began bringing felony charges against arrestees about twice as often as they had 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.