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

331–340 of 766 posts

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

#331

Post by ljw1001 »

sharemywin wrote: post #247
pm90 wrote: post #201

Earlier quoted context omitted.

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

I can just imagine a room full of top 10% engineers/architects...No we need to do it like this...Well, no did you think of this obscure use case... what about performance? I think...should we...fast forward a year later and the company went belly up because everyone was trying to be best and piss on each other to prove who was top...top. At least when middle managers do it they're only interested in who gets credit f…

I've worked at a company that generally hired extremely good engineers - much better than average and they were very successful because (1) doing that was actually important to the very hard problems they were solving, and (2) every other company in the world wasn't trying to take the same approach to hiring. Today, everyone thinks they should hire like google, even though they're building a mid-sized web or phone app.

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

#332

Post by munchbunny »

zimou13 wrote: post #309
munchbunny wrote: post #300

Earlier quoted context omitted.

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…

Having a plan to write a postmortem once a job is landed might actually be useful, since it forces seekers to track their data, analyze the results of what they did, and carefully consider what they could have done better. see: https://luckypatcher.pro/ https://kodi.software/ https://showbox.software/

I'm a bit confused... how do your links relate to your comment?

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

#333

Post by ryanianian »

dragonwriter wrote: post #261
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…

> If the GH code is there, works, and is up to coding standards, why do you care about how the sausage was made? Perhaps because, like many developers on modern teams which eschew the older role distinction, the incumbent in the position being hired for will need to act in the role of a classic system analyst in defining specific requirements give a fuzzy business problem as well as the role of a grunt coder. Also, t…

> position being hired for will need to act in the role of a classic system analyst

Sure but that's a different skill from solving DS/algos, so don't conflate the two. Some people know their DS/algos super well but need to solve them solo, some people need to google around a bit for inspiration or take a walk if they get stuck.

Instead, separate it out. Give a specific "system analyst"-style question that's distinct from coding. A question you don't already know the answer to or that could be taken in a thousand different directions that you've definitely never thought of before.

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

#334

Post by raarts »

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

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.

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

#336

Post by logfromblammo »

spamizbad wrote: post #133
haskellandchill wrote: post #68

Earlier quoted context omitted.

I feel like this is a myth, what do you estimate the figure is? I think under 10%, maybe under 5%. I have significant experience interviewing senior, junior, and mid-range candidates. 99% of my candidates can code, as in iterate over collections, write case statements, and call functions. I've only had one junior candidate who couldn't code at all. Sloppiness is rampant, but sloppy code that gets things done is what…

We set our in-house recruiter up with a coderpad question that screens candidates with a simple question: "Write a function that counts the number of vowels in a string" Candidates are allowed to run it multiple times and just have to produce a correct result within 10 minutes. It's not a trick question -- the test case in place makes sure you pay attention to case. Success rate for mid to senior devs? Only 60%.

In C#, the string object has some convenience in it:

  return inputString.Count( "eaoiuAIEOU".Contains );
Or if you want to solve two problems:

  static Regex VowelMatcher = new Regex( "[aeiou]",
    RegexOptions.Compiled | RegexOptions.IgnoreCase );
  ...
  return VowelMatcher.Matches( inputString ).Count;
And if you want to be clever and snarky:

  return 2; // number of vowels in "a string"

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

#337

Post by ljw1001 »

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…

exactly. If the job and the pay were exceptional, sure. But today it's standard practice for average companies.

One company I interviewed with gave me a program that had to be written in Scala, with the full knowledge that I would have to learn Scala to do it. Please.

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

#338

Post by ihsw2 »

r00fus wrote: post #276
jehlakj wrote: post #219

Earlier quoted context omitted.

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

I'd expect that interviewee to request reschedule then. Isn't that the job of the recruiter to manage the interview process and ensure that requirements like this are being met?

Only if they care enough. Given the volume of applicants, they're incentivized to sift out applicants that don't adhere to the process.

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

#339

Post by twodave »

ryandrake wrote: post #113
calcifer wrote: post #78

Earlier quoted context omitted.

> 99% of my candidates can code, as in iterate over collections, write case statements, and call functions. Honestly, that's way too trivial to call "can code". I usually ask something less trivial, yet still extremely easy like "a function to check if a string is a palindrome" (I explain what a palindrome is) or "check if a substring exists in a given string". You wouldn't believe how many people "with 10 years expe…

Problem is: It's hard to judge the difference between someone who doesn't know what they are doing and someone who does but loses it under the extreme pressure of an interview wherein their entire future with the company is being determined by their performance on a 30 minute exercise. Throughout my career, I've been in professional situations where I was under a lot of pressure: Having to explain failures to executi…

It's way more expensive to hire a bad fit than to pass on a good fit. Also, I think I'd prefer the person who doesn't crack under pressure. Flopping an interview is more likely an indicator of lack of preparation than nerves, although nerves are such an easy scapegoat.

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

#340

Post by lifeisstillgood »

larrik wrote: post #99
lifeisstillgood wrote: post #49

Earlier quoted context omitted.

I think the main point from a candidate perspective is that long, unusual or difficult interview processes are fine as long as we have already decided we really want to work for you (that is you are Trello or SpaceX or some amazing startup we love) otherwise, just as you are faced with picking a rose from a faceless mass of candidates so are we faced with picking a decent place to work from a faceless mass of mission…

We actually only do 2 interviews total, and for some roles a Hackerrank quiz. The only times we use coding tests, we use Hackerrank to administer them. That way you have a distinct time limit (we give an hour, which is honestly way too long) so you don't spend all weekend one something that doesn't matter. I definitely agree about the difficulty of picking a place to work. We reserve half of our final interview (and…

I think that Hackerrank etc are optimising for the wrong question. 98% of the time as a hiring manager I am not looking for a AAA coder - I am looking for an A level coder who fits the team and has other soft skills that matter.

At a certain point "can code" stops being "can write perfromant algorithms" and starts being "can work without direction, can be placed in front of users without fear, can defend their decisions, is not an asshat."

Ten minutes on a shared screen and we can find out if you pass fizzbuzz, can make a rational stab at an algorithm question. After that it's mostly cultural fit.

You cannot automate a test for "is not an asshat" so we get more and more people proving they can get 99% on programming tests when programming tests are 5% of the job.

Post reply on HN