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

291–300 of 766 posts

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

#291

Post by cacrawford »

AnimalMuppet wrote: post #126

> 1. The job search takes much, much longer than it used to. Senior positions take longer than junior. There may be other factors in any individual case, but just as a general rule, the more experience you have, the longer it takes to get hired. This may relate to... > 9. Age discrimination really exists. In my experience, I haven't seen it. What I have seen is salary discrimination. I'm a pretty expensive guy. I've…

I'm a 50+ year-old senior developer who finished a job search last year. Yes, it took longer, but would've taken days if only I was willing to take a small pay cut. We are expensive for the senior level; and while I think myself and many others my age are absolutely worth it for the wealth of experience we provide, I can understand why some employers back off if you're not a perfect fit.

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

#292

Post by pjdemers »

I'm not sure his lack of job search success is technical. I see several jobs at VP/CTO level on his resume. As a hiring manager, I would pass on him as a senior engineer, unless I was planning on promoting him fast. For guru-level hands-on engineers, I want people who chose to make that their career.

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

#293

Post by Clubber »

laichzeit0 wrote: post #255

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…

I've gotten all my jobs that way since 1999. Based on the current trends of tech hiring, I would never bother with a company that does what's mentioned in this article.

Question 1: What's the interview process look like?

Anything other than 1 hour phone / in person interview would get rejected.

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

#294

Post by always_good »

eanzenberg wrote: post #268
always_good wrote: post #238

Earlier quoted context omitted.

Your refusal exposed you as someone with a hubris that's hard to work with. Who doubles down and refuses to budge. That you couldn't yield on such a trivial, manufactured matter would make me wonder how you respond in a team environment on real matters in the face of adversity.

When I see someone doing something wrong or poorly I speak up and I speak out. Loading csv using vanilla python is in that boat. Present a good reason why it should be done in vanilla. Otherwise, I won't maintain your code as-is and will refactor it.

Sounds like their interview worked and they dodged a bullet.

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

#295

Post by enedil »

monksy wrote: post #245
phaedrus wrote: post #109

Earlier quoted context omitted.

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 o…

That actually sounds like a very reasonable senario to not do so well in. The problem that I have with those problems is, they always assume it's easy to answer after seeing the solution. But if you're working on them for the first time, it's a terrible environment. The minute that they stop asking you, as the canidate, are on a timeline to finish. (Also, to finish as well) The answer to that item would be: (with sca…

So is it actually O(n^2)? Because that is a solution that can be implemented.

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

#296

Post by jcadam »

monksy wrote: post #245
phaedrus wrote: post #109

Earlier quoted context omitted.

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 o…

That actually sounds like a very reasonable senario to not do so well in. The problem that I have with those problems is, they always assume it's easy to answer after seeing the solution. But if you're working on them for the first time, it's a terrible environment. The minute that they stop asking you, as the canidate, are on a timeline to finish. (Also, to finish as well) The answer to that item would be: (with sca…

My personal opinion on what a senior dev interview should be is: open with a fizzbuzz-level 'bozo filter' coding question, then step away from the whiteboard and spend the rest of the interview speaking to each other like normal, functional adults.

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

#297

Post by thegayngler »

stevenwoo wrote: post #97
ryandrake wrote: post #82

Earlier quoted context omitted.

It's such a weird hiring market. 1. There are a lot of imposters out there applying for programming jobs who can't program, and 2. There are a lot of very talented programmers out there who are being rejected by overly picky companies. Both can be true, and I'd argue that both are true. I don't know what the solution is. Current interviewing methods don't seem to be solving the problem. I'd suggest a widely-accepted…

One problem with viewing the certification thing as a solution is people can then question - how do you know if you got the person who graduated at the top of their class versus someone who barely graduated? How are lawyers/doctors vetted beyond their certifications?

Id say recertification is an option as time passes. It keeps people up to date and on their toes.

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

#298

Post by fernandotakai »

iamcasen wrote: post #226
larrik wrote: 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 […

Point number 2 doesn't really land for me. I can see how a dev of 10 years might never have needed to think about tuples, depending on what code she was responsible for. Some folks aren't really curious about deep internals, they care more about the bigger picture. Scalability, system maintainability, ease of deployment, monitoring, ease of iteration, etc. If pressed, they can dig in and understand the internals, but…

> Point number 2 doesn't really land for me. I can see how a dev of 10 years might never have needed to think about tuples, depending on what code she was responsible for.

i'm sorry but i don't agree there. in this specific case, tuples and lists are really different and there's specific reasoning for using one or the other. it's a core feature for the language. it would be like saying someone that is a Java dev and doesn't know the difference between an ArrayList or a LinkedList.

i understand not knowing nuances of the language (in python, understanding how __slots__ work and how to make usage of it), but not knowing a core feature?

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

#299

Post by lostcolony »

wenc wrote: post #153
lostcolony wrote: post #28

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…

This doesn't change the crux of your story--which is that Senior DBAs who aren't familiar with ACID are probably not good hires--but that said, "consistency" is actually a somewhat ill-defined guarantee [1]. And if you throw in distributed databases, there is yet another understanding of "consistency" (vis-a-vis the CAP theorem), which really means "linearizability". Sorry, didn't mean to be super-pedantic but consis…

Yeah, I would have been okay with pretty much anything close, and would have given massive bonus points if they could give me a couple of relevant definitions. I wasn't looking for textbook, just for a reasonable discussion.

And I have similar anecdotes related to candidates who claimed years of distributed systems architecture experience, and were yet unfamiliar with CAP (and when explained, could not tell me even at a high level whether, in the event of a partition, their system was CP or AP, let alone the specifics of how that actually exhibited itself).

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

#300

Post by munchbunny »

cema wrote: post #89
zeroxfe wrote: post #57

Earlier quoted context omitted.

> Is it just our industry where you have to prove you aren't a complete impostor every time? Basically we treat every applicant like they are Frank Abagnale [0]. The problem is that a large majority of candidates lie on their resumes. This means that hiring managers have to work harder to qualify a good candidate -- which often ends up turning into a process that hurts and annoys those that are actually qualified.

Quote: a large majority of candidates lie on their resumes Is it really true? I do not think it has been my experience (some, but not the majority).

I've definitely seen people stretching the truth to various degrees. I do it too, because you're in for unnecessary difficulty getting past the recruiter screen if you don't do _some_ spinning.

The key is to only stretch it to the extent that you can explain your background in detail to the hiring manager and be able to openly admit where you don't know much if those areas come up. Generally speaking a hiring manager you actually want to work for understands that experience is heavily dependent on what your last role needed, and skills can be picked up as long as you have enough of the bare minimum covered.

Post reply on HN