DavidWoof

Articles like this seem reasonable on their face, but in practice I really think what they come down to is "I have prejudices, I don't want to admit them, so I have all sorts of soft criteria like 'happiness' that allow me to exercise my prejudices with a good conscience." It's not necessarily simple racial prejudice, it's usually something more subtle around age or social class, etc.. It's a lot like "cultural fit", which often comes down to "something about this person made me uneasy and I don't want to quantify it".

Compare this to Amazon's famous first job ad, which was just "we want top developers". Top devs are going to learn the tech skills that are needed. And hiring managers don't have the magical ability to peer into peoples' souls to determine what makes them happy.

np, I was probably sloppy in my description. In the hand, two players hold AKo, there's another deadcard king in a folded hand, and Postle calls a all-in pre-flop with 54o. That's a +EV call, but only because of the exact combination of cards held by multiple players. There's no way a tell can give him this information.

We're talking about pre-flop actions. It's literally impossible to throw away quads pre-flop in hold-em. You may be thinking about a different form of poker.

There are hands that make this virtually impossible. In one well-known hand where both his opponents have AKo and Postle goes all in. AKo is a very good hand, but it's a much worse hand if two people hold it. Even if Postle had magic face-reading abilities that allow him to always discern good and bad hands, it's absurd to claim he can read exact rank and suit from faces.

I've been Rider almost exclusively for about 2 years now, ever since I've been coding Core. VS is fine, but VS w/Resharper is a dog. With Rider, R# is a first class citizen, which makes a huge difference. Not to mention that the vim emulation and other addons are solid due to being shared with the intellij suite of apps.

I fear we've gone down a wrong turn. You may be 100% correct that fears about instability are irrational and not well-grounded, which is the point you've argued for several posts.

But nobody is arguing with you. Nobody is making the contrasting argument. That simply isn't the conversation anybody is having. It's an interesting conversation, it just doesn't happen to be this conversation.

> At how many lines of code can I call myself proficient in a language?

I would say don't use adjectives to describe skill level. I put most languages I have experience with on my resume, and order them descending by how well I know them. I know the stuff at the top pretty well, and it's downhill from there. In interviews I'm very upfront that I'm incredibly rusty with the stuff on the bottom of the list, and interviewers understand and accept that.

The exception is if you feel comfortable putting "advanced" or "expert" on one of those, but then you had better be able to back it up.

LOC is a bad measure of proficient. I would say you're proficient if you can write a simple program without looking up syntax and relying only on autocomplete for library references.

I think you're wrong. I think companies are completely correct in assessing the cost of a bad hire to be much greater than the loss of a good hire, assuming you're getting enough good hires to fill the positions available.

Now, this assumes that you're not missing out on great hires; in other words, it assumes that the good hires you miss are at the bottom of your hiring range. Your point might be that this can't be guaranteed, and while that may be true, it's unlikely that any tweaks to a given hiring process are going to bring them in either.

Not OP, but there's a group of people who have essentially a good manager's understanding of a project. They understand the trade-offs, they can talk intelligently about technical choices and architecture, and to some degree can even talk about individual modules and classes and language choices.

But they blank at code and struggle with the basics. They get lost for hours at the most trivial bugs. It's weird, but it's very real. Real coding takes a certain kind of abstract thinking that some people just don't have.

I do a lot of consulting as well and am comfortable with it. But most people with families want more stability. I don't know why you're pretending to be surprised by this.

Your personal preferences aren't really the topic at hand.

Upheaval is the issue. First, most contracting firms have pretty crappy medical plans. Secondly, there's generally a wait period before full benefits kick in. Thirdly, you wind up switching your medical plan multiple times in a short period.

That's fine if you're single, but if you've got kids that might mean switching doctors multiple times, which is a gigantic huge deal. Also, you have multiple periods of time where you don't really know your benefits which is terrifying. And if the company does drop you after three months for whatever reason, now you're doing it again.

And keep in mind it's definitely a seller's market if you're a good dev. It's incredibly unlikely that the 3-month contract is the only offer on the table. So all things being equal, who would take it?

It was very similar to the “given an array of stock prices, find the optimal buy and sell indices for the biggest profit" problem that somebody referenced above.

But we emphasized repeatedly we weren't looking for the O(n) solution, just the brute force naive solution was 100% OK. And it definitely didn't look like people were freezing up trying to figure out the optimal problem, they were struggling on the basic nested loop.

Whenever I ask coding problems during an interview, I emphasize any language at all including pseudocode. And if they still struggle, I ask if they could just walk me through it verbally and we can work out the syntax together.

I realize people can still freeze up, but at some point I think there's just no solution to that unless the candidate can produce a significant portfolio. Also, I read your post and it sounds to me like to gained confidence in this area as your coding skills improved, which I don't think is as much a coincidence as you seem to believe.

No, a fizzbuzz test is entirely about whether somebody can do it. That's the definition of a fizzbuzz test. When you hear others talking about a fizzbuzz test, they're not talking about the specific algorithm, they're specifically talking about a simple single-function problem that should take no more than 5 or 10 minutes.

If you're dealing with user input or linting, then that's not a fizzbuzz test. I'm not doubting that maybe somebody asked you to do something larger than that including the fizzbuzz problem, I'm just saying that nobody else here is talking about take-home problems when we talk about fizzbuzz.

They could in theory, but nobody wants to. I used to see probationary periods, but I haven't seen a company use that for salaried staff for a long time. HR and Legal have put an end to that kind of thing.

So Jim is right, in practice the only way HR is going to let you have a probationary period is to use contractors, and that limits your hiring pool significantly.

Slightly above market rate for the area, all in the low-to-mid six figures.

#1 is great, but impossible for a lot of people due to NDAs. The 3-month probationary period is indeed the only way to really evaluate devs, but I'm not so sure it's a good way to hire them. After 3 months, the mediocre devs have friends, etc., which makes it hard to get rid of them without creating a weird morale issue and massive team disruptions. And then you have to add in the limiting effect on the hiring pool (though I wonder if that really matters, I suspect good devs know who they are).

Number 3 is my favorite, but there's a trade-off: almost anything large enough to allow for multiple designs is probably too large to require all applicants to complete. But I also love having a candidate discuss their own code. I'm really curious what types of exercises you have for this kind of thing, and where it fits in the interview process?

I realize everybody's going to jump in and rant about algorithms in interviews, but I wish you'd all add something constructive as well.

I just had to conduct a round of interviews in a non-SF large US city, and it was a hellish crapshoot. Resumes are meaningless, and often re-written by recruiters to match the job anyway. Everyone has the same canned answers to the stupid behavioral questions. And as for the code, we included what we thought was a trivial nested for-loop problem and virtually nobody could even get started on it.

Is this kind of code problem too complicated in your opinion? For all I join in when complaining about irrelevant algorithmic questions, I have to admit that they at least test something, even if it's just willingness to study for the interview.

Instead of reading everybody's complaints about interviewing, I'd love to hear how you think it should be done. Because I have to admit I'm pretty much lost right now.

The reason people doubt it is that developers tend to group at skill levels. It's rare to have a 10x difference in a single shop or on a single team. But it's very common for the top dev at a top company to be 10x the worst dev at another company for any given task.

What most people forget is that the 10x figure only measured those who completed the task. For any given task, there are definitely 0x devs and devs with negative velocity.

I assume the author is the Betty Friedan. This would be about 5 years before she wrote The Feminine Mystique, easily one of the most influential books in modern history.

It's kind of fascinating to see her here at 37, working in obscurity, knocking out fairly pedestrian writing assignments, when in just a few years she's going to change the world.

In the spirit of this thread...

If a child lives in X, he/they will Y. If a child lived in X, he/they would Y.

This comment makes me feel really old.

MacOs wasn't always layered on unix, and the unix-haters' handbook predates the switch to the unix-based MacOs X.

"Going away" might be an overstatement, but I don't see much evidence of it being in use. When I search for help on topics, I don't see much beyond the primary docs. There doesn't seem to be much of a community for swarm out there, and now even the desktop versions of docker come with k8s.

I've had small-ish docker swarms in production for a couple of years as well, and I really don't understand why it doesn't seem to be popular at all. I feel like I need to move to K8S just because swarm seems to be going away, but I'm really not seeing the technical advantages at all.

If someone could point me to an article explaining why k8s is so much better than swarm, I'd really appreciate it. Are the big advantages only at 100-node scales?

> Hiring highly competent people to build software does not scale as well as hiring (many) more less competent people.

I can't imagine an aphorism I disagree more with. I constantly come across companies with similar-sized platforms where one has a development staff 10 times the size of the other (both in cost and size), all due to the complexity and quality of the code. In the long run, few things are more expensive than a mediocre programmer.

As a customer, the late 90s were the absolutely most frustrating time to deal with computer customer support. In virtually every case, it was obvious that the customer support person was simply reading from a support database that the company hadn't bothered to put on the web yet, and yet to get these answers it was necessary to let the operator, who generally had no tech knowlege, walk you through a long script of repeating obvious steps until finally you would get to step 50 in their script that said "if you get error 87AB with an nvidia graphics driver, you must frazz the foo in the bios settings", which is all I wanted in the first place.

Gateway was one of the worst, since they generally had OEM versions of hardware that required special driver settings that were completely undocumented. Since this type of thing is generally online now, I honestly don't think I've called customer support for any personal product in over 15 years.

The focus of this article is on right-wing extreme content, but I think the tendency is true on both sides. The fact is that partisans are more likely to seek out news content, and partisans are happier with content that matches their prior viewpoint. And so the extreme content rises in popularity and is presented as the recommended option to the less partisan.

It's a worthwhile question as to whether this is a flaw in the algorithm or if the algorithm is simply accurately mirroring democratic preferences. Maybe everyone's tendency is toward more politically extreme content, and youtube is simply giving the people what they want. Which is, after all, what YouTube probably sees as the correct goal.

The missing variable here is whether the market share represented by Billboard #1 songs has increased or decreased in this time span. Is everyone listening to more homogeneous music, or is the market for #1 songs shrinking to a smaller and smaller demographic?

I honestly don't know the answer, but a few decades ago in most towns the majority of the public listened to just a few radio stations and everybody knew the top songs. In the Spotify age, I'm far from certain that's true.

I'm a programmer in my late 50s. While age discrimination is real, and I certainly have my share of "not a culture fit" and "overqualified" rejections over the past 10 years, if you're getting rejected over 90% of the time then I strongly suspect the problem isn't age discrimination. It's much more likely that your skills are out of date or you've gained some bad interviewing habits that you should examine.

If people want to filter applicants based on age, it's pretty simple to do so before the interview stage.

This reminds me of the discussion of "quality" in Zen and the Art of Motorcycle Maintenance, where the class finds that while nobody can exactly define quality, when confronted with high and low quality writing everybody could recognize which was which.

As OP realizes, nobody thinks Knuth's ACP is poorly written even though it's hard. The elegance is obvious, even if the algorithm is hard to understand. On the opposite end, I've come across FizzBuzz implementations from job candidates that I've struggled to follow. I've often seen a 10-1 difference in code sizes for different implementations of the same problem, and while there's edge cases where smaller code can start to become confusing, generally every dev on the team recognizes which of the two is more readable.

I have no problem with the idea that there can be subjectivity in discussions of readability. But the idea that readability is purely subjective, or only has to do with differing styles is ridiculous. In fact, I don't believe for a second that OP really believes this. He wants to make a point about subjectivity, which is fine, but for some reason has chosen to write it in this exaggerated clickbait style.