Live data from Hacker News

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

fuzzyblog.io

601–610 of 766 posts

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

#601
post #334

Earlier quoted context omitted.

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

Are you serious? For any algorithmic question, if googling does not turn up a great answer, you would need to be a genius if you could come up with one on the spot.

My job often entails reasoning through a solution to a specific problem which is dissimilar enough from the general formulation of some problem that there isn't an obvious way to Google for an exact answer. It may take a genius to devise the best algorithm to solve some general problem, but it does not take a genius to reason through a decent solution to a specific problem using general knowledge and experience.

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

#602
post #324

Earlier quoted context omitted.

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…

Sure, your mileage may vary and there are definitely bad apples, but my claim is that the vast majority of interviewers aren't looking for people who like reinventing wheels, but are rather trying to suss out the extent to which you can reason through a problem. So I think that's the charitable assumption to make.

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

#603

Earlier quoted context omitted.

> Companies waste lots of engineering talent and company money looking for 10x when 10x is mostly situational in nature. ... In one scene the engineers are not producing. Change the scene and now they are 10x I can relate to this. I have pretty good resume - good schools, advanced degree, impressive sounding projects, a long list of publications. My track-record suggests I am at least a 3x engineer. So when I get int…

6 months? That's terrible. Most engineers can be productive in a month. The 3x engineers take half that.

There's a difference between "feeling unproductive" and actually being unproductive. The person you're responding to said the former, not the latter. And in my experience it's nearly universal that when you ask excellent and very senior engineers "how long did it take you to feel ramped up?" they answer "I still don't!" despite having been there for months/years.

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

#604
post #550

Earlier quoted context omitted.

"For negative performing people, I usually give them something kind of busy-work that doesn't involve the rest of the team." Why waste time? Why not just fire them?

Because you can get sued for firing them. Sued for multiples of their annual salary.

Then that's the heart of the problem, and it should be fixed.

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

#605
post #277

Earlier quoted context omitted.

I understand and truly symphatize with stress the candidate is in, but someone who claims to be a "senior developer with 10 years experience" should be able to write that palindrome function in 30 whole minutes in any kind of stress scenario. Because if I hire that person, they'll be in charge of critical production systems and will face much harder problems in much more stressful situations and if they can't handle…

I don't agree. They should be able to write that as a solution to resolve an issue. It should be very well understood why they're writing it. Additionally, if you want to keep going under that justification: you should also accept quick alternatives that aren't the naive approach. (i.e. bring out groovy, using bash, etc)

Even a "systems" language like Go is just as suitable for a "quick alternative" as a "scripty" language like Apache Groovy or Bash.

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

#606

Earlier quoted context omitted.

Had few jobs in low level system codebases in the millions of locs. I've had 9 months probation periods.

So you weren't productive during that entire time?

So you are telling me you never qualified at a workplace with longer than a month probation period?

Do you see how that putting-words-in-others-mouths looks? It's rude and does not contribute too any kind of productive discussion.

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

#607

Earlier quoted context omitted.

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…

"Give everyone something from left field that pretty much all people bomb, that'll see how quick they learn." The Kobayashi Maru test.

I hadn't thought of it that way, but yes, I think the KM counts

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

#608

Earlier quoted context omitted.

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…

Battle Code Royale

Co-coding with 3 other candidates. I love it. With the 'suicide' option of declaring all variables global.

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

#609

What about the people who can pass the whiteboard/fizzbuzzs tests, but are complete lazy asses who work 2 hours a day once hired? How do you detect these profiles?

As a partial solution, carefully describe the reality of the work they'll be doing. For example, "We're building a bespoke web server using our own in-house programming language based on COBOL. The project has already been cancelled, but for political reasons, we need to produce another million lines of code on it over the next nine months." Etc.

In the face of such frankness, many lazy asses may decide to exclude themselves. ;-)

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

#610

Earlier quoted context omitted.

Wow, alright, this is exactly what I was thinking. The 'novel coding' test was just one test, that it was forewarned to be laughably hard, and that you all were friendly about it. I really do want to know more about how this all went as I thought this would be a really good way to interview coders, but unfortunately I am totally wrong . I want to know why my thoughts are totally off-base. Really, please, tell us more…

> I thought this would be a really good way to interview coders, but unfortunately I am totally wrong. It's not that you're wrong, it absolutely is a really good way of finding out how someone reacts to being asked to learn something new in a stressful situation. And that is a valuable thing to know - I love working with people who get excited about an opportunity to learn something. It's just that you have to be pre…

Maybe this cockamamie way of doing interviews is the correct one then? Each company tries their own thing, and if you get flustered and bomb it, we'll both parties know it not a good fit. Some companies value the ability to learn and be cool under fire, some like GPAs, some like HW tests. The sorting occurs and is not 'fun' but works in it's own way.
Post reply on HN