Live data from Hacker News

Things I Learned from a Job Hunt for a Senior Engineering Role

fuzzyblog.io

441–450 of 766 posts

Re: Things I Learned from a Job Hunt for a Senior Engineering Role

#441

I have a theory of why most of these changes in the job hunt came about: people became afraid of firing. I further theorize that this is an indirect consequence of primarily technical folks filling management roles. How does a fear of firing impact hiring procedures? If you are afraid of firing, you're afraid that you won't be able to get rid of a toxic individual; that a single individual will act as a poison to the…

Firing a person on a work visa is a seriously dick move, especially if they are from china or India, where the waiting lines for a green card is 3-10+ years.

Re: Things I Learned from a Job Hunt for a Senior Engineering Role

#442
post #411

Earlier quoted context omitted.

You're way ahead of the game, OP. We talk a big talk in our industry about hackers and meritocracy, but this is still a relationships business -- like every other business. At most companies if you're cold-applying to a position on a job board, you're already behind your competition. I'd like to propose an alternative job hunt: (1) Start thinking about your next move before you need a job. (2) Send an email or DM to…

sounds great except now that person forwarded the resume, and you still have to do the exact rounds that you would have done when cold calling unless you're applying to a small shop

But HR will come to the referrer when that candidate bombs their homework and the referrer, if they can vouch for you, gets a chance to defend your honor. "Oh, that makes sense. Joan was terrible at that kind of thing but she built this amazing thing that did this and that and that…"

Re: Things I Learned from a Job Hunt for a Senior Engineering Role

#443
post #30

I've been involved in hiring senior engineers for a while now, and here's a few counterpoints: 1) Ruby is hard to get a job in, so you are off to a rough start. 2) A lot of people with lots of experience actually can't code for crap. Do you know how many python developers I see that don't know the difference between a tuple and list? Like, how could you be a real dev if you never even wondered why sometimes you use […

I think the main point from a candidate perspective is that long, unusual or difficult interview processes are fine as long as we have already decided we really want to work for you (that is you are Trello or SpaceX or some amazing startup we love) otherwise, just as you are faced with picking a rose from a faceless mass of candidates so are we faced with picking a decent place to work from a faceless mass of mission…

The trouble with using bugs is that most of the work for fixing them is in isolating just what's going on and where the problem is, and there's no telling how long that will take until you do it. A bug on a new codebase could be anywhere from a few minutes to a few months.

In particular, if you don't know the codebase, you're going to be guessing on places to look. If you're lucky and guess right, you may spot it right away. If you guess wrong, you could spend a lot of time diving around irrelevant details. There is some skill in guessing well and not spending too much time on things that don't give any progress, but there's still a lot of luck too. Because of all that, it doesn't seem like a good idea to assign a bug that you haven't already essentially fixed.

Re: Things I Learned from a Job Hunt for a Senior Engineering Role

#444

Earlier quoted context omitted.

I want to know how resourceful the candidate is, how quickly they make mental leaps and whether they'll play nicely with others in the team under the context of the work we're trying to get done. If the choices are a) find out first-hand by (gasp) asking for a demonstration of skill while I watch or b) try to decipher these things by shaking a tuning rod at their GH repository--then I guess we'll have to agree to dis…

Sure - my point is that asking them to solve a problem on their own that you already know the answer to isn't a realistic environment of "playing nicely" either and is only going to show you how they deal under pressure, not how well they collaborate with somebody who genuinely wants to find the answer and can build off of. If you need proof they can "actually code" and use DS/algos etc, use their GH if it exists. An…

So I'm supposed to spend my time researching your GH instead of just letting you spend 5 minutes proving it? There isn't enough time in a day to research every candidate's code they wrote on their own time (and personally I'd rather not be judged by mine). And, if people lie on their resumes already, what makes me trust their GH? It's like saying here's an essay I wrote, you don't need to talk to me in person, I"ll just stay home and you can decide whether you want to hire me.

Re: Things I Learned from a Job Hunt for a Senior Engineering Role

#445

Don't people get job offers anymore from someone they used to know that moved to another company and then like "hey I know this really great guy who works at XYZ, we should definitely get him here"? That is literally how every job I've moved to happened, except for the very first one right after being a student. That's the only job I ever remember having to "interview" for. The rest were just through established soci…

Any time I've heard of people I knew getting referred by old coworkers they still had to go through the complete interview process. Are you getting jobs through word of mouth alone with no technical interview?

I haven't heard of that happening too much, at least in the Bay Area.

Re: Things I Learned from a Job Hunt for a Senior Engineering Role

#446

Earlier quoted context omitted.

Would it be better to have the interviewer provide take home context a few days before the interview that will be related to the coding problems during the interview? Somewhere between the take home coding problem and the whimsical toy problem solving by during the interview?

I really don't like take-home assignments. It's a one-sided time investment. If I'm asked to do one I say that I'm only prepared to put in 45 minutes on it. Now that I've done this a few times and subsequently been rejected after submitting, I'm leaning towards rejecting assignments altogether. It doesn't really serve me well in job searching but I feel strongly about it. It's a bad investment on my time and the assi…

Take-home assignments are a great way to filter out women, the sick, and the poor, but make it look totally above board.

"The IT industry is committed to increasing the number of women engineers. But if they're too busy caring for their children to spend six hours doing our silly test, that's their fault for being women. We are forced to hire 20-something white males who have nothing better to do with their time."

Re: Things I Learned from a Job Hunt for a Senior Engineering Role

#447
post #429

Can't fully agree in quite a few points. I understand how the author got that feeling tho. Doing interviews is always eating away at one's confidence, no matter who you are. 1. no one believes anyone can actually code - I experience quite the opposite. People expect others to be able to code just because they are currently employed as software developer. That's not true at all. Sooo many people can't. 2. Coding inter…

> PS: One side note. A senior coding position might feel age discriminatory because senior is for talented ~28 year olds to mediocre ~40 year olds. A 50 year old should be architect/manager or not switch jobs.

In other words, it might feel like there's age discrimination because of the age discrimination?

Re: Things I Learned from a Job Hunt for a Senior Engineering Role

#448
post #6

Number 2: No One Believes Anyone Can Actually Code It's surprising to see the number of people who interview for lead technical roles that cannot code, or whose work is exceptionally sloppy. Incompetence is more commonplace than the author believes, even at the highest level.

I feel like this is a myth, what do you estimate the figure is? I think under 10%, maybe under 5%. I have significant experience interviewing senior, junior, and mid-range candidates. 99% of my candidates can code, as in iterate over collections, write case statements, and call functions. I've only had one junior candidate who couldn't code at all. Sloppiness is rampant, but sloppy code that gets things done is what…

You must have a very efficient filtering process. I'd say probably about half of all CS graduates and a greater percentage of people in "coder" positions will struggle to code at an extremely basic level.

Re: Things I Learned from a Job Hunt for a Senior Engineering Role

#449

Earlier quoted context omitted.

Don't know why you're getting downvoted. Much of the language I get from bigco people about why they are so selective is exactly this; it's almost a confession that once in, they are very bad at managing performance.

The downvotes are probably because I've implicitly called out individuals who believe in - have perhaps even published materials encouraging - the "missing out on 99 good hires is better than making one bad hire" philosophy. I've also explicitly called out the FAANG hiring practices, which are frequently held up as the best practices in the industry by those doing the hiring. After all, who wants to be even partially…

It's in no way a fear of firing someone that's little easy. The fear is the weeks/months of issues before someone is fired. Further, many people that are part of the process will be working with this person, but not be able to fire them.

Re: Things I Learned from a Job Hunt for a Senior Engineering Role

#450

Earlier quoted context omitted.

Was it necessary to know on the top of your head without Googling what a binary tree is for the position the candidate applied for? I've been a developer for 12 years and I've never had the use for that. Computer science is a VERY large field and being good at everything is impossible. Asking the right questions at interviews are crucial for finding the right people. If a candidate for a programming job knows binary…

I've been a developer for 30 years, and I haven't ever had a need for it, either - but I still know what one is. I expect that you do, too.

I came across it when studying computer science 20 years ago, yes. Heard about it after that but never directly needed the knowledge.

I'm sure it's used under the hood in a lot of code I write and have written but so is XOR, manual memory management and a bunch of other lower level implementations that I don't need to spend time on when developing on a higher abstraction level.

Not sure why you would expect all programmers to know about binary trees specifically.

Post reply on HN