Hacker News Reader

"that's what the 20s, for the smartest people, are actually about: watching people in power fuck up so you know what not to do when you're in charge. Eventually, you'll be in a position to do things properly. It might take a while."

I like this. That is exactly how I feel and it's great to read/hear about it outside of my head. :-)

I appreciate your perspective and reassurance, and I agree with nearly everything you said, but wow, that's a pretty damning view of things. You made it sound like I've missed the boat that left in 2006! I do feel a bit antsy that once we have a high-profile collapse of a company like Groupon or Zynga that the rest of the startup ecosystem will be dragged down with it.

After reading your comment, I ought to clarify a few things:

(1) I have in fact been unemployed for several months, mostly because I needed the break and have decided that I should be more careful about where I choose to work next to avoid going through the same nightmare again. Even so, I'm not in a hurry to get a paycheck and am willing to take the time for finding a good match. But I'm aware that many employers look upon this rather negatively and will be rather "curious" about what happened.

(2) The "bureaucracy" aspect I was whining about was not so much dysfunctional relationships as it was pure cluelessness and red tape. Think 6-month wait times for a 15-minute procurement job, or crappy tools that were "standardized" in the company based on some sales pitch delivered at the VP level. I'd imagine it's this type of situation that is more easily avoidable at a startup.

I have a vague hunch of what you mean by "VC darling" and am taking all mentions of high-profile backers with a grain of salt, but I'm curious about what you consider "Real Technology" -- in what ways are the technical challenges, from usability to scalability, of a social media "joke" startup substantially different from those of a business that you'd take seriously?

Cluelessness and red tape are the symptoms of the dysfunctional relationships he's talking about. If the relationships were working properly, it'd be easier to get your 15-minute procurement job done, and nobody would be trying to standardize you on a crappy tool.

Don't worry about missing any boats. If you like a job take it, if not, don't. If you want to start a business, start it, and focus on making money rather than chasing techcrunch headlines and VCs.

If you're evaluating work at a startup, look at it like you're your agent:

1) What's the comp package? Equity, unless very significant, is basically a deferred bonus that you can't count on. Don't overrate it.

2) What skills will you get to develop? It's usually not worth taking a lower salary for X,000 shares of "i don't know". But it can absolutely be worth taking a lower salary now in exchange for higher skills later.

Well put. As someone who does a lot of hiring, I know I'm not talking to a candidate because they're happy with their current job. But at the same time, I want to see that someone has the necessary judgement and discretion to not bad-mouth their current employer, especially when I know that one day, that could be my company.

Also, when a candidate does speak negatively about their current employer, you're left with two possibilities: it's really that bad, or they're not a good employee. As a candidate, you don't really want to raise that possibility in anyone's mind.

  (1) Don't take jobs where the company isn't willing to
  tell you what you'll be working on. That usually means
  you're going to be allocated to the least desirable
  projects.

I passed on a job at Google precisely because of this fear. I wonder if they've since changed that practice.

No, they have not. There are very many good reasons why they do things this way - I can elaborate if anybody cares.

However, you do get to talk to 4-5 hiring managers based on your skillset and their interests, and you get to rate them based on the group you want to join.

I've done that and it's worked out pretty good for me.

Please elaborate. I'm interested to hear if your experience is more than survivor bias.

So Google doesn't let hiring managers interview their direct hires because of incentive mismatch.

(Btw, this is all in the public - Stephen Levy's In The Plex is a pretty good resource)

If you have a fairly impartial interviewer, he's most likely trying to hire competent people - he doesn't have any other sort of incentive except to not hire stupid people.

However, if you're a hiring manager, you're under pressure to produce software and fill open recs. So, if you have an open position, the natural thing to do would be to hire a mediocre person cause hey, he's better than nothing, and we got a hole we need to fill for our next project.

As for my personal experience, I'm a bit of an outlier. I'm older (mid thirties), know a couple dozen people who already work here (know which groups to avoid), and my friend who I've worked for before personally recommended me to his current team (I know I'm landing in a good position).

Any other specific questions?

Can you tell us which groups are considered less desirable?

It's hard to tell on a group-by-group basis.

If you work at Google, keep your head down for 12-18 months. Don't pay attention to big-company politics and (unlike me) stay the fuck away from eng-misc. Work hard and (unless you're on a good project) figure out what transfer opportunities will be available, and which ones will be good. At the 18-month point, try for a promotion. It makes it easier to transfer. If you don't get the promo, you can still transfer; it's just somewhat harder. If your performance ratings are still at "Meets Expectations" you should have a good story as to why. In that case, you need to find that middle ground of (a) making it obvious that your manager's appraisal of you is boneheadedly wrong, (b) without throwing him under the bus.

The objective sign of a decent manager is whether his or her reports get promoted. Good managers (at Google) get their reports promoted and bad managers don't. It's that simple. Look into this when you're evaluating transfer opportunities. If you find that a group has a lot of really good people stuck at SWE 3, stay away from it, even if the work sounds interesting. The truth about Google is that no one will consider you qualified to do anything actually interesting (i.e. you won't be considered a Real Googler) until you climb that ladder a bit, so your first few years should be focused on making Staff SWE. (The Real Googler line is somewhere between Senior and Staff.)

Piaw Na wrote some excellent material on the promotion process at Google: http://piaw.blogspot.com/2010/08/tips-for-noogler-engineers....

Nope. :-) I need this job.

Do you have any less specific questions that I could answer without getting canned?

I've worked for large companies that do it both ways. When I knew what group I was going to, it often ended up changing within the first year of my arrival anyway through restructuring, re-prioritization, etc. So I've decided it's generally irrelevant - nice to have, but not actually that important. It's more important to be ok with the larger company culture.

I did that the first two times Google contacted me. The third time, I took the plunge - and I must say, they were great at finding a fit for both my skills and my interests. YMMV, but I don't feel like I've been shuffled of to an undesirable project. I get to work on some pretty cool stuff.

In my (admittedly limited) experience, management at Google listens very carefully if you say to them "I don't think I'll be happy doing that" or "I'm not happy doing what I'm doing." The thing is that you have to be the one to say that. If you let them move you around like an interchangeable cog they will. If you help management find you a job/project you'll enjoy, you'll probably find one.

Another thing to watch out for: (6) during an interview, if questions about work environment (e.g., “how do you manage unit tests?” which of course is code for “do you have unit tests?”) are answered with “that depends on the project/product/client”.

This is pretty silly thing to watch out for. Being a zealot about anything, especially something like unit tests, is certainly not a good idea when searching for a good job. Setting aside the fact that whether unit tests exist and how they are managed often does depend on the project/product/client (and the fact that many good web start-ups don't do unit testing for very good reasons), it's just a bad idea to discount a company based on some technical aspects you may disagree with (especially if you only have a few years of experience and really don't have a strong foundation for evaluating this).

Instead, you are looking for good co-workers, good management, a comfortable work environment, and a compelling or at least interesting-enough business. You are not looking for a company that merely subscribes to your pet programming philosophy.

Unit tests was just an example. The issue is deeper than that.

When I ask a question in a job interview, it’s because I want to learn something about the company, because I want to know whether its corporate culture and its philosophy of how to run a software shop are in sync with how I want to work. If significant questions get the “it depends” answer, I take it as a sign that either the place is so chaotic that it doesn’t have a corporate culture, or that I won’t know what culture I will work in until I find out who my manager is.

But that's the case at any organization of non-trivial (> about 10 people) size. You can't enforce uniformity - if you do, you end up with a sicker system than if you'd just let everyone do the wrong thing.

One of the key signals I use to judge someone's intelligence is their willingness to say "It depends." Because that demonstrates their comfort with ambiguity, their ability to see distinctions in circumstances, and their confidence in being able to make sense of unfamiliar surroundings. All of these are absolutely essential in doing high-level creative work, where there's no roadmap of best practices because nobody's done it before.

It's great that you ask the question, but if you're looking for a specific answer, you're doing it wrong. You should then be able to drill down into "Depends on what?", and then if you can have a sensible conversation based on that, you've probably found someone worth working with.

In the cases I’m thinking of, “depends on what?” was met with more vagueness, or, in one case, “depends on what the client wants”. (This was at one of those companies whose business model involves a very small core product and a lot of per-customer consulting work to enhance it. Which is a perfectly respectable way to run a company, but the core-to-consulting ratio was too low for my taste.)

"If significant questions get the “it depends” answer, I take it as a sign that either the place is so chaotic that it doesn’t have a corporate culture, or that I won’t know what culture I will work in until I find out who my manager is."

Or, you know, it means "it depends". Because sometimes, it depends on the circumstance. As they say, the exceptions make the rule.

The larger point here is that if you go into an interview prepared to dump on a company because they're not absolutists about your particular favorite development philosophy, you shouldn't be surprised if you don't get the job. And nearly every company is going to have something that they're letting slack in order to keep the lights on.

So maybe not having unit testing is a deal-breaker for you. If so, fine. Don't work for companies that don't unit test. But I hope your list of deal-breakers is short.

So where is the line (for you) between not following a pet programming philosophy and incompetence?

If they don't use a bug tracker? If they don't use version control? If they edit the code on the live servers to make changes/add features?

(I've seen all these things)

I agree it depends a little on the specific project but a lot of these kinds of best practice stuff are more than just pet programming philosophies. If you are used to or function best in a place with a certain level of professionalism than working somewhere with some cowboys who just wing it or somewhere were the every piece of work is in a feature branch with a corresponding user story, conforms to a style guide and has proper tests is probably not a good fit.

Where a team falls on this spectrum is part of the company culture.

When I started at my current job 9 months ago (with me, there are now two programmers in the team), there was no bug tracker or formal version control. We still regularly edit the code on live servers for some bug fixes. The first two were (barely) workable for a one person team and got fixed once the team grew, and the third is honestly the right approach for the kind of software we write. The user base for most of our products numbers in the dozens, and I'd rather get a prod bug fix out there as soon as possible rather than having to mess with commit;cd $prod_dir;pull -u or having to deal with the complexity of having too many code environments. I have not yet succeeded at getting a proper testing framework in place - too much hassle dealing with selenium and we don't yet have enough tests written to justify spending more effort. It's the initial capital investment that'll make it worth it, but I just haven't gotten around to it. Rather work on building an actual product that'll add direct value rather than just saving my ass.

These are all practices that in a larger team, or with a larger user base, or with higher requirements, would be untenable. But they work for us, for now.

I've certainly been in that same situation and made the same choices (version control/bug tracker a must, tests would be great but no one finds the time and once it's been left a while then it never gets done). It was a defensible choice at the time.

I learned my lesson though, retroactively adding proper deployment practices is pretty easy, adding tests later is freaking impossible. It's harder to do later when the code isn't fresh in your head (or you didn't even write it) and it takes a lot of time to write tests for legacy code and getting approval to take that much time away is near impossible. Now I pay the 5% tax to do things right and develop features 2-3 times faster long term. (Those numbers are based on pulling some numbers from my work logs and time sheets a while ago, they are very rough and small sample size on a project where there was legacy code with no tests and new code with tests).

To go back to my point though, it's not some rabid devotion to some pet philosophy that would make me think seriously about starting a new job somewhere where they don't test. It's because I've done both and I like my job so much more when I don't have to deal with the bullshit that comes from years or even just months of developer laziness (often my laziness). I can spend more time concentrating on creative problem solving and actual features and less on debugging fragile code.

At this point, I'm not convinced that not testing necessarily leads to laziness.

In my job I deal with a fair amount of legacy code, and definitely find anecdotally that I work several times faster on new code, but that's because the legacy code is crap and the new code is clean and brilliant (just like all code written by yours truly). (Of course, the fact that the code is new and is being edited by the original author are the primary drivers, but I think my code quality is slightly better than my predecessors'.) Once the code is well-written, I don't think that adding tests would significantly improve my productivity. Having a test suite would give me confidence and save me time doing manual testing (no need to test features I haven't touched and am not worried about), but don't see it having a major impact on my development productivity per se.

I meant that laziness leads to not testing. And the "bullshit' that arises from not testing are the bugs and regressions that happen after you role out anything new that isn't completely self contained.

"Once the code is well-written, I don't think that adding tests would significantly improve my productivity"

Yeah, if you never touch that code again then it would not, I agree. I don't have many modules or classes that never change though. I suppose there might be other types of programming where that's not the case.

These kinds of conflicts cause more problems than you might suspect. I respect the fact that different people and organizations code differently. But that respect has to go both ways. Otherwise, you find yourself in a situation where you adapt to others' style of doing things, and they are doing nothing to adapt to yours.

So personally? I say find employers who subscribe to your pet programming philosophy, but don't be willing to rule out someone who doesn't.

Of course there are "startups" and there are "startups." Which is to say that 3 founders and 2 employees is a 'startup' but so is 50 employees and 2 founders. That is why I dislike generalizing about "startups" and prefer to talk about values.

But I agree whole-heartedly that some jobs are just painful. Sometimes they start out great, and the company changes, and then they are painful. Sometimes its the other way around, and sometimes they are all great or all painful.

So lets step past the 'burnout' part, the damaged goods part if you will, and talk about who you are. Try to come up with times where you felt really great about your job, could be a task completed, feedback received, or even just the amount of light in the office. Let those memories inform you about what you really value (as opposed to things you think you should value). Now armed with knowledge about what you value, think about ways to interview companies which would help you know if those things are likely to be there.

I joke sometimes that people often spend a lot of time interrogating a potential boyfriend/girlfriend but don't invest the same energy in interrogating a potential company. While it is true that as a job seeker you are in the 'inferior' position to the job offerer, but both of you want exactly the same thing, a happy, productive employee. That occurs when you love your job and knowing what it takes for you to love your job and being up front with that with your potential employer will pay big dividends.

well said!

Regarding "On job interviews, don't discuss the negative experiences or the bad employer. At all. Bad job experiences are too common to deserve the "silent shame" stigma, but nonetheless, a job interview is just not the place for that. Keep the conversation positive and focused on the future." . I see this very often when I interview people and when it happens I usually stop the interview not too long afterwards.

When I'm interviewing, I avoid discussing negative experiences precisely because this bias against it exists, but I find the bias to be somewhat irrational and wish I could be more honest.

I'm not saying I want to dwell on the negative, but if someone in an interview asks me "Why did you leave Company X?", honestly answering that I left because "Company X is badly managed" would be a lot easier on me than making up some bullshit reason, which is what I'm forced to do because everyone is so afraid to speak or hear anything negative.

On job interviews, don't discuss the negative experiences or the bad employer. At all.

I've been asked point-blank for critiques of past employers before. What is the best response?

"I am sorry, but I am not at liberty to share internal details of my previous workplace.". If they look upset, follow it up with "NDA, you understand...".

If they still look upset, might as well leave right now. They have no sense of ethics, and they sure won't keep promises they made you.

This is pretty comparable to being asked to be critical of yourself (e.g. "What's your biggest weakness"). Generally speaking this is a bit of a trap and your main goal should be to not take the bait and move on to another topic ASAP. If they really press the issue focus on issues where there's nobody to blame and there's not that much that's going to be held against anybody (e.g. Old Co become very big which was fun but now I'm looking to be part of a smaller team). The key thing is to keep things positive and move on to why you want to work for them instead of why you don't want to work for your old employer.

I don't know about the question being a trap. If you don't try to be too sly about it, you might even turn it into a plus for you. If it were me interviewing, my biggest concern would be that the OP is burned out, and thinks that working at a startup will be nothing but sunshine and lollipops.

Instead try being a bit more concrete: "I didn't like BigCo because of <specific, observable and especially non-judgemental facts go here>. Some people like that, but that's just not what I enjoy. I'm curious to hear if you feel I'll run into the same problem working for you."

If a candidate said that, I'd be more convinced that:

1. The candidate is willing to leave the BigCo world behind.

2. The candidate has realistic expectations of what a startup will be like.

For the record, I think I wrote enough in the original post to show that I'm highly skeptical of startups that claim to have awesome work environments. That said, the community response has definitely been helpful for me to figure out some realistic expectations.

Let me reframe what you just said. Yes, your post does show that. But do you plan on showing that post to any potential employers? It's just as important for you to demonstrate that to potential employers as it was for you to demonstrate it to us. You have to skirt a very fine line between demonstrating that you want to work for them and demonstrating that this want is reasonable and not based in fantasy.

> But do you plan on showing that post to any potential employers?

I probably won't say it in the way I wrote the post, since I think it will be open to misinterpretation that might close some doors unnecessarily. But I will definitely bring up my expectations as a matter of concern.

Indeed, a fine line to walk.

Say something positive about them and move on.

”The position just wasn’t a good fit for me any more.”

Imagine yourself on a date with someone you barely know, and listening to that other person go on a long rant about his or her ex. Does that make you more or less likely to want a second date?

Great post that I agree with, except I don't know what a "VC Darling" is. Do you have any examples? How do I know if a startup is a "VC Darling"?

Thanks for taking the time to write this. I needed to hear a lot of these things too.

So how do you reply when the interviewer asks you why you left the previous job?

@Michaelochurch great response! Where do you work?

@HN I've been a hiring manage for years. Take the advice about what to avoid with a grain of salt, and be sure to read some of the other excellent comments in this thread.