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

321–330 of 766 posts

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

#321

Post by ryanianian »

twodave wrote: post #305
ryanianian wrote: post #254

Earlier quoted context omitted.

If the GH code is there, works, and is up to coding standards, why do you care about how the sausage was made? I'd look to see if the code is well-designed, organized, original, tested, etc. It's generally easy to see if the author of code knows how to decompose a problem into pieces. So..saying "we're looking for thought-process not the actual code" feels a bit disingenuous tbh. Now: If you care about being able to…

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. And if you want to see that they can work on a team to define and deliver a messy problem with other people, do that with them on a messy problem you've never solved before. (It could eventually be a DS/algo problem; my point is it's a group effort and neither of you knows the solution; you're looking explicitly for how the interaction goes, not if "the candidate" got the "right" answer.)

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

#322

Post by twodave »

Clubber wrote: post #285
chillydawg wrote: post #76

Earlier quoted context omitted.

It's not a myth. I see it when recruiting for my teams. My sample size is too small to give a proportion, but it's enough that not having tests would be a total waste of my and their time since I'd have to fire them on day 1.

I'm amazed you can't tell an imposter just by talking to them.

The real problem is everyone looks like an imposter until you watch them code.

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

#323

Post by miesman »

I'm over 50 (55) like the author of the article. As it is often said over and over again, the best way to find a job/gig is networking. That's how I found my current job. Having people on the inside pulling for you cuts though the BS. It took about a week for me last time.

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

#324

Post by gmarx »

sanderjd wrote: post #213
lawn wrote: post #170

Earlier quoted context omitted.

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

Maybe but I once had an interview in which I was asked how to find how similar two text strings were (for search). I answered that I would use one of the algorithms from Apache commons text or within Lucerne which implement one or several of the appropriate distance algorithms. He told me he had written his own. I asked why he would do that when these algorithms were written by people who did intense research and the implementations in these libraries have been tested by more eyes than his could ever be. He said “what if I want it to run in Ruby?”...I was interviewing but this is a guy I would not hire. He was wasting time for his own amusement. Never assume people know to do the research on existing solutions. Many developers would rather work on their own toy solutions while avoiding the actual unsolved problems in their domain

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

#325

Post by munchbunny »

komali2 wrote: post #216

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

The only thing I've found to help with this sales funnel is... to know a lot of people, and to invest time in networking. It sucks because in a meritocratic system it shouldn't work this way, but it does.

I'm neck deep in my job search, and I'm getting to the HR interview at rates around 30-40%, but that's because I'm getting to the HR interview at rates near 90% where I was able to get someone to refer me or send my resume straight to the hiring manager. For non-referrals, I'm seeing closer to 100->10-15.

I think that's just insane.

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

#326

Post by bulatb »

komali2 wrote: post #249
bulatb wrote: post #184

A: The talent shortage is just awful. Nobody can code. B: How do you know? A: They can't pass our test. B: How do you know it works? A: Because if they could code, they'd pass. Sometimes they pass, and even some of those can't code. B: So nobody can pass your test. A: That's right. B: And even if they do, it doesn't mean they're good. A: Yep. B: It sounds like you've got neither recall nor precision. Don't you think…

The "can they code test" for us has always been some variation of "fizz buzz." Anybody should be able to do that. It's not a bad test, especially because of how well documented it is. I agree there are terrible tests (why on earth would you have someone implement a search or sort? that's like rolling your own crypto, don't do it, don't bother learning how to do it unless it's your passion), but at the very least a si…

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 a friend who'd had the slot a couple hours after mine; she thought I was joking. It's FizzBuzz!

I'd seen it before. I knew what it was. The guy had changed the strings and added a factor, but who cares. I could write it in my sleep.

Just not in the form of a puddle of goo, which is pretty much the form I took in this interview. My functional IQ was roughly on par with that of my socks.

I could tell you why it happened, but it doesn't really matter. Now that interviewer had a story of the time a guy with FAANG on his resume (whose name alone had gotten me the interview) was totally incompetent.

These comments are full of those stories, mostly being used to show the test is fine and everybody sucks.

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

#327

Post by pixeloution »

diminoten wrote: post #91
time0ut wrote: post #75

Earlier quoted context omitted.

I usually ask a trivial problem like this. Not really to see if they can code (I have had one or two people fail here though), but more to serve as a conversation topic. Why did you do this? How would you do that? etc...

But I don't want to talk about FizzBuzz! It's boring! There's a "right" answer, and not a lot/any real choice or nuance. Ask me about your current problems, problems the person filling the position would need to have opinions about. If nothing else, maybe I could crack a tough issue for you that would have material value. I've given FizzBuzz, and I've done FizzBuzz. It's hard to do it/get it and not feel like there's…

I can't talk to you about my team's current problems, and neither should anyone else. If I do and you offer up a solution I'm in real trouble ... because that's a lawsuit waiting to happen.

Try to remember, this is the country where a range check function resulted in a lawsuit:

    private static void rangeCheck(int arrayLen, int fromIndex, int toIndex {
         if (fromIndex > toIndex)
              throw new IllegalArgumentException("fromIndex(" + fromIndex +
                   ") > toIndex(" + toIndex+")");
         if (fromIndex  arrayLen) 
              throw new ArrayIndexOutOfBoundsException(toIndex);
    }

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

#329

Post by JackFr »

codingdave wrote: post #211
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…

>"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,…

> They care about how you approach it, how you think through it, what you do when challenged, etc.

I was asked to sketch the proof for the irrationality of sqrt(2) in a quant programming interview. I kind of froze, and explained that though I had learned it, I could not recall.

He prompted me with "Well, what does it mean to be irrational?", and with that little hint I did the rest. Though ultimately I did not end up working there, it was very satisfying to have answered it.

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

#330

Post by Balgair »

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…

Hmm, maybe we should 'equalize' the playing field then: Give everyone something from left field that pretty much all people bomb, that'll see how quick they learn.

Exp: You must code in an unfamiliar language (Fortran 1988, for example) and do something simple in it. At least then you'll know that people are all starting from scratch. Time it, make sure it doesn't last more than 2 hours, see how laughably slow we all are, pick those that get the furthest.

Post reply on HN