Hacker News Reader

> If someone has decent problem solving and analytical skills, can understand the problem domain and has the capacity to learn a new language/framework/construct in a short period of time (which frankly most of us can, and do with frightening regularity), unless you have something miraculously niche and technical, they're capable of doing the job.

Agreed. And this was how hiring was done up until about 15, 20 years ago. For example, if you knew C++ they figured you could pick up Java. Or if you knew Perl, you could be assumed to be able to pick up Ruby or Python. But in recent years that's not been the case - you mostly get screened out well prior to any human seeing your resume if you don't have all the right buzzwords. Hopefully the tightening job market with companies (supposedly) having trouble finding people will get us back to more sane hiring practices.

I beg to differ on that. On my experience, both interviewing and being interviewed, capacity to learn and adapt to different languages and proven experience of having done that lifts the bar significally and accounts for most of the tecnical requirements, the rest being just practical knowledge or solid fundamentals.

For sure there will be places on which the person weeding out resumes might miss that a competent programmer on most interpreted languages can jump between them and get up to speed pretty quick. Such places I would avoid anyway. At least on my echo chamber, I thought these were on the minority nowadays?

> Agreed. And this was how hiring was done up until about 15, 20 years ago. For example, if you knew C++ they figured you could pick up Java. Or if you knew Perl, you could be assumed to be able to pick up Ruby or Python.

That's why FAANG still do whiteboard/algorithm questions.

If implemented properly you get a good idea of who can code and solve problems, and who can't. Of course, there are false positive and false negatives, but the signal to noise ratio is pretty good.

This is how I interview as well. Though I usually have a fairly good idea who I want based on my network before HR ever get involved.

> That's why FAANG still do whiteboard/algorithm questions.

> If implemented properly you get a good idea of who can code and solve problems, and who can't. Of course, there are false positive and false negatives, but the signal to noise ratio is pretty good.

I see the idea, and I try to focus interviews on 'show, don't tell', but is there research supporting better outcomes?

> is there research supporting better outcomes?

Sadly it's all empirical.

Since when is research not considered empirical?

That's too bad. I was hoping for conjecture.

I see it as placement of the gatekeeping filter.

Do you trust HR or the hiring team more to filter candidates?

It's a valid question. Keyword / minimums tilt the balance in HR's direction. Whiteboard / algorithm questions tilt towards hiring team.

I essentially hired one guy I interviewed because he seemed intelligent and did motorcycle work on his own. Had some background in the specific subject, but I'd rather hire a demonstrated ability to learn & initiative. (Afaict, he's thriving and a great fit for the position)

> I essentially hired one guy I interviewed because he seemed intelligent and did motorcycle work on his own. Had some background in the specific subject, but I'd rather hire a demonstrated ability to learn & initiative.

Me too, and I respond similarly to information like that. But the #1 hiring bias is hiring people like yourself. It's possibly I am just falling victim to that bias.

> It's a valid question. Keyword / minimums tilt the balance in HR's direction. Whiteboard / algorithm questions tilt towards hiring team.

Keywords are almost always pointless. I've seen extraordinary resumes that ticked all the boxes, yet 20 minutes in there was not a working FizzBuzz on the door.

Problem is, as the hiring manager you're not going to see the resumes that didn't meet the keyword minimum. You're only seeing the resumes that made it through the filters.

Engineering managers should dictate the filter to HR, not the other way around. If it's the other way around, that's a big red flag.

> Most degrees and professional certifications are meaningless to people who only care about the knowledge - there's no point in chasing paper that's out of date the minute the course is designed.

This is a stretch. Most of what you learn in a CS curriculum is extremely useful. Things like algorithms, computer organization, object oriented programming, operating systems, networking, mathematical approaches, etc. aren’t going anywhere anytime soon.

Fair. Perhaps I was over-zealous to include degrees in my statement.

Yes and no. I have never implemented so much as a linked list never mind any more complicated data structures at $JOB. These things are provided by standard libraries.

But knowing what they are, and when to use them, is useful. As is the general background knowledge when it comes to understanding something new (since everything devolves to machine language eventually).

> Yes and no. I have never implemented so much as a linked list never mind any more complicated data structures at $JOB.

And I never divided four digit numbers per hand, yet I don't think we should drop the requirement for primary school math. I fully agree with your second point, but I think the critic is getting too hung up on the vehicle used for teaching these concepts. You don't need to implement a linked list per hand in your day job, but you need to grasp the concept and have an easy task to learn to program on.

So when should you use linked lists ?

My undergrad course didn't say shit about losing cache locality + indirection overhead, allocation cost per entry, etc. You will almost always be better off using whatever the default List implementation is in your standard library, and if performance really matters you will be better off using some optimized tree or whatever fits your use case and measure. Languages these days are not C, you are provided with really good defaults, reading the usage docs and ignoring the internals will yield better results than basic theory without testing your assumptions. You really need to know what you are doing to beat the standard library offerings - and knowing what is available > having a grasp of the underpinnings.

Knowing about algorithms can be useful, recognizing your data structure is a cyclical graph or a DAG, implications of it, knowing how topological sort works, etc. is useful - but even there - if you are good with search you can find the solution to your problem, you will just take more time.

It's extremely easy to "beat" the standard library offerings by incorporating what's unique and specific to your situation. They have to be super generic to be in a standard library. Of course, don't re-implement a completely generic list data structure. But implementing a particular kind of dictionary that takes advantage of assumptions that are true for your use case (but not true in general) and is custom tailored to your environment is extremely valuable.

>But implementing a particular kind of dictionary that takes advantage of assumptions that are true for your use case (but not true in general) and is custom tailored to your environment is extremely valuable

This requires way more knowledge than I got from my undergrad classes and in comparison learning that part is trivial forward to the hard part that you can pick up in "refresher" part of a book/article on the topic.

I doubt your average undergrad could do it so I disagree with the extremely easy part as well (heck I doubt they could write a bug free version in the first place, even less a better performing one) that a correctly selected std lib container. Well at least not without researching and testing a bunch at which point the background knowledge is trivial in comparison.

> but you need to grasp the concept and have an easy task to learn to program on.

"We have to reinvent the wheel every once in a while, not because we need a lot of wheels; but because we need a lot of inventors." -- Bruce Joyce

You have never implemented a linked list or anything more complicated? What the heck do you do all day!? I create new data structures all the time!

Likely creating and debugging http endpoints or web pages within the limits of popular frameworks. Those are the jobs like 90% of developers works on.

My step son is getting into programming and he told me about a console app he wrote where he stored the data in a flat file. I suggested he look into storing it in json format.

For me, the biggest benefit of a degree is more to show you what you don't know in pretty broad strokes. It's up to you to investigate deeper either on the street or with a more specific curriculum.

Broadening the possibilities of knowledge is pretty big. I've known of several otherwise great self-taught developers who didn't know much about database design because they just never really ran across it.

It often resolves to “we want someone that is supposed to be 100% efficient from day one”

When that assumption is explicitly discussed and dropped, the job postings can be backed to realistic levels of expectations and interviewers get more leeway on choosing profiles that could be interesting down the line instead of just playing Tetris with the listed qualifications.

Nobody can be 100% efficient from day one, because even with all other things being equal, the new guy still has to learn all the idiosyncracies of your existing codebase (which is quite likely full of technical debt and poor decisions), your team, your process, your management style, your politics.

Realistically, even the basic "we want someone that's 100% efficient from day one" is the most unreasonable expectation you can have as a hiring manager, and is usually the one spurring the "high quality candidate shortage" complaints.

IMO, if someone thinks you are going to get much work done the first week they are out of their minds, or their software is a trivial console app contained in handful of classes.

I could probably jump into a new position and start cranking out code fast, but it would be different than any code in the existing code base, and could apply techniques not used by anyone on the team. This would result in an awful piece of code to maintain for the team.

There are just so many different ways of writing code that a dev would probably need a few weeks to get comfortable with the code base. I speak openly about this during interviews. One interviewer from a fortune 1k company said I would be given about 6 months to get comfortable with the code base and start with smaller tasks. Another company said I would be building trivial things for a few weeks before touching the codebase.

Unless it is a fresh project there is no such a thing as jumping in and cranking out code day 1.

I've written code on day one at some positions. Usually it's something simple like a bugfix or refactor, but it is certainly working code. Of course, most of the time I spend doing this is figuring out how to work with the codebase and how to submit my changes.

The best hires I've ever made have started submitting code reviews within 24-48 hrs of being onboarded. Sure it's not for something like Microsoft Windows, but still this has been a hallmark positive indicator of a good hire for me, and applicable to many (but not all of course) frontend, backend, and app development projects.

Now maybe there is some discussion to have about what "100% efficient" means. Of course they will not hit their peak of productivity on day 1, and anyways if 100% efficient means the most productive day they've ever had, then they will more days than not be < maximally productive.

I would wager your codebase, tests and development environment reflects this. Any product of any significance requires a day of setup at least before you even get as far as cloning the repo and opening your first user story.

Well, first of all, ouch. Sure, of course you're right about "product of any significance" and I mentioned one myself in my post - Windows. The more complex the project/team is, the fewer people will be productive in 24-48 hours. So yes you can arbitrarily set the bar as high as you like for what "significant" means for you to be correct.

I think it's not a bad metric if you have hired someone fitting right into your current stack.

Now I am sure you had cases where you hired someone that didn't quite fit, but seemed interesting, and you were confident they'd get up to speed and pull their weight in a reasonable time frame (3 weeks ~ a month ?).

I'd argue focusing on the second category of hires as a target, and consider it a lucky event when someone exactly matches what you're doing, can lead to a more stable/less homogeneous team.

That's a fair point. In the life of my startup so far, we haven't been blessed with the room to allow us to hire people that we don't think will be productive for a month. For an established company though, I agree it's a totally reasonable measuring stick for good hires.

> most developers never really grow out of solving problems

Do you see that as a maturation process? Is this about moving into management?

> Most degrees and professional certifications are meaningless to people who only care about the knowledge - there's no point in chasing paper that's out of date the minute the course is designed. We don't want that knowledge, it's old. We want current information which the courses and qualifications haven't been designed for yet.

A couple of additions or objections (depending on how some of those terms are understood):

If you care only about knowledge, then you don't care if it's the latest thing or has any application (though I rarely encounter knowledge that has no application). It you care about job skills, and about knowledge only to the extent it serves those skills, that's a different matter.

Also, you can learn about all those technologies, old and new and future ones too, by learning theory. Theory is the most applicable knowledge; it applies to and predicts everything - just like theories in physics predict how every object behaves, now and in the future, not just specific objects in specific contexts. Theory empowers you to solve novel problems and learn the novel tech.

Generally, I think the best way to learn knowledge, including theory, are good degreed programs: They are designed by experts (how do you design a course of study for a subject you don't know?), you have experts guiding and coaching and mentoring you along the way, and you have access to assets from labs to libraries to peers.

So I can only speak for myself personally. But my perspective is that all the stuff on the exams, I already learned long before the courses became current and have moved onto the next thing. So by the time the course arrives, I no longer care about the content it's delivering because I already did all that. By the time the course comes available for the things I'm learning now, I will already know it and have moved onto the next thing. So that's why those who care about the knowledge don't tend to care about the certificate - because it's a waste of time for us to go back and cram for an exam that's based on technology that has evolved (and thus the material is out of date/no longer accurate, flat out wrong).

I think it is a filtering problem. Back then game companies would advertise on the manual. Local ads got posted. You heard about something and picked up a phone.

In the online world, job ads are not hard to find. People apply to them en masse. You might as well just set a harsh limit so you only consider the best and don't waste your time. I guess the other approach is to just hire the first 'good enough' to walk in. But everyone wants value for money.

It's the exact same as having a UAI/TER score to get into University here. Sometimes it indicates required intelligence, but often it's just a popularity cutoff. They can't accept everyone.

There’s no resume entry for polymath, and what you’re describing is a developer who is at least a mediocre polymath. Not all of us are.