Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

fuzzyblog.io

Post reply on HN
Print view View original

471–480 of 766 posts

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

#471

Post by warrenm »

s73v3r_ wrote: post #189
arca_vorago wrote: post #25

Earlier quoted context omitted.

I agree but I don't think it's fair to put it all on the incompetence of devs/engineers... in many cases it's mismanagement and the real problem is devs/engineers don't know how to talk to management to get to them see why $badpractice is bad. So because the devs don't have MBA's, and the MBA's don't talk well to technicals there is a huge culture gap in the average fortune 1000 workplace. I've seen the inside of com…

"in many cases it's mismanagement and the real problem is devs/engineers don't know how to talk to management to get to them see why $badpractice is bad." I would say that's still management incompetence. They're paying all this money for experts in the field, and they still want to disregard their opinions.

>They're paying all this money for experts in the field, and they still want to disregard their opinions.

Nope - they've gotten burned by being talked down to like the cliche mechanic telling a girl her SUV's hammenframas needs to be replaced, and it's $1600.

If you as a software developer cannot speak coherent English sentences (with a small handful of management jargon) to management without devolving into technical shorthand, you are a failure.

Not management.

You.

You have to explain what is going on in a manner your audience can understand.

You should not expect managers to be technical (they might be (and good for you if they are)) - they're accomplishing a different task from you and need solid, understandable, actionable data to take to their management and customers.

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

#472

Post by seanmcdirmid »

reaperducer wrote: post #446
rojobuffalo wrote: post #212

Earlier quoted context omitted.

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."

There are us guys who are involved in toddler care also (like me, since my wife is working instead). Anecdotally, my wife failed in all her in person interviews until she got one with a substantial take home assignment. She got an offer for that job easily, above what she was looking for.

For her at least, this worked out better for her. She does design, which is even more difficult to evaluate in 30 minute time slots.

Not that I’m arguing this is the way to go, I was just wondering if interviewers could give some hints on what they would cover I the interview, so we could prep like studying for a test.

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

#473

Post by konschubert »

pm90 wrote: post #201
jandrewrogers wrote: post #137

To take a more nuanced view, I think there is an important distinction, frequently lost, between "can't code" -- which is all too common in practice -- and "can't easily code a stream-of-consciousness solution to a synthetic problem unrelated to anything I've ever built". Or its close cousin "can't easily code a toy solution to your toy problem since I've only worked on massively scalable versions of the same problem…

> For all the claims of companies that they only hire the "top 10%" or whatever of engineers, the interview process is often optimized to the benefit of the median engineer. This really seems out of necessity. There are going to be a lot more qualified median engineers rather than superstar coders, so it makes sense to optimize your hiring pipeline to assess these folks. In my experience, most of the "top 10%" hires…

Maybe companies only hire the "top 10" of their applicants and assume that this means they only hire the top 10 of engineers.

In reality, the applicant pool is heavily biased towards very bad engineers.

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

#474

Post by mywittyname »

falcolas wrote: post #223

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…

> Do you have 10 positions and 10 potential candidates? Hire all 10 folks, and fire the one bad person; your company will be better off for the decision. Much better off than it would be if you instead overwork your existing team because you haven't found your unicorn hires yet.

Even if you hire two do-nothings and a negative-performing person (consumes half an FTE's day in questions), you still end up with 6.5 productive people. And frankly, a 65% productive workforce is pretty damn good. I've seen lots of companies where Plus, some of the do-nothing people can be alright with some direction. Sometimes people don't get anything done because they just don't know what to do. I've been on so many teams where the manager said, "we need a person to do X" and they end up with some random person that doesn't really know how to do X. The solution that I've found is to find something they can do and have them work on that. Most projects have no shortage of work that's more time-consuming than difficult.

For negative performing people, I usually give them something kind of busy-work that doesn't involve the rest of the team. They might not be getting anything done, but they also (mostly) aren't weighing down the team by asking them questions all the time.

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

#475

Post by bulatb »

komali2 wrote: post #386
bulatb wrote: post #326

Earlier quoted context omitted.

Story time! I've failed a FizzBuzz. While failing interviews is basically my superpower, I think my git repositories, college graders, previous and subsequent employers, coworkers and clients might be somewhat shocked to learn that all that code was written by a guy who "couldn't code" at all. (The autograders and CI accepting all that non-code must have been exceptionally buggy.) But still, I failed the test. I told…

Putting yourself in the shoes of the company interviewing you: If you collapsed into a puddle of goo under pressure, to the point where you were incapable of performing a task "you could do in your sleep," why are you still a good choice to hire?

The point of my story is not that I should have been hired. That isn't my call.

The claim is often made that anybody who can code should easily pass some particular test: P -> Q. I'm offering a story of P & ~Q, which means FizzBuzz isn't really doing what it's claimed to. There's a ton of subtlety I've sidestepped and a lot more I could say, but I don't really have the time.

(I didn't downvote you.)

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

#476

Post by irundebian »

solatic wrote: post #353
geebee wrote: post #31

Thank you for writing this post. It was informative. A few comments from a fellow software developer who is approaching 50... I don't think the coding test isn't there because people think you're lying, it's there because we have no industry wide, respected entrance exam. Actuarial interviews don't (to my knowledge) contain a whiteboard vector calculus exam, but this isn't because people just sort of believe actuarie…

> ... because we have no industry wide, respected entrance exam. This. In fact there needs to be one exam, with subsections and subscores per subsection, along with an overall score. Being able to solve an algorithmic challenge on a whiteboard does not mean that you can: a) write readable and maintainable code b) effectively communicate requirements to whoever is actually running your code in production c) know about…

That's an interesting conclusion and it makes pretty sense to me. I've heard that most projects fail due to organizational failures rather than development performance failures. It's probably better to invest in process/quality-aware developers than in rockstar programmers. But I've never read studies about that.

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

#477

Post by falcolas »

hoorayimhelping wrote: post #458
falcolas wrote: post #223

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…

I agree that it's related to firing, but I don't think it's fear of interpersonal drama. The simple explanation is that it's really expensive to fire someone without cause. It takes months because the company has to produce a paper trail proving they fired the person for a valid reason to protect themselves from litigation. That's months of paying an individual who may be incompetent or toxic, months of paying people…

As much as I hate it as an employee, "at will" employment means that cost simply does not exist for 48 of the 50 US states (including all states where FAANG have employees).

The cost is also not that high in non-at-will states, since there's typically a 3-6 month "evaluation" period where no paper trail is required.

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

#478

Post by blktiger »

dieterrams wrote: post #431
codingdave wrote: post #211

Earlier quoted context omitted.

>"Not off the top of my head, no." They were probably looking for the answer of, "Lets talk through it and figure out a better answer". Coders are often under a mistaken impression that interviewers care about your answer. They don't. They care about how you approach it, how you think through it, what you do when challenged, etc. So from their perspective, they asked you to try harder on a problem, and you just said,…

> Coders are often under a mistaken impression that interviewers care about your answer. They don't. They care about how you approach it, how you think through it, what you do when challenged, etc. This isn't always true. Some interviews are really about solving the problems as fast as possible. And lots of interviewers are looking for exactly the answer they have on hand, and will think you're doing it wrong if you…

In which case, I don't think that's a place I'd like to work. Most often the solution an engineer comes up with is _not_ ideal and will be improved either because they come up with a better one later before they commit it or because they go through code review and someone else sees a better way. If you don't leave room for people to improve their solutions you'll just end up with the first, crappy one that comes to mind.

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

#480

Post by lliamander »

rojobuffalo wrote: post #212
seanmcdirmid wrote: post #197

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…

> ...the assignments never asses things I'm actually good at.

I actually really like homework assignment approach when done correctly, both as an interviewer and as an interviewee (though seanmcdirmid's suggestion of prep material, rather than a homework assignment, is quite sound), but this is a separate issue, independent of how skills are assessed.

It's really about the company/team having a preconceived notion of what skills they are looking for vs. looking to see if a candidate has a distinctive skillset that could help round-out the team. How do you, as the candidate, market yourself and the things you are good at?

Obviously, the resume is a good place to do such marketing (and I'm sure you already are) so if teams are turning down applications based on the homework without looking at the other skills the candidate has to offer, then that might be an issue.

Post reply on HN