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

161–170 of 766 posts

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

#161

Post by calcifer »

CryoLogic wrote: post #159
calcifer wrote: post #78

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

Personally, if you gave me this answer I would accept it and then asked you how those functions work and how you would implement them. Still trivial, but it would tell me whether you are familiar with the basics or you just memorized some stdlib functions.

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

#162

Post by achileas »

autokad wrote: post #146
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.

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 don't read anything about OP's post as saying they think people should memorize or that this practice is okay, as evidenced by their final sentence that it's sad that you could do so and pass many technical interviews.

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

#163

Post by mixmastamyk »

larrik wrote: post #30

I've been involved in hiring senior engineers for a while now, and here's a few counterpoints: 1) Ruby is hard to get a job in, so you are off to a rough start. 2) A lot of people with lots of experience actually can't code for crap. Do you know how many python developers I see that don't know the difference between a tuple and list? Like, how could you be a real dev if you never even wondered why sometimes you use […

3) If you don’t ace the coding test under the gun, you won’t proceed, with 100% certainty in my experience.

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

#164

Post by hfdgiutdryg »

spamizbad wrote: post #133
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…

We set our in-house recruiter up with a coderpad question that screens candidates with a simple question: "Write a function that counts the number of vowels in a string" Candidates are allowed to run it multiple times and just have to produce a correct result within 10 minutes. It's not a trick question -- the test case in place makes sure you pay attention to case. Success rate for mid to senior devs? Only 60%.

Is Y (Greek I) a vowel?

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

#165

Post by walshemj »

spamizbad wrote: post #133
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…

We set our in-house recruiter up with a coderpad question that screens candidates with a simple question: "Write a function that counts the number of vowels in a string" Candidates are allowed to run it multiple times and just have to produce a correct result within 10 minutes. It's not a trick question -- the test case in place makes sure you pay attention to case. Success rate for mid to senior devs? Only 60%.

That's surprising - ill have to give that a go later this evening as I have been thinking about going back to development form a consultant non coding role.

Took me less than 10 seconds to come up with an approach that would work oh just though of a more efficient one but that would use a regex :-)

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

#166

Post by lostcolony »

ryandrake wrote: post #125
stevenwoo wrote: post #97

Earlier quoted context omitted.

One problem with viewing the certification thing as a solution is people can then question - how do you know if you got the person who graduated at the top of their class versus someone who barely graduated? How are lawyers/doctors vetted beyond their certifications?

Make the bar for passing high enough such that even a person who scores the lowest passing score has demonstrated that he/she can at least code. A standard exam doesn't solve all problems with hiring, but it could at least help solve the very first "can this person even code at all?" screen that weeds out the total phonies.

Oftentimes this is the "CS degree from a good school" stick. But we don't have an easy way to check those claims, nor to evaluate what constitutes a 'good school'.

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

#167

Post by hermitdev »

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…

Also, expectations of coding tests should be upfront. E.g. we're looking for the most optimal solution, not the one that is most convient.

I was declined for a position at a trading shop for a C# backend role because I used linq to do something. I didn't have unlimited time for the tests, so I went with expedient over performant, for which they did not care. Fuck that, set clear expectations for interview "tests".

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

#168

Post by nebgnahz »

> 1. The job search takes much, much longer than it used to.

This is so true (also in Bay Area). I am still in the process of job hunting. The first onsite was in mid March. I thought my last onsite would be last Friday, but no, a few more are still being scheduled (I probably have to withdraw some applications).

Also the negotiation with HR easily takes weeks. Despite I have offers from some companies, I just couldn't get to the actual compensation numbers. (I call this "HR Tai Chi").

> 3. Coding Tests Can Trip Up Even Good Engineers

I have found that the interaction with the interviewers matters more here. If you can solve all tests, then fine. But often times you may get blanked or just stuck somewhere in your solution, and a good interviewer will be able to guide you through and work out the problems collaboratively. I wish companies would spend time educating and training interviewers. (I have had bad times in my interviews where the "obvious" solution just didn't come up during the interview, however much the interviewer hinted).

> 5. Every company’s “process” is different

Yes, the good part of this difference is that "some are pleasant", and obviously "some are annoying". But you get to experience the company culture and how much they value engineers by their difference.

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

#169

Post by walshemj »

eanzenberg wrote: post #115
calcifer wrote: post #78

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…

Testify !

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

#170

Post by lawn »

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…

Interviewer: "Can you think of any way to do it in smaller big-O?" Me: "I would first google it"

It annoys me that the good answer if you actually encounter the problem during the job is never accepted during an interview.

Post reply on HN