Hacker News Reader

It depends on many factors, such as experience, learning abilities, and how well people work together. Speaking for myself, I can start becoming useful within my first morning using a new language or technology. Then, given that I'm working with people who enjoy sharing their knowledge, I can be up to speed with them in a week.

What I tend to dislike with the concept of prior knowledge before being let to work on something, is that in the vast majority of cases, once you join a team that has such a requirement, you notice their knowledge acquisition rate is currently flat; they've become stagnant themselves and are generally insecure about what they know and don't know; it's usually people with a currently flat learning curve who assume others need to know a technology prior to working on it; they're just projecting their static mindset onto others.

Some people eat new programming languages for breakfast if they have to. Deal with it?

> Some people eat new programming languages for breakfast if they have to. Deal with it?

Yeah, I understand that because I'm one of them. And this attitude is fine if you're a junior or mid-level developer; I usually just hire best-athlete for those positions for that reason. But if I'm looking for a senior developer, I need someone who has enough domain knowledge that they can come in and lead other people in using that technology. I'm not talking about small things, but if I'm hiring a senior developer for a data services group that uses Cassandra on the back-end, I want someone who at least has some experience building data services at scale with Cassandra (or some other schema-less NoSQL database tech). They need to be able to catch the mistakes that junior guys make.

It's also different if I'm starting something from scratch - you usually have enough of a runway that someone can develop the expertise along the way. But saying language and technology are irrelevant is just naive: the more senior we get, the more we have to specialize (well, either that or eject to the management track). There are simply too many technology stacks out there to do it otherwise.

Agree with all you say. I can pick up languages with ease, but my real value in a team is the baggage of burns I had fighting against the Java ecosystem.

Some day ago one dev here had trouble getting an image parsed, and I remembered being burn by it many years prior, and indeed was an issue with the in-container initialization order of ImageIO extensions. I see this happening more and more as I grew on. As Spolsky said (but I'm sure there were others) experience is having made all the mistakes in a domain.

Presumably in your first email to this guy, you'd say, "Hey, I'm looking for someone to do ASP.Net and Sharepoint."

Is it honestly that difficult to say what you're looking for up front? Or are you scared that when you tell someone that you're looking for those technologies, that they'd go away cause they're not interested?

You make good points, but I think they might be mostly applicable to someone whom you expect to be productive day 1, as in a contractor or on a project with an extremely tight deadline.

I have been in the microsoft ecosystem for many years, and then I did an internship at a Java shop. Granted, a lot of the things there were new to me, but most of them were parallels from the asp.net world. Even if you are looking for a senior dev, maybe start them out as intermediate for 3-6 months, and then re-evaluate them to see if they've caught up and deserve to be made senior at your shop?

> Even if you are looking for a senior dev, maybe start them out as intermediate for 3-6 months, and then re-evaluate them to see if they've caught up and deserve to be made senior at your shop?

That's hard to do in practice. Do you pay them as if they're an intermediate or a senior dev? If they're really a senior dev who just doesn't know your stack, then you're going to have to pay them senior money. What happens if they don't pick it up as quickly as you hoped, and you have an intermediate dev pulling down a senior dev salary leaving no budget to hire a real senior? That's an awful position to be in - development groups without strong technical leadership have high turnover and low velocity. It's almost always better to hire the right person up front.

Ideally you can promote from within for those types of positions, but not every company has a deep bench of talented people.

> you're going to be miserable if I hire you to do ASP.Net and Sharepoint development

That is probably true in general.