4 ms·

Apologies for judging people on their resume, but that linkedin profile shows a series of job, each of them lasting less than 1 year. That's a bit of a concern.

Apologies for judging people on their resume, but that linkedin profile shows a series of job, each of them lasting less than 1 year. That's a bit of a concern. Together with a post that I subliminally read as "if you don't adopt functional programming you are a loser", I'm tempted to look for more grounded opinion on the matter of Google's technical choices. That being said, if you understand functional programming, you have my respect.

ryguytilidie 14y ago
He finished school in 2009 so most of the early ones seem to be internships or part time. He has had 3 jobs since 2009, at Google, LivingSocial and Social Media Networks. All of those places have very good reasons to leave. I have no problem with judging someone based on their resume (I'm a recruiter), but I genuinely don't think there is an issue with this one at all.
- benatkin 14y ago
  Social Media Networks was acquired by LivingSocial, so for the purpose of discussing career habits, that's one job.
luckydude 14y ago
I'm an old guy so you are free to ignore me. A trend I've seen is young & extremely smart people making posts saying "you are doing it wrong, you should use lisp or $whatever_language_they_like". What I haven't seen is a lot of posts from these same people (have seen them from others) where they are talking about maintaining code, bringing new people in who can fix bugs, add features. I think the natural progression for smart people is - wow, I'm dumb, I'm so dumb, I need to learn. - a few weeks/months/years of learning - holy crap, everyone is doing it wrong! They need to use $New_Whiz_Bang! It's so cool, it's objects or functional or has $feature_I_really_like, why aren't they using it? - time passes. A lot of time. Maybe a decade. - Oh, my, legacy code sucks. I don't understand what $programmer did 5 years ago. Holy crap, $programmer is me! - Wow. Customers suck. They want this code to work and $cool_guy embedded a lisp interpreter in the middle of our database and wrote a bunch of cool lisp that I don't understand. And the customer wants it fixed yesterday. And my kids and wife hate me because I work too much. - I really wish everyone would program their code like it was intended to be understood by an idiot. My take? Writing code is easy. Fixing it is hard. It's easier if you weren't trying to be clever when you wrote it.
- tikhonj 14y ago
  I can't comment on Lisp (except to say that Scheme is awesome), but I think you are very far from the mark on functional programmers in general. In particular, Haskellers worry about maintainability far more than normal programmers. One of the main advantages of functional programming is that it makes reasoning about the code--including ensuring correctness--much easier. Haskell enforces referential transparency, limits IO interactions with the type system, allows you to encode some fairly complex invariants in types and, despite all this, has some of the best testing software around in QuickCheck (which goes beyond unit tests). In my experience, Haskell programs tend to have smaller, less coupled parts with better defined invariants. You don't have to worry about a large class of errors right off the bat: you can't get null pointer exceptions, functions you call can't have any unexpected side effects, you won't get type errors at runtime and so on. If anything, Haskellers worry about correctness too much. Happily, this is offset a bit by the language which happens to be very expressive and productive. You can also get very good performance from high-level code and even unoptimized code tends to be decently fast. Some people also find it hard to learn, but that's simply a cultural issue. Somebody already familiar with functional programming has much less difficulty picking it up, but even without much functional experience the basics shouldn't take too long.
  - jackpirate 14y ago
    In particular, Haskellers worry about maintainability fra more than normal programmers. One of the main advantages of functional programming is that it makes reasoning about the code--including ensuring correctness--much easier. This was what finally convinced me to become proficient in functional programming. I'm constantly amazed at how stuff just works.
  - luckydude 14y ago
    So you want the code that makes your hands free car to be written in Haskell? I can just hear the answers: "Why, yes! Because I can prove that it is correct!" Now consider that you are going to get bored at GM and move on. Someone a lot less talented than you is going to go in and modify your perfect haskell code. They don't know haskell, they aren't you, but the code needs to be enhanced. Now how comfortable are you in that car? (I know what you will say, but as an experienced manager, I would not be comfortable in that car.)
CodeMage 14y ago
that linkedin profile shows a series of job, each of them lasting less than 1 year. That's a bit of a concern. Can someone please explain why this is a concern? I've also had a series of jobs lasting usually less than 18 months. Whenever I witness people judging someone as a "job hopper", I wonder why they do it. The only thing that comes to my mind is the idea of "loyalty", but just looking at dates won't give you any idea of why the I changed jobs as often as I did or whether I made sure before leaving that the rest of the company could pick up my work. If anyone can share some deeper insight or a different point of view, I would be most interested in reading about it.
- wpietri 14y ago
  Sure. When I'm in hiring mode and see a resume like that, a few things come to mind. First is the cost of hiring. Filling an open position is a lot of work. Sifting at resumes, initial phone screens, three kinds of interview, hiring paperwork, equity paperwork. The longer someone stays, the bigger the denominator on the cost/benefit ratio. Second is the cost of bringing somebody up to speed. We work in a very specific way (continuous deployment, test-driven development, collective code ownership, pair programming) and learning it takes time. Even if you know all that stuff, the new person still has a ton to learn about the product, the history of the product, and our plans for the future. Again, the cost/benefit ratio improves the longer somebody stays. Especially so if we take a risk on people by, say, hiring somebody who doesn't know our language or our toolset. Third is the social disruption. When somebody leaves a small company, it has a noticeable effect. That cost is hard to quantify, but it's definitely noticeable. The fourth thing that comes to mind is something subtler. I think there's at least some correlation between how long people stay and other personality characteristics. For example, if somebody has never held a job very long, I don't have any reason to believe they have the capacity to stick through difficult circumstances. And the last item is a suspicion of subtle flaws. I'm sure that some people have had a lot of jobs for reasons that are unrelated to them. But then there are the people who are better in the interview than in practice, so they eventually get pushed out. Or the sort who are on their best behavior at the start, but eventually let their personal issues all hang out. Or the sort who are a little grating to start, and end up a lot grating after you've worked closely with them. So whenever I see a resume like yours, it definitely loses points. It doesn't disqualify somebody outright, but all else equal I'll always take somebody who has demonstrated they can stay at a job.

ryguytilidie 14y ago

He finished school in 2009 so most of the early ones seem to be internships or part time. He has had 3 jobs since 2009, at Google, LivingSocial and Social Media Networks. All of those places have very good reasons to leave. I have no problem with judging someone based on their resume (I'm a recruiter), but I genuinely don't think there is an issue with this one at all.

benatkin 14y ago
Social Media Networks was acquired by LivingSocial, so for the purpose of discussing career habits, that's one job.

luckydude 14y ago

I'm an old guy so you are free to ignore me. A trend I've seen is young & extremely smart people making posts saying "you are doing it wrong, you should use lisp or $whatever_language_they_like". What I haven't seen is a lot of posts from these same people (have seen them from others) where they are talking about maintaining code, bringing new people in who can fix bugs, add features. I think the natural progression for smart people is - wow, I'm dumb, I'm so dumb, I need to learn. - a few weeks/months/years of learning - holy crap, everyone is doing it wrong! They need to use $New_Whiz_Bang! It's so cool, it's objects or functional or has $feature_I_really_like, why aren't they using it? - time passes. A lot of time. Maybe a decade. - Oh, my, legacy code sucks. I don't understand what $programmer did 5 years ago. Holy crap, $programmer is me! - Wow. Customers suck. They want this code to work and $cool_guy embedded a lisp interpreter in the middle of our database and wrote a bunch of cool lisp that I don't understand. And the customer wants it fixed yesterday. And my kids and wife hate me because I work too much. - I really wish everyone would program their code like it was intended to be understood by an idiot. My take? Writing code is easy. Fixing it is hard. It's easier if you weren't trying to be clever when you wrote it.

tikhonj 14y ago
I can't comment on Lisp (except to say that Scheme is awesome), but I think you are very far from the mark on functional programmers in general. In particular, Haskellers worry about maintainability far more than normal programmers. One of the main advantages of functional programming is that it makes reasoning about the code--including ensuring correctness--much easier. Haskell enforces referential transparency, limits IO interactions with the type system, allows you to encode some fairly complex invariants in types and, despite all this, has some of the best testing software around in QuickCheck (which goes beyond unit tests). In my experience, Haskell programs tend to have smaller, less coupled parts with better defined invariants. You don't have to worry about a large class of errors right off the bat: you can't get null pointer exceptions, functions you call can't have any unexpected side effects, you won't get type errors at runtime and so on. If anything, Haskellers worry about correctness too much. Happily, this is offset a bit by the language which happens to be very expressive and productive. You can also get very good performance from high-level code and even unoptimized code tends to be decently fast. Some people also find it hard to learn, but that's simply a cultural issue. Somebody already familiar with functional programming has much less difficulty picking it up, but even without much functional experience the basics shouldn't take too long.
- jackpirate 14y ago
  In particular, Haskellers worry about maintainability fra more than normal programmers. One of the main advantages of functional programming is that it makes reasoning about the code--including ensuring correctness--much easier. This was what finally convinced me to become proficient in functional programming. I'm constantly amazed at how stuff just works.
- luckydude 14y ago
  So you want the code that makes your hands free car to be written in Haskell? I can just hear the answers: "Why, yes! Because I can prove that it is correct!" Now consider that you are going to get bored at GM and move on. Someone a lot less talented than you is going to go in and modify your perfect haskell code. They don't know haskell, they aren't you, but the code needs to be enhanced. Now how comfortable are you in that car? (I know what you will say, but as an experienced manager, I would not be comfortable in that car.)

CodeMage 14y ago

that linkedin profile shows a series of job, each of them lasting less than 1 year. That's a bit of a concern. Can someone please explain why this is a concern? I've also had a series of jobs lasting usually less than 18 months. Whenever I witness people judging someone as a "job hopper", I wonder why they do it. The only thing that comes to my mind is the idea of "loyalty", but just looking at dates won't give you any idea of why the I changed jobs as often as I did or whether I made sure before leaving that the rest of the company could pick up my work. If anyone can share some deeper insight or a different point of view, I would be most interested in reading about it.

wpietri 14y ago
Sure. When I'm in hiring mode and see a resume like that, a few things come to mind. First is the cost of hiring. Filling an open position is a lot of work. Sifting at resumes, initial phone screens, three kinds of interview, hiring paperwork, equity paperwork. The longer someone stays, the bigger the denominator on the cost/benefit ratio. Second is the cost of bringing somebody up to speed. We work in a very specific way (continuous deployment, test-driven development, collective code ownership, pair programming) and learning it takes time. Even if you know all that stuff, the new person still has a ton to learn about the product, the history of the product, and our plans for the future. Again, the cost/benefit ratio improves the longer somebody stays. Especially so if we take a risk on people by, say, hiring somebody who doesn't know our language or our toolset. Third is the social disruption. When somebody leaves a small company, it has a noticeable effect. That cost is hard to quantify, but it's definitely noticeable. The fourth thing that comes to mind is something subtler. I think there's at least some correlation between how long people stay and other personality characteristics. For example, if somebody has never held a job very long, I don't have any reason to believe they have the capacity to stick through difficult circumstances. And the last item is a suspicion of subtle flaws. I'm sure that some people have had a lot of jobs for reasons that are unrelated to them. But then there are the people who are better in the interview than in practice, so they eventually get pushed out. Or the sort who are on their best behavior at the start, but eventually let their personal issues all hang out. Or the sort who are a little grating to start, and end up a lot grating after you've worked closely with them. So whenever I see a resume like yours, it definitely loses points. It doesn't disqualify somebody outright, but all else equal I'll always take somebody who has demonstrated they can stay at a job.