Live data from Hacker News

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

fuzzyblog.io

351–360 of 766 posts

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

#351
post #329

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…

A friend of mine didn't understand how he could have done better than me in a "write a quick sort" interview (we were still students) when I knew the algo and he never heard of it (and obviously struggled more).

Well, in one case (me), all the information the interviewer had was "this guy happens to know how to implement a quick sort by heart. K.".

In the other case (my friend), he got "this guy is able to understand and implement an algo he never saw before in a reasonable time", which is much more impressive

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

#352

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.

I remember interviewing a candidate that didnt even know what a binary tree was (context was big-O complexity of algorithms). That interview was really bad. Left the candidate in tears (which was not intended, but I think of their realization they werent going to get the job), and me annoyed at the waste of my time (should have been caught in phone screen instead of on site).

Most programmers never need to interact with binary trees directly, and I would hazard a guess that if I asked ~10 of my compatriots about big-O notation, maybe 2 of them would understand what I was talking about.

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

#353
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…

> ... because we have no industry wide, respected entrance exam.

This. In fact there needs to be one exam, with subsections and subscores per subsection, along with an overall score.

Being able to solve an algorithmic challenge on a whiteboard does not mean that you can:

a) write readable and maintainable code

b) effectively communicate requirements to whoever is actually running your code in production

c) know about application-level security vulnerabilities like SQL injections and know not to mindlessly insert them into your code

d) instrument your code for metrics and logging in ways that are more or less standard and expected for production monitoring

e) engage in effective review of others' code

f) use typical API handling techniques which are production-ready, e.g. exponential backoff and circuit breakers.

All of which are testable in a certifiable way.

Simple truth of the matter is, the vast majority of companies that hire 10 developers who studied efficient algorithms for their interviews, are better served by hiring 9 engineers who are aware of how production and organizational realities affect their work, plus one "performance hacker" who may or may not have a master's degree in CS, whose job is to find the worst real-world production bottlenecks and replace the implementations with algorithmically more efficient implementations (plus stricter performance tests so that the more efficient code doesn't get ripped out later).

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

#354

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…

Don't know why you're getting downvoted. Much of the language I get from bigco people about why they are so selective is exactly this; it's almost a confession that once in, they are very bad at managing performance.

The downvotes are probably because I've implicitly called out individuals who believe in - have perhaps even published materials encouraging - the "missing out on 99 good hires is better than making one bad hire" philosophy.

I've also explicitly called out the FAANG hiring practices, which are frequently held up as the best practices in the industry by those doing the hiring. After all, who wants to be even partially responsible for hiring "that guy" when you can not or will not fire them later?

But, here's my point: I've been part of the process that hired "that guy". I was also consulted on the decision to fire "that guy" a month later. I was wholly on board with the action in both cases; and in the process we got two other great employees that we never would have hired if we were afraid of taking chances.

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

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

> 1) Ruby is hard to get a job in, so you are off to a rough start. Huh? Enterprise level companies are desperate for Ruby engineers to maintain large Rails apps and there still is a good amount of startups doing new work with it.

I think part of the problem is that the author seems to ONLY be a ruby dev, rather than a polyglot, able to use the right tool for the job.

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

#356

Been coding professionally since '99 - C/C++/C# until 2012, then Rails/React/Angular over the past 6 years. I guesstimate I've been on some 50 interviews. If anything I feel that things have gotten better, although this may be a difference between my former enterprise Windows-stack life vs. open source tech life. The main differences I see are: - Take homes are more prevalent... but I recall only one which has taken…

I'm curious about the transition from C/C++/C# to Rails/React/Angular. What did make you switch?

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

#357
post #201

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…

Also depends on what they're counting in their percentiles.

You can pretty easily hire the top 1% of applicants, and still get only mediocre results. E.g. at one job, when looking for a senior-level eng position, clearly stated in the description, we easily weeded out a couple hundred applicants who had effectively zero experience whatsoever. No prior programming-related jobs, internships, side projects, open source, nothing.

Which is a waste of time for everyone involved. Hence the heavy reliance on connections :(

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

#358
post #154

Earlier quoted context omitted.

I feel like this is a myth, what do you estimate the figure is? I think under 10%, maybe under 5%. I have significant experience interviewing senior, junior, and mid-range candidates. 99% of my candidates can code, as in iterate over collections, write case statements, and call functions. I've only had one junior candidate who couldn't code at all. Sloppiness is rampant, but sloppy code that gets things done is what…

I feel like sometimes it's out of the applicants hands if they come by way of a recruiter / head hunter. Sometimes non-junior devs who aren't quite to senior developer status yet have no control over the recruiters mistaking your pay at previous jobs and the pay you could make next time for the level of job you should be applying for / able to handle. I've run into this issue in different specific ways earlier in my…

I'm a senior engineer and have worked with recruiters many times before, and I've pretty much come to the conclusion that they're a big waste of time unless you want to do the 6-month contracting thing to avoid resume gaps or you just like moving around the country and renting rooms.

I've tried working with them before, have gone on job interviews through them, and then generally found that the jobs that hire through recruiters pay peanuts, and I end up finding a permanent job paying much more and taking that instead. I think if a company only works through 3rd-party recruiters, that means the company has no idea how to hire people, and doesn't want to pay much either (because they're paying the recruiter a huge commission).

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

#359
> Number 7: Companies Really Want to Know Your Salary; Don’t tell Them

This can easily result in wasting your time interviewing for companies that will never be willing to meet your salary expectations. Unfortunately, a lot of companies aren't up-front about how much they're willing to offer, so I'm not sure what the solution is.

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

#360

- Companies are less willing to hire than I’ve ever seen Is this true for other people ?

It's definitely not my experience in the DC area. There's certainly a lot of pickiness, but I had no trouble getting multiple offers here recently, the main problem was that some of them didn't want to pay much. I ended up going with a company that's on a hiring spree and beat my asking price by a good bit.
Post reply on HN