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

#201

Post by pm90 » Tue, Apr 24, 2018, 5:44 PM UTC

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 are either through interpersonal contacts or a fast-tracked interview process for a specific candidate.

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

#202

Post by gaius » Tue, Apr 24, 2018, 5:45 PM UTC

cortesoft wrote: post #149

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…

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?

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

#203

Post by sigstoat » Tue, Apr 24, 2018, 5:45 PM UTC

ryandrake wrote: post #82

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.

It's such a weird hiring market. 1. There are a lot of imposters out there applying for programming jobs who can't program, and 2. There are a lot of very talented programmers out there who are being rejected by overly picky companies. Both can be true, and I'd argue that both are true. I don't know what the solution is. Current interviewing methods don't seem to be solving the problem. I'd suggest a widely-accepted…

> I'd suggest a widely-accepted professional certification could help a lot, like doctors and lawyers have with the medical board exam or the bar exam.

"i passed the bar exam!" and nothing else doesn't get you a legal job you want.

and your medical boards, if i recall correctly, just mean you're qualified to go be a slave, er, uh, resident, some place for a few years.

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

#204

Post by debt » Tue, Apr 24, 2018, 5:45 PM UTC

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 them in with the mediocre engineers for that reason.

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

#205

Post by noahc » Tue, Apr 24, 2018, 5:47 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 […

> Ruby is hard to get a job in, so you are off to a rough start.

Why do you say this?

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

#206

Post by AndyNemmity » Tue, Apr 24, 2018, 5:47 PM UTC

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…

It also entirely depends on your career path. Mine didn't involve programming outside of shell for most of it, and involved tons of deep expertise on a variety of topics.

I was shocked doing an interview in my last round and got so many test questions. I bombed so hard because it wasn't what I was doing.

The real key to me is, we treat all of these jobs as more or less the same, when in reality they are all vastly different. There is no singular senior engineer skill set, but a variety.

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

#207

Post by ummonk » Tue, Apr 24, 2018, 5:48 PM UTC

newssucker wrote: post #27

From the article "The general thing that I saw from everyone that I talked to is that no one actually believes that anyone can code. At every stage in the interview process, you’re going to need to prove that your resume isn’t a lie and that you can actually do what you say you can. I find this ludicrous because it is like interviewing an attorney and then saying to him “Please prove that you can cite a Supreme Court…

>7 years programming in X? YES, 4 years writing scripts in Y?

To be fair, there are a lot of job listings where X hasn't even been around for 7 years.

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

#208

Post by gaius » Tue, Apr 24, 2018, 5:49 PM UTC

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…

It sounds like you've got neither recall nor precision

If you are looking for rare positives, you’d use F1 score ;-)

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

#209

Post by ryandrake » Tue, Apr 24, 2018, 5:50 PM UTC

calcifer wrote: post #123

ryandrake wrote: post #113

Earlier quoted context omitted.

Problem is: It's hard to judge the difference between someone who doesn't know what they are doing and someone who does but loses it under the extreme pressure of an interview wherein their entire future with the company is being determined by their performance on a 30 minute exercise. Throughout my career, I've been in professional situations where I was under a lot of pressure: Having to explain failures to executi…

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 drive home I said to myself, "WTF happened to my brain in there? I know that stuff cold!"

EDIT: I think I read this one from a commenter here, but it's so true: We're interviewing people to be music composers, but judging them by their ability to be performance artists.

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

#210

Post by AndyNemmity » Tue, Apr 24, 2018, 5:51 PM UTC

lostcolony wrote: post #28

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.

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 did DB work forever never hearing ACID. I initially heard of it certainly from slashdot or hackernews, and it only ever ended up coming up due to not DB work, but DB analysis of tools.

Once you start working on a particular database, and are working on all of the specific details of that db, how often does ACID come into things, really? It just doesn't.