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

211–220 of 766 posts

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

#211

Post by codingdave »

phaedrus wrote: post #109
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…

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…

>"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, "No." And they dropped you for it.

FWIW, I had similar questions in some interviews where we hashed through similar problems, and together collaborated down to a "No" answer... but we spent 15 minutes exploring the problem and seeing how well a couple coders can work through it before saying no. And I got the offer despite an otherwise rusty performance.

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

#212

Post by rojobuffalo »

seanmcdirmid wrote: post #197
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…

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 assignments never asses things I'm actually good at.

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

#213

Post by sanderjd »

lawn wrote: post #170
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…

Interviewer: "Can you think of any way to do it in smaller big-O?" Me: "I would first google it" It annoys me that the good answer if you actually encounter the problem during the job is never accepted during an interview.

I'm as critical of how we interview in this industry as anybody, but I've never found this particular criticism compelling or charitable. It's implicit that you know the correct first answer is to seek prior art. Making that explicit is fine but a bit pedantic. The follow-up question is: "ok great, now say that you can't find any satisfying prior art for this on Google, how would you reason through your own solution?".

They aren't looking for people who don't know to start by doing some research, they're looking for people who won't be completely stuck when that research doesn't turn up the answer.

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

#214

Post by ph0rque »

This is almost totally off-topic, but this sentence caught my eye:

> I built it because after I had applied for about 15 jobs, I had no idea where I was in the process and I couldn’t give my wife a decent answer about my progress because I simply had no idea.

The real reason why people do things is often like this! It was a very hard lesson for me to learn, but very enlightening when I learned it.

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

#215

Post by AndyNemmity »

autokad wrote: post #146
vthallam wrote: post #122

Earlier quoted context omitted.

Or you could do top 100 questions on leetcode or hackerrank and you would have solved the question in a minute. It's kinda sad that you could remember the top 100 solutions and clear interviews in almost all big tech companies.

its kinda sad you think professionals should memorize useless tricks that dont generalize to the profession in order to be considered for a job. The skill takes a long time to practice, and quickly evaporates once you stop doing it. Yet none of our work is anything like that. a more real world situation is reading documentation or SO for the function concat_ws that will turn an array column to a concatenated string.…

Exactly, I as well have been doing technical work for my whole life, and sitting here right now, I could more easily explain to you how to optimize the planner cache, and what hints are required to get a given result than I could explain to you which joins do what.

I just look up joins when I need them, and it's straight forward, but ask me in an interview and I sound like an idiot.

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

#216

Post by komali2 »

>Total Jobs Applied For: 82 >Total Jobs Where You Got an HR Interview 25 >Total Jobs Where You Got a Technical Interview: 15 >Total Jobs Where You Got an Onsite Interview: 2 >Total Job Offers: 1

From a recruitment standpoint, this guy's "sales funnel" is remarkably efficient. I'm more used to seeing a ration of 100 applications > 10-15 phone calls > 5 onsites/technicals > 1 offer. Needless to say he blew the initial phone call / interview numbers out of the water, though it did eventually narrow down to about the expected number of offers.

I don't like the current state of recruitment and job hunting. In fact, I have literally never met anybody that did. Recruiters whose living depends on it, our managers, the engineering managers we pitched to, our candidates, fucking nobody is happy with it.

Nobody has solved it though so now that we can all it agree that it sucks, it would be irrational to sit around and complain about how it sucks instead of adapting (and fixing it when you're not trying to figure out how to get health insurance before yours runs out and you gotta spend 400 on COBRA):

It's a number's game. You must send a fuckload of resumes because sometimes a resume for the perfect job will fall off the recruiter's desk or get lost in their email, or get lost in their spam folder, or the recruiter just won't understand what they're looking at, or there's a candidate slated for the position already, or somebody didn't like the formatting of your resume and got frustrated and threw it away. Or 50 other reasons.

That same randomness applies to each of the up to 10 steps (usually 3-5) before you get an offer. They couldn't get you scheduled for an interview in time. You came in and somebody thought your shirt was stupid or too casual. You came in and somebody thought you were dressed too well and a tryhard. They gave you a dumb algorithm that had nothing to do with a job and it created salty feelings on both sides. I mean, there's just so many variables.

So in this system, your best bet is to increase the resolution as high as you can. That gives you realistic access to the greatest number of opportunities you'll actually like, and the luxury (or burden, I suppose) of choice.

Until someone fixes this systems. Lord alive, somebody please fix this fucking system. The best progress I've seen on this front has been by coding test websites that hyper-tailor your profile to companies with specific needs, i.e. completely useless for every other job in the world. Beyond that your best bet is to just align yourself with a god-tier recruiter that actually cares about their relationship with you and their candidates (the established ones that don't have a manager breathing down their neck to randomly spam out resumes cause their numbers aren't high enough).

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

#217

Post by eire1130 »

mightybyte wrote: post #59

The "No One Believes Anyone Can Actually Code" point is right on the money by my anecdotal experience. Just a few weeks ago I was asked to implement FizzBuzz in an interview for the first time in my 15 years of engineering! This was despite having a large amount of verifiable open source Haskell projects.

I'll be honest, if anyone asked me to write a FizzBuzz style test, I would just walk out on the spot.

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

#218

Post by AndyNemmity »

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…

It filters out certain groups of people, but you will also lose out on good hires that don't focus on your given question. ACID has had almost no impact on my career. Only evaluating lies of ACID from certain db vendors is the only time I think I can remember it coming up meaningfully.

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

#219

Post by jehlakj »

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…

They’re also unfair because different candidates have different schedules. One may even be on vacation that day.

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

#220

Post by seanmcdirmid »

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…

Not a take home assignment, just prep material. Like saying, we will ask you about X, Y, and Z, here are some pointers. I would just worry the night before anyways, might as well put my anxiety at ease by prepping and building confidence.
Post reply on HN