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

241–250 of 766 posts

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

#241

Post by glangdale »

Bahamut wrote: post #187
CryoLogic wrote: post #159

Earlier quoted context omitted.

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).

To be fair, if you wanted to do a performant implementation, this is probably a more expensive implementation. The expected response is generally for you to iterate over the string and construct a count map of how many times a character appears in a string, and then iterate over the keys of that object and have at most one odd number in the values of the count map. The interviewer probably should have probed you abou…

I'm very confused by this answer. Have I missed a joke? Wouldn't the expected response be to iterate over half the string comparing the characters to the other half (in reverse order)? The criteria you provide seems to suggest aabbc is a palindrome.

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

#242

Post by nugator »

hermitdev wrote: post #176
crdoconnor wrote: post #55

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).

Was it necessary to know on the top of your head without Googling what a binary tree is for the position the candidate applied for? I've been a developer for 12 years and I've never had the use for that. Computer science is a VERY large field and being good at everything is impossible.

Asking the right questions at interviews are crucial for finding the right people. If a candidate for a programming job knows binary trees but doesn't listen to other peoples views I would say he's less worth to us than a listener that easily learns new concepts but is currently not familiar with binary trees.

BTW, leaving a candidate in tears is not professional recruiting. Please let someone with more people skills accompany you to your interviews, you might leave people with scars that takes years to heal.

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

#243

Post by calcifer »

ryandrake wrote: post #209
calcifer wrote: post #123

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…

People are strange. I can totally picture someone who is an experienced senior, a hero under the pressure of a critical production outage, yet whose brain goes into a crash loop when sitting across from someone who has the power to deny them their dream job. Not claiming to be that hero, but I have personally had those moments where I came out of the interview, and as the disorienting fog of pressure lifted during my…

Fair enough. I certainly don't claim to know the best interview method ever; simply that, in my experience, starting with trivial coding questions has a higher benefit/risk ratio then other approaches.

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

#244

Post by rhizome »

yodsanklai wrote: post #177
vthallam wrote: post #122

Earlier quoted context omitted.

Or you could do top 100 questions on leetcode or hackerrank and you would have solved the question in a minute. It's kinda sad that you could remember the top 100 solutions and clear interviews in almost all big tech companies.

I recently interviewed at a big tech company (phone interview). I spent quite some time practicing on leetcode (completed at least 150 problems). During the interview, it took me a few minutes of thinking before completing the assignments with what I think was the expected solution. We discussed the complexity and a few possible variations. The interview sounded satisfied and I really had the feeling that I had naile…

found that I was "out of practice" as far as coding goes.

They want 23 year olds who just did their finals. You know, real stallions.

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

#245

Post by monksy »

phaedrus wrote: post #109
lostcolony wrote: post #28

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…

That actually sounds like a very reasonable senario to not do so well in.

The problem that I have with those problems is, they always assume it's easy to answer after seeing the solution. But if you're working on them for the first time, it's a terrible environment. The minute that they stop asking you, as the canidate, are on a timeline to finish. (Also, to finish as well)

The answer to that item would be: (with scala)

> datasource.window(3,1).filter((a,b,c)=> a+b == c)

I mean if you knock it out of the park and know the internals of window.. then asking the bar raiser question is appropriate as a curiousity.

There are other problems as well: Those are the ones where they have an expected answer, response, and reiterate. I've seen that with tree problems. That's where they would low-key ask for the recursive version and then get you to say stackoverflow exception.

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

#246

Post by [deleted] »

chillydawg wrote: post #76
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…

It's not a myth. I see it when recruiting for my teams. My sample size is too small to give a proportion, but it's enough that not having tests would be a total waste of my and their time since I'd have to fire them on day 1.

[deleted]

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

#247

Post by sharemywin »

pm90 wrote: post #201
jandrewrogers wrote: post #137

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…

> 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 for the work so they leave the average tech guys alone long enough to get the work done.

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

#248

Post by eanzenberg »

Bahamut wrote: post #183
eanzenberg wrote: post #115

Earlier quoted context omitted.

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…

That seems like a fairly arrogant response on your part - it's obvious that an interview is meant to gauge your technical capabilities/knowledge. Even if something is trivialized, the ability to solve certain types of problems can translate to other problem domains where you have to use the same core skills to solve other problems - parsing a file does not seem like an other worldly type of skill (it could even be an…

I respect your view but disagree. I use pandas everyday for my job. I use spark. I use keras. I use scikit. I use all these APIs everyday for my job. I can't think of the last time I loaded a file using vanilla python. If it's a requirement for the job (which it wasn't, they showed me pandas code later) then I completely understand and would not be qualified nor would I want the job.

There's a few things going on here. First, there's a frustration from the interviewer who is obviously looking for the cookie-cutter answer to move things along. Second, there's a culture misalignment because they are looking for cookie cutters to do the job while I am not that. Third, they, along with OP, are obviously not a palindrome company nor a load-everything-to-lists company yet this is what they're testing. So again, culture misalignment.

At the end of the day, you are right, I self-selected myself out because I would not be happy at a place like such who are looking for cookie-cutter employees.

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

#249

Post by komali2 »

bulatb wrote: post #184

A: The talent shortage is just awful. Nobody can code. B: How do you know? A: They can't pass our test. B: How do you know it works? A: Because if they could code, they'd pass. Sometimes they pass, and even some of those can't code. B: So nobody can pass your test. A: That's right. B: And even if they do, it doesn't mean they're good. A: Yep. B: It sounds like you've got neither recall nor precision. Don't you think…

The "can they code test" for us has always been some variation of "fizz buzz."

Anybody should be able to do that. It's not a bad test, especially because of how well documented it is.

I agree there are terrible tests (why on earth would you have someone implement a search or sort? that's like rolling your own crypto, don't do it, don't bother learning how to do it unless it's your passion), but at the very least a simple programming test can indicate that the person can sit down at a fresh debian/windows/OSX install, and knows enough about their given language to be editing, compiling, and running code. This isn't even deploying, just able to have a functional dev environment and be able to create software.

A lot of compsci kids come out of school having worked in specialize VMs or only doing matlab stuff or, well, I don't know what they're getting up to over there but they aren't quite sure what the magic invocations are to get their Java thing running (do I need eclipse? err....) or C (how do I compile...?) or even sometimes Javascript stuff (how come it doesn't work when I double-click the html file?).

A simple fizzbuzz is a great filter for this sort of thing.

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

#250

Post by d1zzy »

vthallam wrote: post #122
phaedrus wrote: post #109

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…

Or you could do top 100 questions on leetcode or hackerrank and you would have solved the question in a minute. It's kinda sad that you could remember the top 100 solutions and clear interviews in almost all big tech companies.

I would say that if you know the answers to 100 top coding questions (and understand them, a good interviewer will poke you to determine that) then you are a pretty good coder and you should be hired. Seems working as intended :)

For many tech companies where they get a lot more candidate applications than they have positions for, the goal of the interview process isn't to avoid losing good candidates, it's to not hire bad candidates.

Post reply on HN