Live data from Hacker News

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

fuzzyblog.io

651–660 of 766 posts

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

#651
post #496

Earlier quoted context omitted.

>I don’t expect engineers to be better than me. I respect your opinion but I find this strategy very strange. (Or maybe I don't exactly understand what you're saying.) In my view, it would be a dream scenario if the next 10 programmers I hire were all superior to me . If I was the worst programmer on the team, that would be an ideal outcome. Yes, I've been programming for 30+ years but I'm also self-aware of my limit…

Of course you want the best you can get. I’m arguing 10x is constantly influx for any number of reasons. So it’s unlikely you’ll get one. If you have a process for making engineers into the best then you don’t need to look for the unlikely 10x because you can make them into the 10x high performers you need. Ive seen companies literally turn good engineers into underperforming engineers...stifling them with process, t…

I have observed exactly the same thing. It's truly mindblowing.

I also find it remarkable how quick people are to blame the engineer, rather than considering the whole picture (process, tech debt, politics, etc). It's a complicated equation with a large number of variables.

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

#652
I think this and many of the comments illustrates part of the gap.

If you are in the big tech companies doing infrastructure work (and to some degree, product work), then you need a very firm grasp of the basics because you will have to revisit them. The reason one has to revisit them in these companies is because scale will demand taking different evolutionary passes that are not needed in most other companies.

What this does is create a barrier between jobs that pay crazy and the rest of the market that just need to cobble together a product. I actually experienced this many years ago when I assembled a hacker news meetup in the midwest. I felt rather isolated because most people were assembling some ruby website or some product while I wanted to build next generation infrastructure and write my own database.

Now, the problem here is that ex-big-tech workers will bring the same processes from big companies to smaller scale. Small companies need to pick their battles, and they need to decide to educate and wield weaker engineers; most will not because that is expensive.

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

#653

I try to write up each job interview I do, if it goes badly. Here are two writes up, the first at Adaptly.com and the second at JustWorks.com: Embarrassing code I wrote under stress at a job interview (at Adaptly) http://www.smashcompany.com/technology/embarrassing-code-i-w... The JustWorks job interview http://www.smashcompany.com/technology/the-justworks-job-int... I agree the job finding process has gotten slower…

Embarrassing code I wrote under stress at a job interview (at Adaptly)

I've done about 100 interviews at a large tech company. You did fine. Maybe not the best but far from the worst, and definitely in the upper half.

The guy who is interviewing me has mostly stopped watching, because he’s already decided there is no chance in hell that they will be hiring me. He is looking at his phone.

More likely he was bored because he's done this dozens of times and always ends up twiddling his thumbs while the candidate deals with silly syntax errors. (Incidentally this is a point in favor of whiteboards, so that you both can focus on the actual logic rather than fighting the compiler).

I think they want someone who can write something like this in 5 minutes

If an interview session is 30 minutes, the anticipated outcome is not that you solve the problem in 5 minutes and spend 25 minutes chatting about the weather. I guarantee that many if not most candidates don't get to the point you did of having a working solution.

Even if they say “Please feel free to ask questions” if you phrase the question the wrong way, or ask a question outside the bounds of what they were expecting, it becomes a mark against you.

I obviously can't prove the lack of a subconscious effect, but I've never criticized a candidate for any question that they asked. Confirming something that was in the problem description is neutral, asking about something that wasn't (e.g. "is the input case-sensitive?") is a positive.

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

#654
post #88
post #31

Thank you for writing this post. It was informative. A few comments from a fellow software developer who is approaching 50... I don't think the coding test isn't there because people think you're lying, it's there because we have no industry wide, respected entrance exam. Actuarial interviews don't (to my knowledge) contain a whiteboard vector calculus exam, but this isn't because people just sort of believe actuarie…

> it's there because we have no industry wide, respected entrance exam So you think the person with 30 years experience might be, whats the word... oh right. Lying. You think they are lying. Quit trying to dress it up. Coding tests are exactly you saying you don't believe the experience written on the resume.

Coding tests are exactly you saying you don't believe the experience written on the resume.

In the same sense that verifying previous employment is saying you don't believe the resume.

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

#655
post #454

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 guess the numbers should be primes... 4+1=3+2

10 = 5 + 5 = 7 + 3

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

#656
post #160

Earlier quoted context omitted.

I use a coding test not only to see if someone can write basic code, but also to assess general intelligence and see/hear their problem solving process. A resume definitely doesn't tell you all you need to know and experience does not necessarily mean effectiveness.

I actually do understand why people administer these tests in our field. There's so little to guide you otherwise. The problem is that it's kind of awful, and I personally really do believe that it's driving people away from the field. Here's my take (I've posted this on HN a few times). Many people find in person, at the whiteboard exams quite stressful. This is fairly common, many people describe exams to be among…

This is fairly common, many people describe exams to be among the more stressful events in their lives.

Interviews are always exams, whether it's writing code on a whiteboard or trying to figure out what the interviewer wants to hear about where you see yourself in 5 years.

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

#657

Earlier quoted context omitted.

Had few jobs in low level system codebases in the millions of locs. I've had 9 months probation periods.

So you weren't productive during that entire time?

There’s a reason people refer to it as “ramping up”, as you become familiar with the environment and code base you become more and more productive until more or less plateauing a while later. It’s not really useful to categorise it as binary productive or not productive.

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

#658
The main reason I don't believe people can code from a CV is that in app many cases they can't. Many candidates are being completely desingeneous with their experience claims. Quite often it's obvious when you see a laundry list of languages and technology stacks. I have had candidates come in claiming to have extensive experience with hadoop, spark and Scala and then don't even know what a hash map is let alone their characteristics. I had one candidate struggle to even write a single function in their language of choice and mean even just the basic declaration and then to my face still claim that they are suitable for an in depth technical role. It's very frustrating.

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

#659

Earlier quoted context omitted.

I've been a developer for 30 years, and I haven't ever had a need for it, either - but I still know what one is. I expect that you do, too.

I came across it when studying computer science 20 years ago, yes. Heard about it after that but never directly needed the knowledge. I'm sure it's used under the hood in a lot of code I write and have written but so is XOR, manual memory management and a bunch of other lower level implementations that I don't need to spend time on when developing on a higher abstraction level. Not sure why you would expect all progr…

Binary trees are the simplest kind of nontrivial tree, and trees are used extensively in programming. Most computer problems are solved using trees of one kind or another.

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

#660
post #364

Earlier quoted context omitted.

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…

I’m not familiar with this one but have been thinking about it for a few minutes and think I have an answer (granted I think it will depend on language and OS whether it would work)

The gist of it is: walk the list and after each step, multiply the previous node’s pointer by negative one.

If the current node’s pointer is negative you’ve found a loop (because you colored it by inverting the pointer in a previous step).

Clean up by starting at the beginning and multiplying all pointers by negative one until you reach the last one you inverted. Then return your answer (true).

If you reach a null pointer there is no loop because you’ve gotten to the end of the list. Clean up by going through again and multiplying all the nodes by negative one. Then return your answer (false).

Your worst case running time is 2n (if there is no loop) which reduces to O(n) and you use O(1) memory because you’re coloring the list by using the already existing pointers in the list.

Post reply on HN