Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

On the flip side, as an old friend once said, "Do you have ten years of experience, or one year of experience ten times?"

Highly experienced people can be priceless because they have dealt with similar situations before (and it's not the technology, it's the situations). But if they didn't learn from their experiences, it doesn't help. And imho a majority of the old hands are still doing things wrong - sometimes due to management interference, sometimes due to ignorance, but mostly due to simply not making the effort to do better.

One of my own interviewing mantras is, "I don't care so much what you know how to do, as how you deal with what you don't know how to do." But honestly, this mantra taken to its logical extreme massively favors raw intelligence and flexibility over experience. That's not always a Good Thing.



I am right in the middle of this right now. In my 40s, looking for a job at the moment. My interviews have been decent to downright bizarre. The trend of the interview approach is very curious to me.

I've been looking at a variety of lead engineer/architect positions to development manager. Many of these positions come with some immediate needs, i.e. addressing large systems as part of a business expansion.

I find myself being interviewed by individual engineers asking heavy comp-sci questions, mostly in the academic sense. In several cases, during the interview, the individuals were focused on specific answers to questions that could hold several interpretations. Ambiguity is a great way to assess individuals and critical thinking, but when someone is looking for the answer...well, it doesn't necessarily pan out.

The kicker, after these meetings, is interviewing with the C-level folks who explain how their technical team can't get product out the door, and wonder how I'm going to help to that end. I've been shipping products for multiple years, in many cases longer than the individuals on the teams I'm interviewing with have been in the industry.

What's funny to me is that I'm a guy that prides myself on being current in technology. I'm not that old dude who is resistant to the latest thing -- I really enjoy seeing where the industry is going.

I'd love to get to depth on my experience -- why we built something the way we did, decisions we made, difficulties and how we addressed those -- it's like those questions are irrelevant. At the last interview, I was asked how much I enjoy playing "Dominion". I like Dominion, but really.


I understand how you feel. I went on some intensely technical interviews a few years back (late 30s). Many of the questions were the sort of thing you'd expect on an undergraduate data structures and algorithms class, though there were a few brain teasers thrown in there for good measure.

My interviewers were young, and at lunch, I tried to talk to them a bit about the business problems they were trying to solve. Their knowledge about this seemed very thin. I pressed a bit, and finally was told that this is what the "product managers" are for.

In short, I realized that they were asking me about these CS-related questions, at least in part, because this is the bubble of their work life.

One interviewer seemed unengaged in the discussion, waiting for a pause. Then he asked "how would you swap two integers without creating a third integer?" At lunch, in between two 3-4 hour blocks of technical interviews.

I'm done with these interviews. Well, ok, if my family was looking at foreclosure and going without health insurance, I'd subject myself to them again. But it is a priority of mine not do do another one of these interviews again.

It's not that I won't do a technical interview per se - there's a wide range of what counts as a technical interview, and not all of them are equally unpleasant. But I will view it as a personal...letdown if I find myself at the whiteboard showing how to add a branch to a binary tree ever again in my life. Or, to put it another way, I don't want to reload data structures and algorithms into "exam ready" memory in my own head again. I know where to find these things when I need them.

The reason I say letdown is that I most definitely do see my own personal role in this. If I fail to establish enough of a personal reputation for competence that people are asking me to do this, then that is, at least in part, my "fault". However, it does come with the territory - as far as creative fields go, software development is an area where the programmer's contributions are fairly obscured (unless they are working on open source projects).


Exceptionally well put; and good that you're aware of the shortcomings of looking too closely at dealing with the unknown. I love the succinctness of, "It's not the technology, it's the situations."

Obviously, crappy people with 10 years of experience are useless in any situation--it's just easier for them to blend in at Big Company X where they are one of a hundred. The rest of the article already applies well to how to weed those people out. Sadly, they're not always super-easy to spot.


When doing tech interviews, I always prefer to interview experienced people. I find that digging into a project that they did before was all I need to figure out if the candidate is worth going forwards with. My big red flag is when the candidates have "leading project X generating Y revenue or Z customer engagement" in their resumes, but are not able to articulate the system/product architecture, or tell me what the biggest technical challenge encountered.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: