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…
Things I Learned from a Job Hunt for a Senior Engineering Role
681–690 of 766 posts
Re: Things I Learned from a Job Hunt for a Senior Engineering Role
#682Earlier 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…
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* 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
#684Earlier 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.
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
#685I 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.
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
#687It'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
#688Earlier 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…
nice to see it's more common
Re: Things I Learned from a Job Hunt for a Senior Engineering Role
#689Earlier 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.
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
#690Earlier 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.