Re^4: Interview Questions

Actually, the original question was solely "senior developer", which, and here's my hubris again, yes, I think I should be applying for - since that is really what I am right now (over 10 years with C/C++ should qualify, and more soft-skills on my resume which I won't get in to). Even before I started with perl, I was already pretty close to calling myself a "senior" developer (at least, relative to the team I'm on, I already was the senior developer, which may say more about the team than about me, but I'll cling to the term "hubris" again for this).

Sure, I may not be in a position to train people in Java. But it would likely take me about a year to be at the point of calling myself a "senior" Java developer for most projects. It's just a language.

Same thing here. What is more important - length of time in perl, or simply real amount of knowledge of programming principles? I've known some contractors with significant amounts of perl experience whom I would probably avoid for long-term permanent hiring. On the other hand, there is one student who I want back badly, and would have every confidence that he would pick up Perl in no time, and be extremely productive at it.

Training someone in a language is easy, if they have the skills in programming that you need. The other way around is much more difficult (and thus expensive).

At least in the company I work for, this is delineated by the ways we hire contractors (based largely on language skills: "we want to transform this spec to this language, do it.") and students/permanent hires (based largely on general experience and ability to learn).

Comment on Re^4: Interview Questions

Replies are listed 'Best First'.
Re^5: Interview Questions by tilly (Archbishop) on Apr 04, 2005 at 17:17 UTC
It is easy to have 1 year of experience 10 times, and think that you have 10 years of experience. I have no idea whether this is true for you. But it has been true for a number of people that I've worked with. Back to the topic at hand, Perl is a very different language than C or C++. Sure, it is easy to write C in Perl. Just like you can write Fortran in C. If your C coding habits are clean, the result won't be that bad. But it won't be anything close to idiomatic Perl. Your answer a couple of posts ago demonstrates exactly how non-idiomatic. Which is why I'd prefer to see more Perl experience in a potential mentor or lead programmer on a Perl project. (And I'd like to see experience of the sort that leads to "5 years of experience" rather than "1 year of experience repeated 5 times".) On your comments about ability to learn being more important than existing expertise with a language, that can be very true. I've been in the position of hiring people who I was supposed to teach Perl to, and have some idea how to do it. However it is somewhat hit or miss, you can't know in advance whether a given person will readily adapt to new ways of thinking or not. And there is always a learning curve. So if I'm hiring to lead, I want to pick someone who I think can grow, and who also has the skillset I want. I want both.	[reply]

Replies are listed 'Best First'.

Re^5: Interview Questions
by tilly (Archbishop) on Apr 04, 2005 at 17:17 UTC

I have no idea whether this is true for you. But it has been true for a number of people that I've worked with.

Back to the topic at hand, Perl is a very different language than C or C++. Sure, it is easy to write C in Perl. Just like you can write Fortran in C. If your C coding habits are clean, the result won't be that bad. But it won't be anything close to idiomatic Perl. Your answer a couple of posts ago demonstrates exactly how non-idiomatic. Which is why I'd prefer to see more Perl experience in a potential mentor or lead programmer on a Perl project. (And I'd like to see experience of the sort that leads to "5 years of experience" rather than "1 year of experience repeated 5 times".)

On your comments about ability to learn being more important than existing expertise with a language, that can be very true. I've been in the position of hiring people who I was supposed to teach Perl to, and have some idea how to do it. However it is somewhat hit or miss, you can't know in advance whether a given person will readily adapt to new ways of thinking or not. And there is always a learning curve.

So if I'm hiring to lead, I want to pick someone who I think can grow, and who also has the skillset I want. I want both.

[reply]