|
|
|
|
|
|
by MetaCosm
4216 days ago
|
|
|
> I've known some engineers to argue that the number of languages on a CV is negatively correlated to the quality of the candidate. The song sung by old engineers who refuse to learn new technology, so they try to make knowing few a positive (it isn't). The classic "It's not a bug, it's a feature!" I don't think the core of a good developer has changed much since the early 90s. You still want people whose skill-set is T-shaped... You want them to go deep on at least a few domains, but you want them to have broad experience in lots of them. The broad experience makes for developers who are better than the sum of their parts, can adopt solutions from other domains and can communicate better. I generally won't consider too seriously a "senior" engineer who has only a single "class" of knowledge. I realize that sometimes they have limited control over this (the jobs they happen to get, yada), but I just want the best developers... and in my experience they find a way to follow Norvig's advice and at least toy with some of the major flavors: DBC, functional, class, syntax, declarative, concurrent, parallel... |
|
|
I think Michael's point was that a senior developer might have a very different idea of what constitutes "deep" to a junior developer.
By the standards of a 20 year industry veteran, a six month project they worked on three years ago using language X might not even make X worth mentioning unless it was specifically asked for, next to the half-dozen languages they already show where they have 5+ years of experience including shipping multiple projects in each one.
By the standards of a junior 2 years out of school, a six month project working in language X last year might make it one of their top two languages and get presented as "expert-level" understanding. These are the people who tend to list fifteen programming languages, because they used each of those languages for about five minutes on a toy project during their CS course.