Live data from Hacker News

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

fuzzyblog.io

101–110 of 766 posts

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

#101
post #12

> Number 1: It Takes Longer than Ever to Get Hired Last twice I've looked for a developer job, I got offered a position and was hired within 2 weeks. > No one believes that anyone can actually code. Quite rightly, most devs can't code. > Extensive homework is now normal. Not been my experience, I've done some homework assignments but none were ever more than 1 hours work (and then even the standard of the tests were…

> Last twice I've looked for a developer job, I got offered a position and was hired within 2 weeks.

Region matters too. I don't doubt in Silicon Valley it's trivial to pull this off, but in Chicago I've seen most companies have a 2 month+ hiring process, if they ever hire anyone at all. I've even heard from recruiters that this is common for those companies. And then there's a lot, lot less companies out here to choose from, especially if your tech stack experience doesn't match. I've literally had company HR chastise me for not learning their specific language, even though I don't list it on my LinkedIn and the message was unsolicited.

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

#102

Earlier quoted context omitted.

Seriously. I've sat on the hiring side. I've seen impressive resumes. I've had reasonable discussions with people. And then I give them a very, very trivial coding exercise (a take home, they're free to Google, do it on their own computer, in their own IDE, in their professed preferred language), in a time frame that while constrained is still plenty...and the result is -terrible-. I can try and come up with reasons…

It's weird, I've heard plenty of stories about this kind of thing but when I sat on the hiring side and interviewed for intermediate roles (couldn't even afford senior) I didn't come across anybody who was stumped and simply couldn't code. There were people who were bad at (possibly some because they were under pressure), it but nobody who couldn't do it at all. I wasn't giving out a trivial question either.

[deleted]

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

#103
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 […

> and communication is not optional.

It's weird how prevalent the idea that communication _is_ optional in this industry. Headphones-on, heads-down engineering teams are to be avoided (by me).

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

#104
Imagine a world without dishonesty and deception. That is the only place where interviewing for a software development job would be more or less straight-forward. Too many people either flat out lie on their resumes or overstate their achievements and involvement in order to get a higher-paying job. So those who are hiring are left to separate the honest from the dishonest. The only way to do this objectively is by adding complexity to the interview and testing for the claims made by the applicant.

If you think it's hard finding a job, try hiring 10 programmers in a short time, and let me know how it goes for you. Try bringing on a candidate who spins his wheels for months (while you pay him) and who you then have to fire. It's expensive. Companies are entitled to protect themselves.

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

#105

Earlier quoted context omitted.

A few years ago I was approached about a new opportunity, and through the course of the interviews I was given a generic fizzbuzz-like coding challenge and I completely bombed it. I got flustered, I got stuck on something trivial, and I ended up running out of time with not much to show for it. It was in a language that I had been using for 5+ years at that point, using a framework that I had just finished architecti…

I think this is most people who “can’t code”. Just nerves I’ve been in that situation myself.

I'm really glad that you and the parent posted these comments. As someone with pretty bad anxiety, this kind of thing prevents me from even going for interviews. And, unfortunately, after browsing this thread it seems that this possibility isn't even on most peoples' minds.

FizzBuzz-style filters not only don't prove that someone can code, they don't disprove it either. I'm not sure what the answer is.

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

#106
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.

That is because over last few years it became extremely prevalent industry to make everything about "teams": projects are responsibility of teams, failures are attributed to teams, etc. It used to be that code won arguments. Now it is not ruffling feathers that wins arguments. If I'm not hiring the entire team, how do I know who in that team actually can code based on the result?

What does it all mean? It means exactly what it meant in a high school/college group assignments - one or two people carried the group project but everyone took credit.

I have seen hundreds of resumes where people claimed that they have done XYZ where through some side channels I know they just happened to be on that team but their contribution was limited to tweaking spelling.

I see coding tests as one of the two ways to evaluate that someone can code[1]. I trust it.

[1] The other way is that I know this person and I'm already aware what they can do.

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

#107

So the author is complaining about coding tests and being doubted for knowing how to code... yet converted 15 technicals into only 2 onsites.

Could just be age discrimination. I've worked with more than a few people who are very suspicious of people over 40 who are "still just coders," saying that it shows the candidate lacks ambition or they must not be that good since they never advanced to a more senior role like very-senior-principle engineer or management.

> since they never advanced to a more senior role like very-senior-principle engineer or management

Not everyone makes principal, and you shouldn't go into management if you aren't suited for it.

Oh but if you don't do either of those things by 40 then you suck and don't deserve to get hired.

Speaking of sucking, I should probably figure out what I'm gonna do once I'm unemployable. hm.

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

#108
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 […

> 1) Ruby is hard to get a job in, so you are off to a rough start. Huh? Enterprise level companies are desperate for Ruby engineers to maintain large Rails apps and there still is a good amount of startups doing new work with it.

I'm a "Ruby engineer" but tend to avoid Rails teams because most of those large Rails apps are a giant pile of technical debt. They're looking to hire senior talent to clean up the mess but aren't willing to make the organizational commitments needed to make that effort succeed.

No thanks.

Edit: My 'favorite' experience was the few months of consulting work I did with a team building Rails apps to deal with medical records and the app that I came into had tons of dead code paths that leaked HIPAA-regulated data all over the place.

None of the API routes were 100% functional, so I spent my first few weeks cleaning that up and making it bulletproof. Then I fixed their broken homebrewed SAML IdP. None of that work that I did was appreciated as they only wanted (but wouldn't say that they wanted) new frontend features to show off to the client to inflate the quality of their work.

More importantly, they were using Rails4, but implemented everything by watching a Rails2-era Railscast and would get frustrated with me for not doing the same, a.k.a "the rails way" (I was, just modern Rails and not their broken bullshit). And that was the CTO...

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

#109
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.

Seriously. I've sat on the hiring side. I've seen impressive resumes. I've had reasonable discussions with people. And then I give them a very, very trivial coding exercise (a take home, they're free to Google, do it on their own computer, in their own IDE, in their professed preferred language), in a time frame that while constrained is still plenty...and the result is -terrible-. I can try and come up with reasons…

I once got knocked out of the running by a whiteboard-coding interview question that went something like "How would you find all triples from a list of a million integers, where the first two numbers add up to the third?" I said, "Hmmm that sounds like an O(N^3) problem." Interviewer: "Can you think of any way to do it in smaller big-O?" Me: "Not off the top of my head, no."

For some reason that company insisted on only doing interviews at 7:00 AM, and my brain doesn't come fully online until after 9:00 anyway. I felt annoyed later when the answer came to me that afternoon, too late: put the list in a hashtable, add all pairs of numbers for O(N^2) complexity, and check if each answer occurs in the hashtable.

Much later after that, I realized that all the other red flags I'd picked up on while interviewing there added up to an impression that their corporate culture was seriously f'ed up, and that I probably dodged a bullet by getting passed over quickly in the process.

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

#110
post #2

> When did an entire industry of people get pre-judged as lying? That's the kind of thing that happens when people lie. Everybody who's ever hired engineers knows from experience that a simple Fizzbuzz test is still, unfortunately, a very usable candidate filter. A lot of candidates with years of real work experience simply cannot write code. How else can we find this out?

A few years ago I was approached about a new opportunity, and through the course of the interviews I was given a generic fizzbuzz-like coding challenge and I completely bombed it. I got flustered, I got stuck on something trivial, and I ended up running out of time with not much to show for it. It was in a language that I had been using for 5+ years at that point, using a framework that I had just finished architecti…

I had the same experience. It was humiliating.
Post reply on HN