3 ms·

> If you really care which programming languages I already know or which applications I have used before, I can only assume that you're overlooking my ability t

by exelius 11y ago

> If you really care which programming languages I already know or which applications I have used before, I can only assume that you're overlooking my ability to quickly pick up new technologies and adjust to new ways of thinking. I would encourage you to correct this, as it is a mistake. I don't know that these questions are necessarily bad. Often, when I look to see what programming languages someone knows, it's to see if they're operating in the same ecosystem. If you've spent your career writing Java, Ruby, Python and Erlang, you're going to be miserable if I hire you to do ASP.Net and Sharepoint development. You'll probably be fine if I hire you for a Scala job. You're also not going to be as experienced in the quirks and design patterns in that ecosystem / framework. I'm ok with hiring people who are smart enough to figure it out, but if I'm looking for a senior developer I want someone with some domain expertise who's not going to be learning hard lessons on the job. If it's an existing project, I may not have the luxury of picking the best tool for the job, so I may need to hire people who know the tools that we have. That includes not just the ability to pick up the technology, but knowing from experience how it behaves at scale in a full-stack configuration.

cpplinuxdude 11y ago
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?
- exelius 11y ago
  > 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.
  - LoSboccacc 11y ago
    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.
it_learnses 11y ago
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?
- exelius 11y ago
  > 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.
s73v3r 11y ago
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?
greydius 11y ago
> you're going to be miserable if I hire you to do ASP.Net and Sharepoint development That is probably true in general.

by exelius 11y ago

cpplinuxdude 11y ago

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?

exelius 11y ago
> 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.
- LoSboccacc 11y ago
  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.

it_learnses 11y ago

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?

exelius 11y ago
> 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.

s73v3r 11y ago

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?

greydius 11y ago

> you're going to be miserable if I hire you to do ASP.Net and Sharepoint development That is probably true in general.