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

521–530 of 766 posts

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

#521

Post by danielvinson »

jasode wrote: post #496
thegayngler wrote: post #365

Earlier quoted context omitted.

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…

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

I believe he is referring to the case of the interviewer being a peer rather than a manager.

In my experience the manager cares about fit and attracting you to the team, whereas the peers are all looking for reasons NOT to hire you.

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

#522

Post by ljw1001 »

stevenwoo wrote: post #401
ljw1001 wrote: post #331

Earlier quoted context omitted.

I've worked at a company that generally hired extremely good engineers - much better than average and they were very successful because (1) doing that was actually important to the very hard problems they were solving, and (2) every other company in the world wasn't trying to take the same approach to hiring. Today, everyone thinks they should hire like google, even though they're building a mid-sized web or phone ap…

How did they interview these engineers to hire them in the first place?

Really hard puzzles that you had to submit a solution to if you wanted an interview. This was very rare in those days. The problems were original and clever, not pulled from a book or website. Also, the company was in Cambridge, MA and had very close ties to MIT so they could find people like that.

If you got an interview, and did well you got another challenging programming problem to solve on-site. You were given a computer with the programming environment of your choice and as much time as you wanted, as well as someone to ask questions from.

I think it was also important that the company solved hard graph problems in Lisp, with a lot of macro-driven code. If you were a Lisp programmer, you generally wanted to work there.

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

#523

Post by ryanianian »

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

> Alas, I really do care about the thought process.

Sure - but you're not likely to really see the "real" thought process you're hiring for by asking a stranger a riddle you already know the ansewr to in a high-pressure situation.

Real problem-solving and thinking is done in a huge number of ways that sometimes isn't conducive to strangers, pressure, or whiteboarding.

> I'm interested in when candidates pick not-optimal choices for good reasons

Right - which is why starting with something they've written on GH (which is something they've thought about and are probably passionate about) is a great jumping-off point for such a convo.

> As an aside, the reason not to work on novel-to-you problems with job-seekers is that it's very hard to fairly compare candidates after.

I see your good-intention here, but it's nearly impossible to compare two candidates without all kinds of biases (implicit and explicit) coming into play.

> I strongly prefer pairing on the same problem with all the candidates in a batch. Otherwise it's hard to tell if a bad result is due to a bad problem or an unacceptable candidate.

I think this may be another way of trying to compare candidates to eachother (which is perilous).

Good candidates can do well with bad questions, and bad candidates can rarely do better than okay with good questions. There are lots of good/proven questions you haven't solved - ask your colleagues.

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

#524

Post by ljw1001 »

tedsanders wrote: post #367
Balgair wrote: post #330

Earlier quoted context omitted.

Hmm, maybe we should 'equalize' the playing field then: Give everyone something from left field that pretty much all people bomb, that'll see how quick they learn. Exp: You must code in an unfamiliar language (Fortran 1988, for example) and do something simple in it. At least then you'll know that people are all starting from scratch. Time it, make sure it doesn't last more than 2 hours, see how laughably slow we all…

I love this idea. Testing how well someone can learn new skills can be just as important as the skills they've already learned. However, the problem is that as soon as it becomes known that Google is giving tests in Fortran 1988, applicants will study Fotran 1988 and thereby reduce the efficacy of the test. It will also have the sad side effect of incentivizing people to waste time studying Fortran 1988 rather than b…

Umm. Not if they only stay 2 years at your company. I think that's about average outside of ones with golden handcuffs.

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

#525

Post by Tyr42 »

leongrande wrote: post #432
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…

You need not to sort the strings. Create a vector with indices he ascii codes, incrementing for the first string and decrementing the count for the second, and keep a count of the number of chars, if you get a negative number exit false, else if the count of chars is zero then each one is an anagram of the other. (n+m+128) operations n and m are the length of both strings and 128 for creating the vector

That sounds a lot like doing a radix sort of the strings, then comparing the run length encoded, sorted strings ;p

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

#526

Post by rojobuffalo »

boyter wrote: post #462
rojobuffalo wrote: post #212

Earlier quoted context omitted.

I really don't like take-home assignments. It's a one-sided time investment. If I'm asked to do one I say that I'm only prepared to put in 45 minutes on it. Now that I've done this a few times and subsequently been rejected after submitting, I'm leaning towards rejecting assignments altogether. It doesn't really serve me well in job searching but I feel strongly about it. It's a bad investment on my time and the assi…

Same. Now that I am on the other side I send out a short piece of code and ask the person to point out all the errors in it. There are about 20. It takes about 5-10 minutes of the candidates time and I have had a lot of success with it.

That's a unique approach or at least one that I haven't encountered. I like it.

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

#527

Post by Clubber »

twodave wrote: post #439
Clubber wrote: post #369

Earlier quoted context omitted.

I don't mean this the way it sounds, but if you can't tell if someone is an imposter by talking shop with them in your chosen profession , you probably shouldn't be doing the interviewing.

I think unless you're prideful enough to believe you can identify someone's level of productivity from a short conversation, it's probably better to see the proof. Again, why would I settle for a conversation when I can ask for first-hand proof? It's like a judge dismissing concrete evidence and just basing their verdict on the circumstantial. Sure, it's likely to be right most of the time, but what about when it isn…

>I think unless you're prideful enough to believe you can identify someone's level of productivity

None of the techniques discussed in this article are even attempting to judge productivity, they are attempts to judge coding ability. It's good that you bring up productivity though; that's what we are really after, isn't it?

>from a short conversation

I'd argue 30 minutes to an hour is not a short conversation. Do you think an imposter could fool you about tech (assuming you are an active programmer) for 30 minutes to an hour?

>it's probably better to see the proof

You're not proving anything except the fact that the candidate has memorized a merge sort algorithm (or whatever trivia you are testing for). What you really want to know is, can they ship?

I think you should at least consider the idea that not only are these tests and homework assignments (past fizz buzz) a poor indicator of ability, they active repel any candidate good enough to be in even reasonable demand. I mean you have a lot of people on not only this thread, but many other threads saying the same thing.

Time for a little reflection, what does your company offer that even a mediocre developer can't get in 20 other places in your city? I mean if I could get "market rates," and a "fine cubicle," and "standard PTO" in 20 places, tell me again why I would bother with this rigamarole?

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

#528

Post by ljw1001 »

jasode wrote: post #496
thegayngler wrote: post #365

Earlier quoted context omitted.

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…

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

I recall one of my friends, when I was at Google, sending me a screenshot of code written by Jeff Dean with an obvious bug. Jeff is, of course, extraordinary, but I wonder how many companies might have passed on him if he submitted that code in an interview setting.

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

#529

Post by lostcolony »

kyberias wrote: post #423
lostcolony wrote: post #28

Earlier quoted context omitted.

Seriously. I've sat on the hiring side. I've seen impressive resumes. I've had reasonable discussions with people. And then I give them a very, very trivial coding exercise (a take home, they're free to Google, do it on their own computer, in their own IDE, in their professed preferred language), in a time frame that while constrained is still plenty...and the result is -terrible-. I can try and come up with reasons…

Do you really think that text-book question about ACID determines whether the applicant is a good DBA? I know something about databases but I couldn't remember all the letters.

Hence the follow-up (which I'd ask regardless, as we work our way to more and more hands on stuff). It's okay if someone has never heard of the acronym before. And an answer of "Uh, I remember the C is consistency...and the D is durabilty. But otherwise no" is as good, to me, as remembering the entire thing; it shows you've run across it before, that you've at least read up or received some sort of training with DBs.

I mean, look at this thread; would it be better to start with "Here are some example tables, please write the SQL that will return me (etc)" and turn it into a coding exercise? Because I honestly don't care that much about that from anyone espousing a senior level of knowledge.

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

#530

Post by [deleted] »

nerraga wrote: post #199
brandall10 wrote: post #39

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…

Can you elaborate you that last statement? Are Rails developers less terrible than the C/C#/C++ people with whom you’ve worked? If so, what are your thoughts on why that may be?

[deleted]
Post reply on HN