I got asked LeetCode questions for a dev-ops systems engineering job today • Hacker News Board

Re: I got asked LeetCode questions for a dev-ops systems engineering job today

#431

Post by sokoloff » Sat, Jun 15, 2019, 1:43 AM UTC

OldHand2018 wrote: post #426

pault wrote: post #348

Earlier quoted context omitted.

Thanks. Unfortunately we can't afford to pay front end developers $300k/year. And what we are paying is more than competitive. It's not an issue of pay, it's an issue of availability and not having the resources to stalk and poach developers from other companies. We also have a generous internal referral bonus, and various recruiters sourcing candidates. Is there something else I'm missing? Edit: I don't think you ar…

> Is there something else I'm missing? Yes, probably. Why do you need a supply of new front end developers? Is your workplace exceedingly lethal? Have you considered that paying $2XX/year is a signal? It attracts a certain type of candidate and you can't extrapolate the talent level of the entire market just based on your experience with those that would try to land a $2XX/year job. Where I live, trading firms can pa…

Seems like Paul can’t catch a break here. He is simultaneously not paying enough and paying too much...

Re: I got asked LeetCode questions for a dev-ops systems engineering job today

#432

Post by wutbrodo » Sat, Jun 15, 2019, 2:03 AM UTC

dcolkitt wrote: post #250

wutbrodo wrote: post #210

Earlier quoted context omitted.

I think it's a holdover from hiring more junior candidates: after a few years interviewing and sitting on HCs at Google, I hired for a tiny startup that had tons of trouble sourcing candidates. My interviews at the latter place eventually devolved into basic IQ tests. Simple coding problems are pretty ideal for this, since they also lightly test necessary domain skills. The problem is that this doesn't scale with tal…

> My interviews at the latter place eventually devolved into basic IQ tests... The problem is that this doesn't scale with talent and/or experience. Industrial psychology has consistently found that IQ is a better predictor of job performance than experience. The reason being is that intelligence is defined as the ability to acquire knowledge and skills. Intelligent people literally learn faster than others. The skil…

I'm probably a stronger believer in this than most, which is why it was easy for me to follow the evidence for our narrow case where it led. But you only need a weaker form of this to explain the experience I had recruiting at that company.

All it takes to be a good engineer at the lower levels is a sufficiently high IQ/creative problem-solving ability. Put someone like that under the mentorship of someone who's learned good engineering habits and (barring severe behavioral problems), you'll have a pretty great junior engineer in a few months.

Otoh,Experience and other habits and knowledge do become more relevant at higher levels, only because the responsibilities of the job shift and grow, such that you can do a lot more damage in the "learn by exploration" period of becoming good at something by just being really intelligent and learning on the job.

I currently work with a bunch of physics and math and CS PhDs, people who are likely as intelligent as I am or more, but I'm a lot more equipped for our job because I'm applying that intelligence in the context of understanding how engineering systems work, at both a technical and personal level. There are tons of engineering habits that are second nature to me that never occur to them; if they shadowed me closely and I dedicated time to explaining the reason I do every little thing I do, then they'd pick up those habits in the same way junior engineers do.

That is to say, as one would expect, the relative supremacy of IQ over other skills like conscientiousness (or yes, experience) diminishes at the higher levels. Everyone I work with would be considered "really smart" by any reasonable measure, but it's not purely the smartest who are the most effective anymore, the way it was when we were entry level.

Re: I got asked LeetCode questions for a dev-ops systems engineering job today

#433

Post by justinclift » Sat, Jun 15, 2019, 2:25 AM UTC

pault wrote: post #270

sokoloff wrote: post #262

Earlier quoted context omitted.

If that's a competitive salary for your area (you would know better than me, but that range in the middle of the country certainly seems competitive), then have a look at your recruiting sourcing funnel. If you're only sourcing the same 75% of active job seekers who are bombing most of their other interviews [thus leaving them available to come in and bomb yours as well], start advertising your positions elsewhere or…

You're correct. The problem is that the positions we have open are for front end developers, and for a variety of reasons (mostly that the scale of complexity on the front end has increased so rapidly that the industry still has a lot of people in it that were writing mostly HTML and CSS a few years back) the supply of competent developers is far lower than the demand, and anyone worth their salt is already happily e…

Maybe hire people with the a good teamwork attitude + ability to learn, and training them up to the required standard?

Sounds like it'd be more effective than spinning wheels without traction. :/

Re: I got asked LeetCode questions for a dev-ops systems engineering job today

#434

Post by rectaway » Sat, Jun 15, 2019, 3:01 AM UTC

ryandrake wrote: post #415

chimpburger wrote: post #364

Earlier quoted context omitted.

What about github projects? Can't you ask for examples of code they have written?

Sure, if they actually have any. You’d need a way to verify the code was actually written by them. You’d also need to be careful you’re not overly biasing towards “people who [have time to / are allowed to] publish on GitHub”. Plenty of good developers don’t/can’t use GitHub.

You don't really need to test basic skills over and over again.. you could just ask them what part of the code they wrote, if they don't have any open source code then ask them to send you a take-home code assignment they completed for another job interview, or have them complete one you make for them.

You're right that there are plenty of developers that have no experience with GitHub, but I'm sure there are far more who would struggle with simple theoretical questions and programming quizzes during the interview, because it's difficult to think clearly when you're feeling a lot of pressure.

Re: I got asked LeetCode questions for a dev-ops systems engineering job today

#435

Post by perl4ever » Sat, Jun 15, 2019, 3:03 AM UTC

IshKebab wrote: post #372

ConcernedCoder wrote: post #123

Earlier quoted context omitted.

This disproportionally filters for those who can think/code and perfom while under pressure/observation... i.e. the "porn stars" of software development, if you will. Similar to how not everyone is able to perform well while having sex-on-demand in front of a camera -- these same people are more than likely able to have sex when not under pressure and observation, and probably are quite adequate while doing it. My pe…

By the same logic you might say that we shouldn't interview at all because it selects for people that are good at being interviewed. Obviously this is true but I think it would be pretty crazy to not interview people. Frankly I think most people suck at being interviewed initially, but you can definitely improve with practice. The same as public speaking and interviewing candidates.

Some people are even good on a take-home test, good at chatting in an interview, good at coding at their desk, but completely unable to code in an interview. And you can fail an interview at some places if you are one of them.

Re: I got asked LeetCode questions for a dev-ops systems engineering job today

#436

Post by perl4ever » Sat, Jun 15, 2019, 3:11 AM UTC

wutbrodo wrote: post #210

caymanjim wrote: post #85

Interviewing people is hard. Most people suck at it. I've interviewed over 100 people in my life, and I've been interviewed about ten times. I know I still suck at it. The code test is one of the more annoying facets of interviews. On the hiring side, it's an efficient way to screen and vet candidates for basic skills. It's relatively low cost to the employer to have a recruiter issue the test. If you come up with yo…

I think it's a holdover from hiring more junior candidates: after a few years interviewing and sitting on HCs at Google, I hired for a tiny startup that had tons of trouble sourcing candidates. My interviews at the latter place eventually devolved into basic IQ tests. Simple coding problems are pretty ideal for this, since they also lightly test necessary domain skills. The problem is that this doesn't scale with tal…

"the reality is that many candidate pools consist of some of the dumbest people you're likely to ever encounter"

I think people genuinely experience this but are unwilling to consider that their pool is not the random sample they expected. Something subtle is filtering out (nearly) all the non-dumb people.

Have you ever seen a personal ad with a long list of characteristics that are unwanted?

Re: I got asked LeetCode questions for a dev-ops systems engineering job today

#437

Post by perl4ever » Sat, Jun 15, 2019, 3:17 AM UTC

winter_blue wrote: post #264

dcolkitt wrote: post #250

Earlier quoted context omitted.

> My interviews at the latter place eventually devolved into basic IQ tests... The problem is that this doesn't scale with talent and/or experience. Industrial psychology has consistently found that IQ is a better predictor of job performance than experience. The reason being is that intelligence is defined as the ability to acquire knowledge and skills. Intelligent people literally learn faster than others. The skil…

> Industrial psychology has consistently found that IQ is a better predictor of job performance than experience. If hiring managers are aware of this, then it might be a good idea to apply to Mensa. If you're able to get in, maybe putting "Mensa" down on your resume isn't that bad of a thing. (I've always felt it would make one come off as a douche, but maybe that's not so true.)

My opinion of Mensa was formed by someone who told me about how, when she was a hiring manager, she once had an applicant who made a point of belonging to Mensa and didn't seem to have anything else she was proud of or had accomplished.

That doesn't mean I am necessarily on board with the fashionable view that IQ is meaningless, but I think to the extent there are people whose IQ is disconnected from their abilities/achievements, it's going to be the ones who are preoccupied with it. So I would think belonging to a high-IQ society would send the wrong message.

Re: I got asked LeetCode questions for a dev-ops systems engineering job today

#438

Post by perl4ever » Sat, Jun 15, 2019, 3:18 AM UTC

SubuSS wrote: post #119

tomp wrote: post #103

Earlier quoted context omitted.

Everything you say sounds extremely reasonable... but still, there are plenty of stories (mostly online, so they might not actually be true) of people hiring a person that aces (mostly non-technical) interviews only to show absolutely 0 actual technical skills on the job.

I agree with the urban legend guess. Yeah it happens, but not as often as you think.

An alternative hypothesis I have is that some organizations inadvertently skew their pool somehow, and they really do get a lot of these, but other places don't.

Re: I got asked LeetCode questions for a dev-ops systems engineering job today

#439

Post by devanl » Sat, Jun 15, 2019, 3:37 AM UTC

maxxxxx wrote: post #60

woodrowbarlow wrote: post #46

Earlier quoted context omitted.

actually, i would think leetcode interview problems would be more relevant for embdedded development jobs. in embedded, you're less likely to have access to libraries that implement advanced data structures, sorting and searching, string manipulations, etc. so you'll need to do more of it by hand.

That’s my impression too. I would expect more handcrafted code on embedded systems and you need more awareness of computational complexity and memory needs.

It's not as important as you would expect for a couple of reasons:

1. The size of the data is often much smaller - the savings from using an nlogn time algorithm vs a n^2 algorithm are much smaller when n=10 versus n=10000. There's a good chance that the constant time setup will dominate for those smaller datasets.

2. To a certain extent, embedded systems don't need to be as fast as possible - they just need to be "good enough" to meet their deadlines so that the rest of the system functions as expected. It'd be nice to be able to compute 1000 CRCs per millisecond instead of only 10, but if it already takes 1 millisecond to transmit the CRC over the serial bus, it's not going to make the system substantially better at its job.

So yes, there is a lot of handcrafted code, but quite often it's just implementing your standard naive brute-force algorithm with minimal code size, minimal memory overhead (preferably without dynamic allocation), and well-understood worst-case latency.

Re: I got asked LeetCode questions for a dev-ops systems engineering job today

#440

Post by sethammons » Sat, Jun 15, 2019, 5:02 AM UTC

malvosenior wrote: post #144

kache_ wrote: post #126

The reason that people still ask algorithmic questions is because they work for avoiding false positives. False positives are a lot more damaging to a company compared to false negatives. While algorithmic questions can get many false negatives, they don't get much false positives. What does it mean for a software developer? Spend a few hours a week doing leetcode questions. They're really not that hard.

> False positives are a lot more damaging to a company compared to false negatives. This is accepted blindly as dogma in our industry but in my experience it's only the case if the company is dysfunctional and management is too weak to let poor performers go quickly. Being an effective leader means being able to hire and fire quickly. If you're open and honest about it, you don't have to do as much as much intense ve…

I disagree. We had a candidate talk the talk when we were experimenting with different interview methods. They came in and used a lot of team time to start learning the system and stack. And continued to use the team's time, costing real productivity. They lasted a quarter or so. Not only did the team lose out on productive time, they lost morale by having to support a team member who was not getting up to speed and had to have their work redone and an couple members lost more morale when the newer person was let go. It was a net loss to bring in the new poor performer. I've seen it play out similar more than enough to be convinced that the adage is accurate.