Hacker News Reader

Comment by wwweston | Hacker News Reader

The weirdest part about this is how many companies fail to properly estimate the degree to which per-project on-the-job-training / on-boarding is inevitable even if you check every language/datastore/framework/tooling box they could possibly ask for. Checking those boxes can be helpful, but unless there's no value in your software other than that provided by the l/d/f/t, your software has something like domain specific knowledge. Or at least a somewhat niche linear combination of other pieces of such knowledge. And a person who can fill in those blanks on their own -- as seems to be expected for a fair number of positions -- is probably capable of filling in l/d/f/t gaps too.

(OP: email's in the profile if you're interested in making a potential contact; hiring is on the horizon where I'm at.)

View on HN

Onboarding in domain specifics is different.

Language and programming fundaments have to be taught, and companies rarely have any decent processes around it, and it eats a lot of time from other developers. Domain knowledge can be gathered from literally anyone in the company, and also unless you are a senior, you don't need that much of understanding.

Moreover, you can do some tasks without knowing anything – fixing nasty bugs nobody has time for, automating some stuff. During doing that you can get some ideas what it is about. Another point is that person with experience already immersed into other/same domain in the past projects.

The term domain knowledge may not be specific enough to convey what I'm talking about; "domain app logic" might be closer to what I'm getting at. It's the domain specific portion of a given system. It (hopefully) represents domain knowledge or is oriented around a process informed by that knowledge, but it's encoded in the software (and docs, if any).

I can see why many companies don't often have a process around teaching programming fundamentals and prefer to hire those who can demonstrate competence in one or more languages. I understand less why companies with a determination to build their team rarely have any kind of methodical approach to introducing developers to their systems and seem to prefer sink-or-swim ad hoc task assignment.

There's a consistency to that approach with the approach of a precise list of specific stack/tooling requirements, of course: it says "we want to rent talent, not develop it." And that approach has its merits, even. But there's an inconsistency, too -- if your primary approach to introducing people to your existing systems is learn-by-flailing, why be concerned about avoiding that with frameworks and languages, too? Especially when, as far as you're concerned, the familiarity that matters is with specific languages and frameworks as used by your system.

Reply on news.ycombinator.com