Hacker News new | ask | show | jobs
by smoyer 4198 days ago
I turned 50 last summer and the last time I was looking, I had no problem finding a good job ... perhaps the best job I've ever had. But to survive the interview process, you can't act 50 (or 55 or 51). You need to be current and make it obvious you've kept yourself up-to-date.

To a lesser degree you can't look 50 either - I'm fortunate to have been dirty blond when I was younger and my hair doesn't seem to be greying yet but if it was and I was interviewing, I'd change it. Five hundred pounds and rolled into the interview in an oversized Aeron chair? You probably look older than you are to the interviewers.

I don't think most age discrimination is conscious but even where it is, don't help them out by acting or looking old/older.

Note: Since I have no idea how @MichaelCrawford looks or interviews, this comment is not aimed at him but is rather responding to a pattern I see when we interview people my age.

2 comments

Many young people simply assume I am not up-to-date because of my age.

In reality I invest a great deal of money in technical books, as well as time in reading them, and writing code for the exercises in the books.

That sounds good, but it sounds hard to show that to a potential employer and impress them. Have you built anything with what you've learned?

I'm 42, and I performed unimpressively in an interview two years ago. That gave me some motivation to go back and polish the projects I'd been working on, so the projects would speak for themselves. Since then a number of professional opportunities have come up, largely based on the quality of the projects I've been building. It has a snowball effect as well; it's become easier to pick the work I want, and get work in that area.

I've built quite a lot with what I've learned, however it's not always possible to demonstrate that. Consider that I am not permitted to tell anyone at all what my most-recent project was, other than that it had something to do with OpenGL.

This because the product was an in-house tool for a client of my client. The very existence of that tool is a closely guarded trade secret.

I read Robert Ward's excellent "Debugging C" back in the day. In part as a result of that book, I am better at debugging just about anything than just about anybody. But what can I show to a potential employer or client? "Here's some code that doesn't have bugs in it." Similarly with Scott Meyers' "Effective C++" series.

Three times I have applied to a certain company to write Mac OS X I/O Kit Kernel Extensions - what Apple calls device drivers. All three times, their HR refused to forward my resume to the hiring manager, unless I removed all the experience that wasn't directly related to Mac OS X.

All three times I refused; I first learned to write device drivers by hand-coding LSI-11 assembly into octal, then entering the code into the LSI-11 kernel with an octal keypad and a profoundly primitive debugger called ODT, for "Octal Debugging Technique".

That was in an Intro to Computer Architecture class at UC Davis that I took over the summer of 1981, while I was still in high school.

Whoever it is who keeps telling me to remove my non-OS X experience, clearly does not understand how computers work. Each time I have refused; I don't want to work for idiots.

As a side note - I wish more interviewers would ask debugging related questions. I had a couple coworkers at Google who would try them ("Here's some code with some bugs in it. Identify them, or talk me through how you would identify them"), but they were definitely in the minority. Debugging is its own skill, very different from writing green-field code, and yet a large portion of the time we spend as professional software developers is spent debugging.
I understand that ten times as much time and money go into maintenance work, than in writing the original product.

Now some of that is adding features but much of it is fixing bugs.

I work very very hard to promote myself as a debugging specialist, but it is quite uncommon for potential employers to even care.

The most common requirement for "Debug" - not "Debugging" just "Debug" - is for really low-level embedded work. Not even kernel nor device driver work, stuff like board bring-up.

However I have gotten a few jobs specifically as a debugger. My very first retail coding job got me the title of "Product Development Manager", but in reality I was hired to debug a product that my predecessor made a smoking crater of. I've also been a "Debug Meister" for Apple, and a "Man in Black" for Sony Ericsson Mobile Communications, where I worked on what is now the Sony Mobile XPeria Play.

Cisco had a written test in which I was asked to debug a C++ program that had thirty lines or so of source.

Note that I did this with paper and a ballpoint pen - no computer.

That same test also had me reverse-engineer a network protocol packet, given a hex dump.

I have only had one other written test that I can recall. With that one I was given the assembly instruction architecture for a hypothetical CPU, then the source to a program, with the problem being for me to write down what the output of the program was. It was a huge PITA, and took me several hours, due to multiply-nested loops, recursion and the like.

I didn't get an offer from Cisco, but I did at that other company. The owner never tells anyone how they did on the written test though, other than that you get a job offer or you don't.

Unfortunately, part of the game is accomodating HR and non-technical managers in most companies that have gone beyond the 30 person startup stage, unless you have widely recognized expertise in some relatively rare skill.

There's three hurdles to being hired (and HN has hashed this over before), so the technical chops are there, it sounds like, but then they ask

- is he/she willing to sacrifice for our success?

- "fit/culture", is s/he somebody we want to travel with/hang out, spend lots of time with, most of it involuntary

I don't have a problem with non-technical HR and managerial people, nor sales, marketing, production staff and so on.

I remain dumbfounded that their HR didn't understand that work I did on other platforms, contributes a great deal to my ability to code for Mac OS X.

Consider that OS X drivers are all written in C++. I've done quite a lot of C++ work on Windows and embedded platforms, and a little on Linux. Yet their HR wanted me to delete all that from my resume.

I didn't just turn down the jobs. Each time I explained to the recruiters - who generally are non-technical too - that all that other experience contributes to my ability to write OS X drivers. Yet the recruiters were unwilling to pass on the message to the HR.

I've only known this to happen at just one company.

Actually I am quite good at explaining difficult concepts to the uninitiated, as a direct result of my experiences with many of my teachers.

I have a BA in Physics, with some graduate school. I had some courses that I regarded as quite easy, some were quite difficult. Quite often this was not the result of the material I studied, but the ability of the instructor to explain it.

Consider that physics is commonly taught by working out mathematical derivations. That leads people who either don't know math, or don't like it, to regard physics as completely unapproachable.

But physics can be taught in a purely conceptual way, with no math at all. For example, I once explained elementary particle physics to a Burgerville cashier by comparing it to the game of pool. "Suppose you cover the break" - the initial positions of the balls, in a triangle - "with a sheet of plywood. Your job now is to shoot the cue ball underneath the wood, then determine the shape of the break from the tracks of the balls after they scatter out from underneath the sheet of wood."

She was quite pleased as she grasped it instantly.

I wasn't clear, that was supposed to be a purely mechanical calculation of amortizing the time costs of preparing for screens and onsites over how much you want the gig, which for me always includes tailoring a resume for each company and other stuff which is basically a waste of time.

You reminded me of the 4th, newest hurdle to getting hired at a lot of places, a decent grounding in linear algebra, prob/statistics, calculus, with the odd category theory curveball question.

I was taught physics the other way, BTW, my Dad decided around 8th grade was the right time to start developing intuitions for ODE's and linear algebra, with illustrations from real life. Made absolutely no sense to me.

young people don't do this ;)
Touche.

"So how could you contribute to our company?"

"I have a goatee and look really good in tight blue jeans. Also I like to ride skateboards, and compose original minimalist piano music."

"You're hired!"

Completely agree. Like you, I have fortunate genes & much younger mindset.
One more anti-pattern to avoid during interviews - don't be the naysayer during your interview!

If they say they're going to be trying "technology/algorithm/framework X", don't immediately say "that will never work!". Sure you've got 30 years of experience and you've tried that and failed with it 15 times but they're young and impressionable and they can do anything. Plus they might be right in this instance!

Instead, you're the flexible guy who balances his experience, intuition and caution with the realization that while X might have failed you in the past, there might be situations where it's the right fit. So play the wise sage and say something like "that's an interesting idea, I'd be careful about Q, R and S but if it's implemented correctly that might be exactly the right plan (for instance, sometimes people really do need a NoSQL database, but often it should be put next to an RDBMS ... don't just choose one!). And you'd certainly like to be on the team working with X right? (you are presumeably at the job interview to get the job).

So the right play during the interview is to look like you'd be a valuable member of the team. Once you've joined the team you can help guide them to a proper solution - whether or not it includes X.

Bonus: Do not in ANY CIRCUMSTANCES get drawn into flame wars during your interview. Editors, IDEs, editors versus IDEs, languages and frameworks are tools - your position is that you use the one that best fits the project and maximizes productivity.

I often get into flame wars during my interview. If the hiring manager says something that indicates he is a jackass, I will quite bluntly inform him of that fact.

For example, Apple's CoreEdit is profoundly nonportable, as well as clearly designed to implement vendor lock-in. There are all manner of ways to store structured data that are quite portable.

So if my interviewer asks me if I have experience with CoreEdit, I will quite emphatically tell them "No, because it's nonportable," then supply some portable solutions such as SQLite.

I don't want to work for a bad manager.

What I have a problem with is someone making assumptions about me, just because they see my grey hair, and the wrinkles in the skin of my face.

> I get lots of interviews, but quite commonly I find that my interviewer starts finding reasons not to hire me

> I often get into flame wars during my interview. If the hiring manager says something that indicates he is a jackass, I will quite bluntly inform him of that fact

Do you see the correlation? If you said this to me in an interview it would be over immediately.

No.

I get lots of interviews with managers who use technologies I'm quite happy with.

When I say I am discriminated against because of my age, it's because I can tell they don't want to hire me, the very instant they look at me.

Do you know the term "code word", with reference to discrimination? With me, I am often told I would not "fit the company culture".

My ex-wife was one a motel manager. She was specifically told not to rent rooms to First Nations people (ie. Native Canadians).

A friend once interviewed to be an apartment manager. She was specifically told not to rent to black people.

However, the owners of that hotel and that apartment, did not specifically come right out and say so. They used "code words", for example the apartment owner told my friend to inform people that spoke in a certain way, that there were no apartments available.

Just from your responses in this thread, I think it's more your personality rather than your age. It probably a lot more of a factor than you believe.
"not fit the company culture" has many meanings. Again, if you started any type of flame war in my interview, you would be gone instantly