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

361–370 of 766 posts

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

#361

Post by pfarrell »

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…

"That guy didn't have 20 years of experience with db2... He had 2 years of experience, 10 times."

One of my mentors said that about an interview he conducted a while back. I found a lot of truth in that line. I run my tech interviews by starting very green and let the candidate dictate how fast I ramp it up. I've gotten pushback from managers before that you can't start with basic questions, but I've equally gotten positive feedback from candidates (even one's who've been failed the interview). In the end, programmers want to see an algorithm that allows them to judge an interviewee. I don't believe one exists.

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

#362

Post by andrei_says_ »

Balgair wrote: post #330
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…

Hmm, maybe we should 'equalize' the playing field then: Give everyone something from left field that pretty much all people bomb, that'll see how quick they learn. Exp: You must code in an unfamiliar language (Fortran 1988, for example) and do something simple in it. At least then you'll know that people are all starting from scratch. Time it, make sure it doesn't last more than 2 hours, see how laughably slow we all…

I’d probably pick the ones who interrupt the coding exercise, tell me how ridiculous it is, and tell me about the ways they’d solve it in plain English / pseudo code.

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

#363

Post by cortesoft »

eanzenberg wrote: post #234
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…

I think that is the point. If your business relies on importing csvs that cannot be imported with pandas then explain that, explain the edge cases where pandas has failed, and I will understand. If your business relies on having the best fucking palindrome product then that becomes super relevant. They can definitely ask a complicated problem. On-sites are 4 hours long these days.

The question on the interview isn't about the business, it is about showing your ability to design an algorithm. I is an exercise, not a purpose driven task.

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

#364

Post by lawn »

sanderjd wrote: post #213
lawn wrote: post #170

Earlier quoted context omitted.

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.

I'm as critical of how we interview in this industry as anybody, but I've never found this particular criticism compelling or charitable. It's implicit that you know the correct first answer is to seek prior art. Making that explicit is fine but a bit pedantic. The follow-up question is: "ok great, now say that you can't find any satisfying prior art for this on Google, how would you reason through your own solution?…

> ok great, now say that you can't find any satisfying prior art for this on Google, how would you reason through your own solution?

So then I try and give them a O(n^3) solution (or something).

Of course this isn't accepted as there's a better O(n^2) solution, which can always be found by googling, and I fail the interview.

The "turtle and the hare" problem of finding a loop in a single linked list in O(n) time and O(1) memory is the perfect example. It's easy if you know the answer (or can google) but basically impossible if you don't.

What did the interviewer do when I said I couldn't do better than a hashmap? He laughed and said "not many can".

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

#365

Post by thegayngler »

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…

Most engineers would not hire themselves. That has been apparent to me for awhile now. I’m not sure why they expect people to be to be better than they were when they were hired. I don’t expect engineers to be better than me. I have but one qualification. Can they do the job? Are they strong enough that I can guide them into the position I need them at if it is required.

So much focus has been put on 10x this and high performing that. Companies waste lots of engineering talent and company money looking for 10x when 10x is mostly situational in nature. Set the scene. In one scene the engineers are not producing. Change the scene and now they are 10x.

Instead of looking for 10x, that time would be better spent making incoming and current engineers better at their jobs and creating 10x situations.

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

#366

Post by LyndsySimon »

aquateen wrote: post #343
mindhash wrote: post #317

Earlier quoted context omitted.

on a tangent, one way could be assign a number code to each alphabet. Add the numbers that occur in the strings. IF the sum matches, they are anagrams.

I don't see how the sum would be unique to a particular combination of letters.

“ad” = “bc”

You’re right.

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

#367

Post by tedsanders »

Balgair wrote: post #330
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…

Hmm, maybe we should 'equalize' the playing field then: Give everyone something from left field that pretty much all people bomb, that'll see how quick they learn. Exp: You must code in an unfamiliar language (Fortran 1988, for example) and do something simple in it. At least then you'll know that people are all starting from scratch. Time it, make sure it doesn't last more than 2 hours, see how laughably slow we all…

I love this idea. Testing how well someone can learn new skills can be just as important as the skills they've already learned. However, the problem is that as soon as it becomes known that Google is giving tests in Fortran 1988, applicants will study Fotran 1988 and thereby reduce the efficacy of the test. It will also have the sad side effect of incentivizing people to waste time studying Fortran 1988 rather than building skills useful to their job. It seems to be a good interview needs to satisfy the following properties:

* Predictive of job performance

* Either (1) difficult to optimize against or (2) easy to optimize against but in a way that doesn't reduce predictive value

* Low cost to give

* Low cost to take

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

#368

Post by cortesoft »

tkxxx7 wrote: post #341
softawre wrote: post #302

Earlier quoted context omitted.

You sound like somebody who would derail all of the technical discussions and pat himself on the back for it because he was "technically correct" while still missing the point altogether.

I hear the opposite. They are stressing a technical opinion here, but for the sake of rationality and efficiency. These are usually not the same people that are overly concerned with "correctness" when communicating with others.

But it is only 'rational and efficient' if you are being obtuse... they aren't asking you to code a CSV parser because they actually need a CSV parser, they are asking because they want to see you code. The 'rational' thing to do is satisfy THAT requirement, which is the real one, not try to bypass the purpose by insisting on using a CSV library.

The ability to understand the underlying need behind a request is important to being a good employee. If a candidate fails completely to understand the purpose of a question during an interview, and in fact continues to argue against you as you explain it, they aren't a good candidate at all.

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

#369

Post by Clubber »

twodave wrote: post #322
Clubber wrote: post #285

Earlier quoted context omitted.

I'm amazed you can't tell an imposter just by talking to them.

The real problem is everyone looks like an imposter until you watch them code.

I don't mean this the way it sounds, but if you can't tell if someone is an imposter by talking shop with them in your chosen profession, you probably shouldn't be doing the interviewing.

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

#370

Post by jgforbes »

mindhash wrote: post #317
jcadam wrote: post #274

Earlier quoted context omitted.

Had the same thing happen to me. Simple problem: find out if two strings are anagrams of each other. My immediate solution: Sort the two strings and then compare them: (defn anagrams? [x y] (= (sort x) (sort y))) or some such. I was fortunate in that they didn't make me implement the sort (because it's been a long time for me) :) "Ok, what's the efficiency of that solution?" "Well, assuming the library sort functions…

on a tangent, one way could be assign a number code to each alphabet. Add the numbers that occur in the strings. IF the sum matches, they are anagrams.

a=1, b=2, c=3, ...

ac = 1 + 3 = 4 bb = 2 + 2 = 4

Post reply on HN