Live data from Hacker News

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

fuzzyblog.io

681–690 of 766 posts

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

#681
post #274

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…

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…

def anagram?(a,b) a.reverse == b end

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

#682

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…

How often do you need to write palindrome functions for your job? Checking substring in a string is a 1 liner in languages like python. I was at a final interview with FAANG. One question asked was to load a csv. I used pandas, it's a 1 liner. You could see the wretched face of the interviewer since he was expecting a with open() as f: do_some_shit and kept pushing me to write this on the board. I looked at him and s…

Okay, so the interviewer says: “And what if you can’t use pandas? What then?”

Your response is to flip the table and leave? If so, then good riddance.

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

#683
Senior level dev here (6+ years). My last job search was brutal. I aced my interviews but still got a lot of rejections. The feedback included

* the team thinks you’re a great engineer, but you didn’t show enough excitement about the company

* we think you’re a solid engineer but not quite at the senior level yet, it’s ok though, we reject 98% of our candidates

* we do a lot of code story telling at our team (I kid you not) and you weren’t a great story teller about your code

* the team didn’t get the sense you enjoy pairing and we pair a lot here

I actually think the real reason was poor personality match but companies don’t like being honest about that so they make up nonsensical excuses.

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

#684

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…

Forget syntax bad. Forget algorithms bad. I regularly look things like that up. I am a builder and a problem solver, not a reference manual.

Well said.

I've written code tests where I'm expected to read the code, find the issues and fix them on paper. But when they take it too far beyond the spirit of what I believe to be a reasonable test of understanding and fixing code, then I write that I'd just for example compile the program and look at the output.

The companies that are most into questions like these seem to be the classic (failing agile) body shops with ridiculous turnover of their talent, which causes them to have to interview even more, which causes in turn for their tests to become even more abstract and worthless.

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

#685
While i do hate some hirigin practices, i will obey to get that one cool/great job :|.

I do like programming / what i'm doing anyway and it is not that far fetched to expect someone to write code or know what ACID means exactly. It is more like 'sharpening your skills' and i like doing it.

I do hate homework. At least google and other companies do that together with you and investing equal amount of time for it. When i get a homework, there is often not much effort on the other side.

What i do is always ask for feedback because of that time i spend on the homework.

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

#686

> 1. The job search takes much, much longer than it used to. Senior positions take longer than junior. There may be other factors in any individual case, but just as a general rule, the more experience you have, the longer it takes to get hired. This may relate to... > 9. Age discrimination really exists. In my experience, I haven't seen it. What I have seen is salary discrimination. I'm a pretty expensive guy. I've…

> Senior positions take longer than junior. There may be other factors in any individual case, but just as a general rule, the more experience you have, the longer it takes to get hired. This may relate to... I recently read a thread on Reddit with people making the exact opposite complaint -- that senior developers just didn't understand how hard it is to find a junior position now.

People with very little experience have trouble finding jobs because companies don't want to train people. People with a lot of experience have trouble finding jobs because there aren't a lot of jobs that require that much experience.

Because of title inflation the people with average experience match up best with the title senior.

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

#687
> Number 2: No One Believes Anyone Can Actually Code

It's about the level and structure of your code. They don't think you _can't_ code, they want to know how _well_ you code.

When I'm interviewing people I let them solve a simple problem as well - it doesn't need to work, it doesn't need to be perfect. I just want to know where the interviewee stands. Case in point - I've had a young-un just out of school in for an interview and his code was clean, commented and had structure.

On the other hand I've had an older bloke in with roughly ten years of experience as a programmer. His code was an absolute mess from start to finish with K&R-style initialization etc.pp.

That is why I want to see how they approach and what code they produce - someone may have been writing code since they were born, but if they never went through a review their code will likely be bad.

> Number 3: Coding Tests Can Trip Up Even Good Engineers

That is true, hence a coding test should not be measured on the completion but rather on the approach the interviewee took.

> Number 10: You’ll Never Really Know Why You Weren’t Hired

True and bad. I dislike companies who don't give the applicants feedback - or even worse false feedback. Much like in a review - if all you hear is 'no, wrong, bad, ...' you won't improve. You need explanations to single out the issues you can work on (primarily in the short term).

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

#688
post #453

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…

That would still not level the playing field for several reasons: 1) Some people may find Fortran easier to understand than others even if they haven't touched it before. This was the case when my University decided to use Haskell* as the first language to teach students in order to level the playing field. It did help somewhat, it leveled the field for those with little and those without any prior programming knowle…

I like that 2) - i feel i have to dive at least one "level" below what i actually need else I feel like a fraud.

nice to see it's more common

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

#689

Earlier quoted context omitted.

I’ll be honest, I don’t know a lot about databases, but Atomiticy comes up a fair bit in the web apps I write, as does Consistency in terms of designing data models that can’t go wrong, or trying to encode domain structure into data models to use the Consistency guarantees that Postgres gives us. Isolation is pretty important in general, and easy to reason about from a web app perspective, with requests being isolate…

I've done tons of disaster recovery, and no one ever called it ACID. It's never come up. The only time the type of discussion specific to the terms of ACID comes up is with other database administrators. Just my experience, perhaps I live in another world.

> The only time the type of discussion specific to the terms of ACID comes up is with other database administrators

I think this is partially what I'm referring to. I use these terms in conversation with others when designing systems because they are useful in describing very specific properties of databases.

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

#690
post #496

Earlier quoted context omitted.

>I don’t expect engineers to be better than me. I respect your opinion but I find this strategy very strange. (Or maybe I don't exactly understand what you're saying.) In my view, it would be a dream scenario if the next 10 programmers I hire were all superior to me . If I was the worst programmer on the team, that would be an ideal outcome. Yes, I've been programming for 30+ years but I'm also self-aware of my limit…

I recall one of my friends, when I was at Google, sending me a screenshot of code written by Jeff Dean with an obvious bug. Jeff is, of course, extraordinary, but I wonder how many companies might have passed on him if he submitted that code in an interview setting.

Absolutely. There exists no single human being that does not make any mistakes. The trick is to find the people that make as few as possible, know how to track them down, and that can figure out how to hot-fix them as needed.
Post reply on HN