7 ms·

"Those VP jobs just don’t exist at startups, and the few VPs they have are the founders and a key early hire or two. Not you." That's probably not fair. Succes

"Those VP jobs just don’t exist at startups, and the few VPs they have are the founders and a key early hire or two. Not you." That's probably not fair. Successful startups are looking for talent, not pedigree - it's a question of whether the candidate can add significant value as a VP. I think this blog post get's distracted from it's original point - if you're a software developer looking for a software developer position then emphasize software development skills. This applies to small companies and even big companies (like Google). The skill set to be a good developer is consistent no matter what the size of your company. This doesn't mean that startups don't need business, product, or technical leadership because all the best ones have shown they attracted all these very early.

tptacek 18y ago
So, even though I think Spolsky's posts have gone further and further off the rails, this is one that resonated with me: * first, management jobs in startups do go to the founders and "key hires" (definition: if you have to ask if you are one, you aren't) --- and * the key predictor for whether someone does well in a startup has, in my experience, been how willing they are to write lots of code, as opposed to just talking about code. Every bad hiring decision I have ever contributed to has involved allowing myself to be impressed with someone's design/architecture/methodology/"engineering". Conversely, everyone I've ever neg'd because they didn't seem grounded or professional enough has gone on to depants me in the commit logs.
- ghshephard 18y ago
  Even though I recognize you meant this, I'd edit your key predictor to read, 'the key predictor for whether someone does well in a startup has, in my experience, been how willing they are to write lots of _good_ code" I've been at several startups where the developers who made the most difference where those who wrote concise, correct, and elegant code that did the job, and nothing more. They didn't get distracted into writing "architectures" when all that was needed was a "tool." Their code was a pleasure to build upon, and people instantly respected their ability to bang it out. Sometimes less is more.
  - tptacek 18y ago
    I actually didn't mean that. I meant: write lots of code. The bad decisions I made? (a) thinking that people who could talk and talk and talk about code (shut up I'm not interviewing with you) would write good code (b) thinking that people who couldn't explain why they'd ever use a red-black tree instead of a hash table would write bad code. I'm making a case for more-is-more. People who write code (really write, sure, not cut-paste) have work ethics, are really into actually writing code, can easily be trained to bring them up to a median "engineery" standard of code, and get stuff done.
    - randallsquared 18y ago
      That's an interesting and intuitive-after-the-fact observation. Thanks.
    - swombat 18y ago
      (a) It's not really the fact that they talk about code, imho, it's what they say about code. Anyone who's clearly a passionate geek and writes weird and wonderful programs in their spare time is likely to be good. (b) I don't know how to answer that question, but I could easily look it up if I was doing some work that required this sort of optimisation. Despite that lack of knowledge, I've built two start-ups now.
      - tptacek 18y ago
        You use a hash table when you just need lookup. You use a tree when you need sorted order. The only tree worth using is a red-black tree. There, now you don't need to look it up. ;)
        swombat 18y ago
        Cheers :-)
        wheels 18y ago
        If I asked that question in an interview, and that's the answer you gave, I'd probably not hire you (assuming the position was CS-intensive). There are a number of special-purpose trees which are important in some domains (tries, B-tree, splay tree, ...) Simple hash implementations also tend to assume that it's cheap to compute a hash on the given key type (not always true) and that you have a rough idea on the bound of items in storage. Hashes far below that level are often also less memory efficient since the hash-table is pre-allocated.
- bootload 18y ago
  I'd agree with pretty much all except the below quote. "... So, even though I think Spolsky's posts have gone further and further off the rails ..." From the article ... "... But for startups, everything about your resume has to scream getting your own hands dirty... the only thing we REALLY need is code to be written, and customers to be called on the telephone ..." reads to me, on-track. One thing I have noticed is JOS has always been skewed towards JOS type businesses (privately owned, bootstrapped software development companies) rather than Startups (fast revenue based technology companies that in the end are either sold or IPO'd). So the stories seem misaligned.
  - tptacek 18y ago
    The off-the-rails comment is due to the blog's trend away from things like critiquing the Win32 API and talking about software scheduling, and towards Spolsky's theories of company management. It's the Inc. effect. His writing is also less engaging now than it was 3 years ago; fewer stories about crazy bread machines, more bland prescriptions.
qhoxie 18y ago
This applies to small companies and even big companies (like Google). The skill set to be a good developer is consistent no matter what the size of your company. I agree only partially. It definitely applies to all sizes of companies, but larger companies seem to care less about it during interviews. This is a large part of why startups work more efficiently on average.
- nostrademons 18y ago
  I dunno about other big companies, but Google seems to care about it a lot.
  - qhoxie 18y ago
    Agreed, they are an anomaly there in my mind.

tptacek 18y ago

So, even though I think Spolsky's posts have gone further and further off the rails, this is one that resonated with me: * first, management jobs in startups do go to the founders and "key hires" (definition: if you have to ask if you are one, you aren't) --- and * the key predictor for whether someone does well in a startup has, in my experience, been how willing they are to write lots of code, as opposed to just talking about code. Every bad hiring decision I have ever contributed to has involved allowing myself to be impressed with someone's design/architecture/methodology/"engineering". Conversely, everyone I've ever neg'd because they didn't seem grounded or professional enough has gone on to depants me in the commit logs.

ghshephard 18y ago
Even though I recognize you meant this, I'd edit your key predictor to read, 'the key predictor for whether someone does well in a startup has, in my experience, been how willing they are to write lots of _good_ code" I've been at several startups where the developers who made the most difference where those who wrote concise, correct, and elegant code that did the job, and nothing more. They didn't get distracted into writing "architectures" when all that was needed was a "tool." Their code was a pleasure to build upon, and people instantly respected their ability to bang it out. Sometimes less is more.
- tptacek 18y ago
  I actually didn't mean that. I meant: write lots of code. The bad decisions I made? (a) thinking that people who could talk and talk and talk about code (shut up I'm not interviewing with you) would write good code (b) thinking that people who couldn't explain why they'd ever use a red-black tree instead of a hash table would write bad code. I'm making a case for more-is-more. People who write code (really write, sure, not cut-paste) have work ethics, are really into actually writing code, can easily be trained to bring them up to a median "engineery" standard of code, and get stuff done.
  - randallsquared 18y ago
    That's an interesting and intuitive-after-the-fact observation. Thanks.
  - swombat 18y ago
    (a) It's not really the fact that they talk about code, imho, it's what they say about code. Anyone who's clearly a passionate geek and writes weird and wonderful programs in their spare time is likely to be good. (b) I don't know how to answer that question, but I could easily look it up if I was doing some work that required this sort of optimisation. Despite that lack of knowledge, I've built two start-ups now.
    - tptacek 18y ago
      You use a hash table when you just need lookup. You use a tree when you need sorted order. The only tree worth using is a red-black tree. There, now you don't need to look it up. ;)
      - swombat 18y ago
        Cheers :-)
      - wheels 18y ago
        If I asked that question in an interview, and that's the answer you gave, I'd probably not hire you (assuming the position was CS-intensive). There are a number of special-purpose trees which are important in some domains (tries, B-tree, splay tree, ...) Simple hash implementations also tend to assume that it's cheap to compute a hash on the given key type (not always true) and that you have a rough idea on the bound of items in storage. Hashes far below that level are often also less memory efficient since the hash-table is pre-allocated.
bootload 18y ago
I'd agree with pretty much all except the below quote. "... So, even though I think Spolsky's posts have gone further and further off the rails ..." From the article ... "... But for startups, everything about your resume has to scream getting your own hands dirty... the only thing we REALLY need is code to be written, and customers to be called on the telephone ..." reads to me, on-track. One thing I have noticed is JOS has always been skewed towards JOS type businesses (privately owned, bootstrapped software development companies) rather than Startups (fast revenue based technology companies that in the end are either sold or IPO'd). So the stories seem misaligned.
- tptacek 18y ago
  The off-the-rails comment is due to the blog's trend away from things like critiquing the Win32 API and talking about software scheduling, and towards Spolsky's theories of company management. It's the Inc. effect. His writing is also less engaging now than it was 3 years ago; fewer stories about crazy bread machines, more bland prescriptions.

qhoxie 18y ago

This applies to small companies and even big companies (like Google). The skill set to be a good developer is consistent no matter what the size of your company. I agree only partially. It definitely applies to all sizes of companies, but larger companies seem to care less about it during interviews. This is a large part of why startups work more efficiently on average.

nostrademons 18y ago
I dunno about other big companies, but Google seems to care about it a lot.
- qhoxie 18y ago
  Agreed, they are an anomaly there in my mind.