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

#221

Post by hermitdev » Tue, Apr 24, 2018, 5:56 PM UTC

mixmastamyk wrote: post #79

pg_bot wrote: post #6

Number 2: No One Believes Anyone Can Actually Code It's surprising to see the number of people who interview for lead technical roles that cannot code, or whose work is exceptionally sloppy. Incompetence is more commonplace than the author believes, even at the highest level.

The idea that no one can code is often a result of poor interview practices, i.e. coding trivia contests under the gun. Then misconstruing poor performance as coding ability.

At a former job, I had a set of simple, if contrived examples, that I asked. Programs were short, less than 20 lines; candidates were instructed that the source would compile unless indicated otherwise, in which case they were given the entire compiler output. I would ask fairly simple questions that would expose a lot about the candidates knowledge. Such as:

if (~false == true) std::cout In C++, what does this print? And if they answered correctly, I'd ask them to explain how/why. This question wasn't a deal breaker, but did immediately given an insight into their depth of knowledge of the language.

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

#222

Post by xyzzyz » Tue, Apr 24, 2018, 5:56 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?

Depends if the job can be done using one-liners from existing libraries.

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

#223

Post by falcolas » Tue, Apr 24, 2018, 5:56 PM UTC

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 morale of your entire workforce. Thus, you want to make damned sure you don't make a bad hire in the first place - even when it means you leave a position open for a really long time.

This fear of firing has gotten so bad that FAANG-alike companies directly espouse how bad the impact of a bad hire is, how they would rather give up on 99 good candidates than hire one bad candidate.

But that's bullshit.

That's letting the fear of interpersonal interactions drive business decisions. The impact a bad hire can have on a work force is pretty minimal when caught and addressed quickly; it can even provide an overall boost to morale to know that the company is willing to address real problems in an adult way. Even a perfect initial hire can turn toxic after a few years: what will you do then, if not fire them?

Do you have 10 positions and 10 potential candidates? Hire all 10 folks, and fire the one bad person; your company will be better off for the decision. Much better off than it would be if you instead overwork your existing team because you haven't found your unicorn hires yet.

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

#224

Post by wheresvic1 » Tue, Apr 24, 2018, 5:56 PM UTC

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…

Err I always thought that the expected performant response is to have two indexes 0 and length-1 and bring them to the middle checking that the values are equal :)

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

#225

Post by busterarm » Tue, Apr 24, 2018, 5:57 PM UTC

efields wrote: post #185

busterarm wrote: post #108

Earlier quoted context omitted.

I'm a "Ruby engineer" but tend to avoid Rails teams because most of those large Rails apps are a giant pile of technical debt. They're looking to hire senior talent to clean up the mess but aren't willing to make the organizational commitments needed to make that effort succeed. No thanks. Edit: My 'favorite' experience was the few months of consulting work I did with a team building Rails apps to deal with medical r…

I'm in the midst of maintaining/fixing one of those and I find it a great opportunity if you A) want to learn outside your comfort zone, B) enjoy figuring out problems that aren't just technical (talking to people, design, organization), C) want to get out of a coding-grind lifestyle. Our organizational structure isn't immutable, it just moves slowly. After about a year, my team's effort resulted in measurable improv…

Sometimes. I'm actually fully on board with what you said, but the situations I found and was describing are usually environments where they just expect someone to put their head down and code.

When I say "not willing to make organizational commitments..." I specifically mean they don't give you access to people -- stakeholders don't want to be bothered by the devs. It's far too common.

What you're describing though is a great situation -- I love those engagements.

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

#226

Post by iamcasen » Tue, Apr 24, 2018, 5:57 PM UTC

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 […

Point number 2 doesn't really land for me. I can see how a dev of 10 years might never have needed to think about tuples, depending on what code she was responsible for. Some folks aren't really curious about deep internals, they care more about the bigger picture. Scalability, system maintainability, ease of deployment, monitoring, ease of iteration, etc. If pressed, they can dig in and understand the internals, but that might not be what they are interested in/ care about.

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

#227

Post by AndrewStephens » Tue, Apr 24, 2018, 5:57 PM UTC

I have been interviewing senior engineers extensively for the last few months while also interviewing at other companies so I have seen the process from both sides. Different companies handle interviews in their own way but I know exactly why interviewers ask the questions they do.

Coding tests are an important part of the interview, you would be surprised how many senior software engineers have been in de facto management or very specialized positions for 7 years and no longer know how to code. We are not asking anyone to implement a red-black tree off the top of their heads, just very simple stuff. I think this is important but anything more than a 20 minute question will not help further gauge a candidate. We tend to not put too much weight on the coding test since some very good people have trouble thinking on their feet under pressure.

We also recently started also asking for a simple homework assignment that tests basic data structures and general C++ knowledge. It should take between 2-4 hours. Personally I hate homework and resisted introducing it but a well designed exercise is great for separating out the wheat from the chaff and allows a really great candidate to show some flair with a clever algorithm or even just nicely formatted code. I would now recommend it.

I was asked to do an assignments during my job search and typically spent 3-4 hours on them. I've heard of companies asking for days worth of work - that is completely unfair.

Finally, you would be surprised at how much outright fraud goes on, particularly with junior candidates lying on their resumes. We have had people on Skype interviews blatantly cheating to the extent that one candidate was just moving their mouth while someone else off-camera was speaking for them. "Mr Ed" did not get the job.

I ranted about the interview process last year[0] but now I am a little more mellow now.

[0] https://sheep.horse/2016/10/so_you_want_me_to_hire_you_as_a_...

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

#228

Post by mixmastamyk » Tue, Apr 24, 2018, 5:57 PM UTC

twodave wrote: post #104

Imagine a world without dishonesty and deception. That is the only place where interviewing for a software development job would be more or less straight-forward. Too many people either flat out lie on their resumes or overstate their achievements and involvement in order to get a higher-paying job. So those who are hiring are left to separate the honest from the dishonest. The only way to do this objectively is by a…

> Companies are entitled to protect themselves.

But they don’t do it effectively, only wasting everyone’s time instead. I.e. Protection has a significant cost as well.

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

#229

Post by amyjess » Tue, Apr 24, 2018, 5:57 PM UTC

debt wrote: post #204

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…

"A: Nope! Everyone just sucks." I do think this attitude genuinely limits many startups. Software engineers will always be the first to take up hobbies like fixing old motorcycles or building a house from scratch, yet they view mediocre engineers as things that can't be fixed up in the same way. A mediocre engineer is actually a really good bargain. Obviously a great engineer who doesn't know it is ideal but I'd toss…

Sounds like a good opportunity for mid-size companies to play Moneyball.

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

#230

Post by exelius » Tue, Apr 24, 2018, 5:57 PM UTC

Yeah, the entire HR process at most companies is so incredibly broken for technical candidates.

One of the problems IMO is that HR doesn’t know shit about tech, and dev managers don’t know shit about HR. A dev manager who needs a person tells HR “I want to interview 10 people for this open job req” — which is likely just some bullets vaguely describing job responsibilities.

HR, having very little idea what any of the bullets on the list mean, do their best to filter resumes. Because they’ve had to do this a lot in the past, they engaged an outside firm to issue coding tests to make sure they don’t pass on shitty candidates to the dev manager (they got dinged last year on their review for that!)

So hence all the bullshit before you even get to the guy who posted the job. Part of the problem is that the dev manager just expects to be able to throw this over the fence to HR.

One way I’ve solved this in my teams? I don’t expect HR to do resume screens. Sure, I have them do a basic screen for candidates who don’t even mention development anywhere on their resume, but I really don’t expect HR to be able to detect bullshit.

The key is to treat hiring a new team member like any other task you have to deal with. But the days when engineers can sit heads-down and code are all but over; because the situation described in the article above is what you get when you try to do that.