Things I Learned from a Job Hunt for a Senior Engineering Role • Hacker News Board

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

#641

Post by ShroudedNight » Wed, Apr 25, 2018, 3:03 AM UTC

rajacombinator wrote: post #501

JackFr wrote: post #329

Earlier quoted context omitted.

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

From what I remember, it's simpler than that:

Assume sqrt(2) is rational and has the reduced form (x/y). Thus we are assuming that x and y are integers and that gcd(x,y) is 1. You square it and get x^2/y^2 which are somehow simultaneously coprime integers and also reducible to 2/1...

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

#642

Post by alew1 » Wed, Apr 25, 2018, 3:03 AM UTC

rajacombinator wrote: post #501

JackFr wrote: post #329

Earlier quoted context omitted.

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

I think here they just meant, show that no rational number is the square root of 2. Not rational = not expressible as a ratio. You assume that sqrt(2) = p/q for some integers p and q, then derive a contradiction.

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

#643

Post by jetsnoc » Wed, Apr 25, 2018, 3:05 AM UTC

> no one actually believes that anyone can code. [..] When did an entire industry of people get pre-judged as lying?

I've been hiring recently for a senior developer and I have had a dozen or more candidates not be able to explain composition and inheritance or the differences between an Object Oriented or Functional language. One person started describing how to define functions and another couldn't really explain inheritance.

For my company, candidates lying on their resume is our experience. A number of people ARE lying on their resume. we've front-loaded a lot of the "we don't trust your resume" in to the screening process and the first 30-minute screen because so many people list the dogs breakfast on their resume, but really can't do those things. I think a lot of times, someone else on the project team may have hacked on that type of thing and so they list it on their resume. There aren't a lot of good answers -- besides validating those skillsets -- since people can list anything that they want on their resume. I would love for someone to have an accreditation or certification program that was widely used so that we could know someone could do the work and most importantly do the work well since the implementation and the patterns they will be choosing will be with our company for years to come.

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

#644

Post by analog31 » Wed, Apr 25, 2018, 3:08 AM UTC

falcolas wrote: post #223

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…

Supposedly risk should be probability times cost. But I think that people have a remarkably difficult time processing a risk that's based on a very high cost and very low probability. (The limiting case of an infinite cost and infinitesimal probability is how I describe Pascal's Wager).

In those circumstances, it's easy to imagine the mental math: Firing someone could cost many times their salary, but a screening service costs 50 bucks per candidate. So the chance of weeding out one bad candidate pays for the service, right? Where's the fallacy?

I think the fallacy is that the service doesn't actually improve the hiring process, and the ROI is zero.

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

#645

Post by nythrowaway » Wed, Apr 25, 2018, 3:08 AM UTC

I don’t understand why getting a degree in cs at a good peogram isn’t good enough for the proof you can code. I had to write a ray tracer in graphics, calculate recurrence relations and code them in advanced algorithms analyzing all sorts of run times, wrote a compiler.

My friends in top law firms hire from top law schools and don’t ask technical questions to candidates. If they make it through top law schools they have an extremely high success rate as employees. Should be same for our field.

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

#646

Post by uiri » Wed, Apr 25, 2018, 3:10 AM UTC

ojbyrne wrote: post #557

hoorayimhelping wrote: post #458

Earlier quoted context omitted.

I agree that it's related to firing, but I don't think it's fear of interpersonal drama. The simple explanation is that it's really expensive to fire someone without cause. It takes months because the company has to produce a paper trail proving they fired the person for a valid reason to protect themselves from litigation. That's months of paying an individual who may be incompetent or toxic, months of paying people…

The simple explanation is that many employers believe that. In fact I don't think it's that hard. 1. As another commenter pointed out, most jobs are in "at-will" states. 2. Many companies require arbitration instead of litigation to settle any disputes as a requirement of employment. 3. It's just as expensive for the fired employee, probably more so, since if you litigate, you're unlikely to ever work again.

Every state in the US is an "at-will" state. That is a US based vs non-US based employment distinction.

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

#647

Post by Myrmornis » Wed, Apr 25, 2018, 3:15 AM UTC

> no one actually believes that anyone can code....When did an entire industry of people get pre-judged as lying?

Unless the author has never attempted to hire programmers, I don't understand this attitude at all. It's extremely common to find resumés vastly exaggerating the applicants skills in programming languages and technologies.

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

#648

Post by D_Alex » Wed, Apr 25, 2018, 3:16 AM UTC

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.

What if a=1, b=10, c=100 - etc? Assuming the strings were English words...

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

#649

Post by AndyNemmity » Wed, Apr 25, 2018, 3:19 AM UTC

lostcolony wrote: post #286

AndyNemmity wrote: post #210

Earlier quoted context omitted.

I did DB work forever never hearing ACID. I initially heard of it certainly from slashdot or hackernews, and it only ever ended up coming up due to not DB work, but DB analysis of tools. Once you start working on a particular database, and are working on all of the specific details of that db, how often does ACID come into things, really? It just doesn't.

Hence the followup question about consistency. I purposely gave a useless and very inaccurate answer as an example (and one I am paraphrasing from an actual candidate). If you legitimately did the work without picking up -any- of the terminology, -and- respond confidently to questions you should know you don't know the answer to (rather than admitting ignorance and asking for follow-up questions, or declaring assumpt…

The responding confidently about things you don't know is obviously a huge red flag for anyone regardless of position.

Otherwise, I think we simply disagree in some respect, although I think it's over emphasized due to the topic. I think both perspectives have a level of truth to them, and have their flaws. It really depends on the candidate, and what they really know. Perhaps my particular circumstances are sufficiently odd enough that they aren't useful in a broader context. Who knows.

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

#650

Post by AndyNemmity » Wed, Apr 25, 2018, 3:22 AM UTC

danpalmer wrote: post #263

AndyNemmity wrote: post #210

Earlier quoted context omitted.

I did DB work forever never hearing ACID. I initially heard of it certainly from slashdot or hackernews, and it only ever ended up coming up due to not DB work, but DB analysis of tools. Once you start working on a particular database, and are working on all of the specific details of that db, how often does ACID come into things, really? It just doesn't.

I’ll be honest, I don’t know a lot about databases, but Atomiticy comes up a fair bit in the web apps I write, as does Consistency in terms of designing data models that can’t go wrong, or trying to encode domain structure into data models to use the Consistency guarantees that Postgres gives us. Isolation is pretty important in general, and easy to reason about from a web app perspective, with requests being isolate…

I've done tons of disaster recovery, and no one ever called it ACID. It's never come up. The only time the type of discussion specific to the terms of ACID comes up is with other database administrators.

Just my experience, perhaps I live in another world.