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

501–510 of 766 posts

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

#501

Post by rajacombinator »

JackFr wrote: post #329
codingdave wrote: post #211

Earlier quoted context omitted.

>"Not off the top of my head, no." They were probably looking for the answer of, "Lets talk through it and figure out a better answer". Coders are often under a mistaken impression that interviewers care about your answer. They don't. They care about how you approach it, how you think through it, what you do when challenged, etc. So from their perspective, they asked you to try harder on a problem, and you just said,…

> They care about how you approach it, how you think through it, what you do when challenged, etc. I was asked to sketch the proof for the irrationality of sqrt(2) in a quant programming interview. I kind of froze, and explained that though I had learned it, I could not recall. He prompted me with "Well, what does it mean to be irrational?", and with that little hint I did the rest. Though ultimately I did not end up…

Errr in the set of numbers that complete the rationals wrt to standard metric? I guess you have to show it’s not rational so you probably did a proof of upper/lower converging bounds always having nonzero difference for 1/n increments or something? I would definitely not get this in a pressure interview situation.

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

#502

Post by notacoward »

ropeadopepope wrote: post #485
notacoward wrote: post #80

Maybe the difference in people's experience with candidates who can't code is that some types of programming are full of BSers and others aren't. In nearly 30 years I've never encountered a candidate who flat-out couldn't code. If you see a lot of that in your specialty, maybe you should ask yourself what it is about that specialty that leads to a different experience.

What field do you work in?

I've worked in various kinds of infrastructure - kernels, networking, various kinds of clustering, and for a long time now storage. I've met people who write lousy code, I've met people who struggle to think even one millimeter above the code right in front of them, I've met people who can't debug worth a damn, but I haven't had any candidates who simply couldn't code.

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

#503

Post by pg_bot »

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.

You need to multiply the numbers, (and they must be prime) not add them.

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

#504

Post by cpeterso »

Balgair wrote: post #468
kybernetikos wrote: post #428

Earlier quoted context omitted.

I've worked somewhere where we used this approach for one of the 5 interview sections. Even being upfront about our low expectations and providing very friendly and helpful people to pair and guide, it lead to record numbers flipping the table and stomping off premises before the completion of the interview. I don't use this approach now, as I don't think its a good use of time (and I think an interview should be a p…

Wow, alright, this is exactly what I was thinking. The 'novel coding' test was just one test, that it was forewarned to be laughably hard, and that you all were friendly about it. I really do want to know more about how this all went as I thought this would be a really good way to interview coders, but unfortunately I am totally wrong . I want to know why my thoughts are totally off-base. Really, please, tell us more…

I like to pose technical problems that can scale to the candidate's level of experience. If I sense I'm hitting the candidate's comfort level, I can back off. Otherwise, I can take the problem even deeper with more technical questions. Either way the candidate still has a positive experience.

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

#505

Post by aeorgnoieang »

ufmace wrote: post #443
lifeisstillgood wrote: post #49

Earlier quoted context omitted.

I think the main point from a candidate perspective is that long, unusual or difficult interview processes are fine as long as we have already decided we really want to work for you (that is you are Trello or SpaceX or some amazing startup we love) otherwise, just as you are faced with picking a rose from a faceless mass of candidates so are we faced with picking a decent place to work from a faceless mass of mission…

The trouble with using bugs is that most of the work for fixing them is in isolating just what's going on and where the problem is, and there's no telling how long that will take until you do it. A bug on a new codebase could be anywhere from a few minutes to a few months. In particular, if you don't know the codebase, you're going to be guessing on places to look. If you're lucky and guess right, you may spot it rig…

Maybe it'd work to just timebox the task, i.e. 'work on one bug for an hour', along with 'document everything you find and learn' (and add it to the public issue). I'm a habitual documenter and I could imagine something like those 'papertrails' being a useful way to evaluate someone's thought processes (and written communication skills).

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

#506

Post by braindouche »

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

That's reasonable, but at the same time, unless it's a top-secret clearance job, don't threaten me with doing web development on an air-gapped machine. We both know it's absurd, just don't do it.

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

#507

Post by rajacombinator »

1812Overture wrote: post #460
spamizbad wrote: post #133

Earlier quoted context omitted.

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

I applied for an analytics position that unexpectedly had me take a Python coding test like this (I know a bit of PHP and Java but no Python) and I was able to google everything I needed to pass the test in the time limit. Apparently I got one of the higher scores too. Got the job. It has not required me to write a single line of Python, lol.

Googling stuff to copy is one of the most important skills for programmers. I was appalled when a middle aged senior programmer at my first internship told me this, thinking he was lazy and unethical... (people are paying you after all!)... how naive I was!

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

#508

Post by twic »

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…

> You must code in an unfamiliar language (Fortran 1988, for example)

Oh wow, that would definitely get me sweating. All the FORTRAN i learned was 77!

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

#509

Post by joyeuse6701 »

Coding interviews hide subjectivity behind the veneer of objectivity. They are the worst type of interview.

Maybe I'll make a 'fair coding interview'. The candidate and interviewer get a random coding problem they must solve together. We'll see how the candidate and interviewer feel about each other after the shared trauma.

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

#510

Post by rajacombinator »

For a senior position, if resume + talking for a few minutes can’t verify that the person is potentially qualified, it means you suck at interviewing people. From there it should be a discussion to learn about thought process, architecture experience, and people skills.
Post reply on HN