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

741–750 of 766 posts

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

#741

Post by ascorbic »

wpietri wrote: post #398
ryanianian wrote: post #254

Earlier quoted context omitted.

If the GH code is there, works, and is up to coding standards, why do you care about how the sausage was made? I'd look to see if the code is well-designed, organized, original, tested, etc. It's generally easy to see if the author of code knows how to decompose a problem into pieces. So..saying "we're looking for thought-process not the actual code" feels a bit disingenuous tbh. Now: If you care about being able to…

Alas, I really do care about the thought process. If a person arrives at a great decision for bad reasons, I may not want to hire them. More importantly, though, I'm interested in when candidates pick not-optimal choices for good reasons. So much of software development is about tradeoffs. Seeing and hearing how they tackle those tells me much more about how they'll do than the specific code in question. As an aside,…

If someone has a good GitHub profile I won't ask the candidate to do much or any coding exercises, because it's much better to just discuss the code they already wrote. I'll put it up on the screen and get them to talk me through it. I'll ask about anything that looks unusual, but also about anything that looks particularly elegant. Even if they wrote it a while ago they should still be able to talk about it.

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

#742

Post by ascorbic »

thomascgalvin wrote: post #380
always_good wrote: post #238

Earlier quoted context omitted.

Your refusal exposed you as someone with a hubris that's hard to work with. Who doubles down and refuses to budge. That you couldn't yield on such a trivial, manufactured matter would make me wonder how you respond in a team environment on real matters in the face of adversity.

CSV is really fucking hard to parse. There's tons of edge cases. "I'd just use a well-known, well-tested library" is a very valid answer. One of my go-to questions is "sort this array", and if the candidate types `Arrays.sort(input)` they get bonus points, because it shows they have useful knowledge of the language they'll be writing in.

That's a bit unfair. I agree that Array.sort is the best answer, but array sorting is such a classic interview puzzle that most candidates will expect that that's what you want. So instead of the bonus answer, they'll slog away trying to remember the algorithms that they learnt at uni years ago (or codecademy last month).

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

#743

Post by ubernostrum »

thegayngler wrote: post #365
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…

Most engineers would not hire themselves. That has been apparent to me for awhile now. I’m not sure why they expect people to be to be better than they were when they were hired. I don’t expect engineers to be better than me. I have but one qualification. Can they do the job? Are they strong enough that I can guide them into the position I need them at if it is required. So much focus has been put on 10x this and hig…

Most engineers would not hire themselves.

IIRC a Google recruiter once sent a set of packets to a hiring committee and all of them got a "no hire". Then the recruiter revealed the packets were lightly-anonymized versions of the actual packets of the hiring committee members, from when they'd all originally interviewed.

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

#744

Post by ubernostrum »

d1zzy wrote: post #260
yodsanklai wrote: post #177

Earlier quoted context omitted.

I recently interviewed at a big tech company (phone interview). I spent quite some time practicing on leetcode (completed at least 150 problems). During the interview, it took me a few minutes of thinking before completing the assignments with what I think was the expected solution. We discussed the complexity and a few possible variations. The interview sounded satisfied and I really had the feeling that I had naile…

As someone that does lots of coding phone interviews I can say that yes, time is a factor. But it's relative, ie I'm comparing you to the time it took other candidates to solve the same problem. After all, we have to evaluate you, over the phone, in the course of less than an hour. If 2 candidates arrive to the optimal solution, the one that did it much faster is the better candidate. It sounds to me like you did pre…

the one that did it much faster is the better candidate

Translated: "the one that did it much faster is a more recent graduate and exploitable for 100-hour weeks at below-par pay, hire that one".

Congratulations, now you know how to hire at a tech company!

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

#745

Post by deanCommie »

thegayngler wrote: post #365
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…

Most engineers would not hire themselves. That has been apparent to me for awhile now. I’m not sure why they expect people to be to be better than they were when they were hired. I don’t expect engineers to be better than me. I have but one qualification. Can they do the job? Are they strong enough that I can guide them into the position I need them at if it is required. So much focus has been put on 10x this and hig…

"A players hire A players and B players hire C players" - Steve Jobs (Maybe?)

If you don't encourage a culture where everyone is asked to hire people better than themselves, it can easily degrade where each progressive hire is slightly worse.

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

#746

Post by ubernostrum »

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

Except they don't just want a solution, they want a solution with certain performance characteristics. And they want it to be the solution with the best performance.

Which means what they're really saying is not "we want problem solvers". What they're really saying is "the bare minimum for entry level work here is being able to, in 30 minutes and on the spot, out-perform top-tier theoretical CS researchers".

Which in turn really boils down to "be a recent CS graduate who memorized this algorithm in advance so as to 'derive' it later on command".

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

#747

Post by [deleted] »

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.

[deleted]

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

#748

Post by knopkop_ »

cema wrote: post #726
mywittyname wrote: post #492

Earlier quoted context omitted.

Screw it, everyone else is posting code examples: def vc(s): return len([c for c in s if c in ['a','e','i','o','u']])

Probably s.tolower() or whatever it is in Python.

def vc(s): return len([c for c in s.lower() if c in ['a','e','i','o','u']])

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

#749

Post by geebee »

aeorgnoieang wrote: post #493
solatic wrote: post #353

Earlier quoted context omitted.

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

How would you test, "in a certifiable way", just the first of your examples "write readable and maintainable code"?

You might not test this. Keep in mind, the bar exam, medical boards, actuarial exams, and other entrance exams aren't intended to establish competence in all areas of professional practice.

I think that the google style data structures and algorithms exams are a good case in point. Think of these like the actuarial exam for linear algebra, vector calc, and numerical analysis. These exams don't of course test everything important about being an actuary. But they do establish competence in something that can be tested. As a result, actuaries don't (to my knowledge) have to do 5 hours of whiteboard exams doing LU matrix decomposition or finding a steepest descent vector. Whereas software developers have to find all matching subtrees in a binary tree over and over (and over).

What I like about the actuarial exams is that while they are rigorous, and it helps immensely to have majored in math or something closely related, you are free to decide how to prepare for these tests. Although I like the idea of a widely recognized entrance exam, I really don't like the idea of something like the law schools putting themselves (and 200k in debt) in between an individual and the right to take the exam.

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

#750

Post by geebee »

orangecat wrote: post #656
geebee wrote: post #160

Earlier quoted context omitted.

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.

In a way, yes. But by blurring this distinction, you make it impossible to distinguish between an hour at the whiteboard solving a data structures problem, and an hour answering questions like "tell me about a time you overcame a challenge and what you learned".

Because people outside our field experience interviews in the second way more often, I think they don't fully understand what goes on in google style interviews. This is why I would call what we go through "Exam-style interviews", drawing a distinction between the two - even though I agree with you that they have elements in common.

Post reply on HN