Things I Learned from a Job Hunt for a Senior Engineering Role • Hacker News Board

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

#251

Post by AndyNemmity » Tue, Apr 24, 2018, 6:06 PM UTC

the_arun wrote: post #61

The common thing I see is there is an implicit bias from interviewer, who always wants to hire someone like himself/herself. I also hear comments from the candidate that - as an interviewee if I interview the interviewer, he might fail too. If the interviewer stays unbiased, we may see better results.

Absolutely true, but it isn't something that can be fixed.

The interviewer interviewing the interviewee is hilariously true. No interviewer could answer questions about my domain expertise. Just like I could never answer questions about theirs.

But they are in control and I am not, so there's no fighting it, just indifferent resignation to the situation, and attempting to sort through it.

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

#252

Post by kd5bjo » Tue, Apr 24, 2018, 6:06 PM UTC

gaius wrote: post #202

cortesoft wrote: post #149

Earlier quoted context omitted.

So what is the interviewer supposed to do to find out if you can code? They want to give you a simple, straightforward task to see how you code. Of course, every simple, straightforward task is going to have an existing tool to do the job, but they aren't looking for a solution to parsing CSV, they are looking to see you code. They can't ask you a complicated problem, because they don't have the time (nor do you) to…

So what is the interviewer supposed to do to find out if you can code? I’ll take someone who gives an idiomatic answer over someone who reinvents the wheel anyday. Who is likely to be more productive on the job?

That depends on whether or not the job entails inventing new kinds of wheel.

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

#253

Post by autokad » Tue, Apr 24, 2018, 6:06 PM UTC

bigtunacan wrote: post #239

autokad wrote: post #146

Earlier quoted context omitted.

its kinda sad you think professionals should memorize useless tricks that dont generalize to the profession in order to be considered for a job. The skill takes a long time to practice, and quickly evaporates once you stop doing it. Yet none of our work is anything like that. a more real world situation is reading documentation or SO for the function concat_ws that will turn an array column to a concatenated string.…

I didn't take the parent's post the same way. The situation is more that if you do leetcode or hackerrank then you pass the interview. So once again the interview process has failed; instead of identifying good candidates you identify candidates that do hackerrank in their free time.

thanks for the clarification, i read it as "its sad they cant do it, whats wrong with them?" kinda way, but what you said is probably what he/she meant

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

#254

Post by ryanianian » Tue, Apr 24, 2018, 6:06 PM UTC

twodave wrote: post #83

vorpalhex wrote: post #71

Earlier quoted context omitted.

I understand that's a problem, but if I have an entire github of highly starred and heavily developed projects with reasonable commit histories... don't make me do your do damned homework or implement a toy BST. I have better things to do with my personal time than toy problems because you can't be bothered to open my github. The worst part is that usually these toy problems are justified with "but you can post this…

I'm not going to speak to the homework type of problem (because honestly I think you should be paid for that sort of thing), but I always ask people programming questions in on-site interviews, not strictly because I want them to prove they can program (although that's one useful side-effect), but because I want to observe the candidate's problem-solving process. I can't deduce anything like that from your Github or…

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 collaborate on a tough problem with somebody, work on a problem neither of you has seen before together :)

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

#255

Post by laichzeit0 » Tue, Apr 24, 2018, 6:08 PM UTC

Don't people get job offers anymore from someone they used to know that moved to another company and then like "hey I know this really great guy who works at XYZ, we should definitely get him here"? That is literally how every job I've moved to happened, except for the very first one right after being a student. That's the only job I ever remember having to "interview" for. The rest were just through established social connections by working in the tech industry. Surely if you have skills and work hard and other people know about this, they would be knocking at your door?

It's just weird to me that people go job hunting by "cold-calling" some random job advertisement where they don't know the company or anyone that works there. If I were hiring people, I'd go for people I personally have worked with, or been recommended by someone that I work with, waaaaay before hiring some random person that showed up at an interview.

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

#256

Post by Bahamut » Tue, Apr 24, 2018, 6:08 PM UTC

glangdale wrote: post #241

Bahamut wrote: post #187

Earlier quoted context omitted.

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.

Ah sorry, I misunderstood the question - the one I've seen usually is if a string could be rearranged as a palindrome ha.

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

#257

Post by rhizome » Tue, Apr 24, 2018, 6:09 PM UTC

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

How often would you estimate either of binary trees or big-O were discussed in one year of that job?

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

#258

Post by glangdale » Tue, Apr 24, 2018, 6:09 PM UTC

falcolas wrote: post #223

I have a theory of why most of these changes in the job hunt came about: people became afraid of firing. I further theorize that this is an indirect consequence of primarily technical folks filling management roles. How does a fear of firing impact hiring procedures? If you are afraid of firing, you're afraid that you won't be able to get rid of a toxic individual; that a single individual will act as a poison to the…

Don't know why you're getting downvoted. Much of the language I get from bigco people about why they are so selective is exactly this; it's almost a confession that once in, they are very bad at managing performance.

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

#259

Post by ryanianian » Tue, Apr 24, 2018, 6:09 PM UTC

minimaxir wrote: post #121

vorpalhex wrote: post #71

Earlier quoted context omitted.

I understand that's a problem, but if I have an entire github of highly starred and heavily developed projects with reasonable commit histories... don't make me do your do damned homework or implement a toy BST. I have better things to do with my personal time than toy problems because you can't be bothered to open my github. The worst part is that usually these toy problems are justified with "but you can post this…

> but if I have an entire github of highly starred and heavily developed projects with reasonable commit histories... don't make me do your do damned homework or implement a toy BST. Unfortunately, the current common argument from the hiring side is that GitHub profiles are not sufficient proof of skill since code can be copied (not fair) and GitHub projects bias toward people with extra free time (reasonable, but no…

Right. Don't "require" a GH, but use it if it's there!

Yes, some of the code may not be original, but unless the repo is a fork you can pretty easily see if the code is organized in a coherent way that shows the committer knew how to decompose a problem well. If they solved /every/ piece of the problem themselves, it may be a sign of a different problem (and also copy/pasting without citing source is also telling!)

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

#260

Post by d1zzy » Tue, Apr 24, 2018, 6:11 PM UTC

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…

As someone that does lots of coding phone interviews I can say that yes, time is a factor. But it's relative, ie I'm comparing you to the time it took other candidates to solve the same problem. After all, we have to evaluate you, over the phone, in the course of less than an hour. If 2 candidates arrive to the optimal solution, the one that did it much faster is the better candidate.

It sounds to me like you did pretty well so don't give up.