Live data from Hacker News

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

fuzzyblog.io

271–280 of 766 posts

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

#271

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…

I've had this question and replied with: const isPalindrome(str) { return str === str.split('').reverse().join(''); } And the post interview notes said bad performance on the isPalindrome() question since I didn't write out my own functions (interviewer did not mention to).

Most of the time when they ask for the palindrome questinon they prevent you from using StringBuilder.reverse.

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

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

OTOH, I've had the good fortune of working in a team of top 10% engineers/architects (I'm not top 10%, btw) who worked harmoniously, and it was one of the best times I ever had in my career. Learned a lot, upped my level trying to keep up, helped create a good product, etc.

In that case, the key was that clumps of them had already worked together in earlier jobs, so the incompatibilities had been pruned.

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

#273
Interesting read. So here is what I've learned if you wanna keep on writing code and stay competitive:

* You'll be discriminated the older you get. Make yourself ready:

* Career and big names is important. Companies wanna hire ex-googlers. Have Google on your resume. It's better to work in BigCorp for 10 years rather than being contractor for 10 years.

* Improve your interview skills. For engineer it's theoretical computer science knowledge and cracking code challenges on a whiteboard within limited time.

* Have a big thing on your resume. Source code, GitHub, whatever it is.

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

#274

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…

Had the same thing happen to me. Simple problem: find out if two strings are anagrams of each other.

My immediate solution: Sort the two strings and then compare them:

  (defn anagrams? [x y] (= (sort x) (sort y))) 
or some such. I was fortunate in that they didn't make me implement the sort (because it's been a long time for me) :)

"Ok, what's the efficiency of that solution?"

"Well, assuming the library sort functions I'm using are sane, I'll take a guess and say O(n log n)"

"Can you come up with a more efficient solution."

Off the top of my head, on the spot, I couldn't. Later, during the plane ride home, the obvious occurred to me: Don't sort the strings, just scan through each string once and build a hash table, keeping track of the number of occurrences of each letter in each string. Then compare the occurrences for each string. Not as elegant to express in code, but faster.

As it turns out, they later declined to hire me, giving me an excuse that made it clear they weren't really serious about hiring anyone for the position (as is the case at least half the time, it seems).

And thus ended my latest round of failed interviews. I cancelled the last one I had scheduled (probably another fake) and decided to take a break for a while (I mean, I do have a job right now, so it isn't urgent).

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

#275

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…

It also entirely depends on your career path. Mine didn't involve programming outside of shell for most of it, and involved tons of deep expertise on a variety of topics. I was shocked doing an interview in my last round and got so many test questions. I bombed so hard because it wasn't what I was doing. The real key to me is, we treat all of these jobs as more or less the same, when in reality they are all vastly di…

"There is no singular senior engineer skill set, but a variety." That is extremely well said. Thank you.

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

#276

Earlier quoted context omitted.

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.

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?

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

#277

Earlier quoted context omitted.

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…

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)

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

#278

Earlier quoted context omitted.

It's weird, I've heard plenty of stories about this kind of thing but when I sat on the hiring side and interviewed for intermediate roles (couldn't even afford senior) I didn't come across anybody who was stumped and simply couldn't code. There were people who were bad at (possibly some because they were under pressure), it but nobody who couldn't do it at all. I wasn't giving out a trivial question either.

I remember interviewing a candidate that didnt even know what a binary tree was (context was big-O complexity of algorithms). That interview was really bad. Left the candidate in tears (which was not intended, but I think of their realization they werent going to get the job), and me annoyed at the waste of my time (should have been caught in phone screen instead of on site).

Why on earth did you think that was a good, relevant question to ask? Did you ask about how to implement merge sort? I learned about it in college in the early 90s. Haven't implemented it directly since.

I'll bet, even with this feedback, you'll continue to ask that question, just because.

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

#279
It might be lucky occasion, but in my limited experience, I found that European companies provide pretty good and detailed feedback about interview performance.

In particular, Skyscanner feedback was outstanding (I've been referred through one of Who's hiring thread) for both skype screening and onsite.

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

#280

Interesting read. So here is what I've learned if you wanna keep on writing code and stay competitive: * You'll be discriminated the older you get. Make yourself ready: * Career and big names is important. Companies wanna hire ex-googlers. Have Google on your resume. It's better to work in BigCorp for 10 years rather than being contractor for 10 years. * Improve your interview skills. For engineer it's theoretical co…

Hi,

You will absolutely be discriminated against the older you get. Your observation on being a contractor for too long is likely on point (I was).

Post reply on HN