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

131–140 of 766 posts

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

#131

Post by calcifer »

eanzenberg wrote: post #115
calcifer wrote: post #78

Earlier quoted context omitted.

> 99% of my candidates can code, as in iterate over collections, write case statements, and call functions. Honestly, that's way too trivial to call "can code". I usually ask something less trivial, yet still extremely easy like "a function to check if a string is a palindrome" (I explain what a palindrome is) or "check if a substring exists in a given string". You wouldn't believe how many people "with 10 years expe…

How often do you need to write palindrome functions for your job? Checking substring in a string is a 1 liner in languages like python. I was at a final interview with FAANG. One question asked was to load a csv. I used pandas, it's a 1 liner. You could see the wretched face of the interviewer since he was expecting a with open() as f: do_some_shit and kept pushing me to write this on the board. I looked at him and s…

> How often do you need to write palindrome functions for your job?

That's like answering "how often do you need math?" to the question "what is 2+3?". It is an utterly, completely, stunningly trivial question that even a CS101 student on their first semester should be able to answer.

> used pandas, it's a 1 liner. You could see the wretched face of the interviewer since he was expecting a with open() as f: do_some_shit

I would be perfectly fine with the pandas answer, but my point is "csv parsing" wouldn't be my first question, I'd start with something much easier and if you managed that, I'd gladly accept pandas as a valid and then asked you to elaborate further (what does this pandas function do, how would you implement it yourself etc).

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

#132

Post by SmirkingRevenge »

logfromblammo wrote: post #54
LandR wrote: post #12

> Number 1: It Takes Longer than Ever to Get Hired Last twice I've looked for a developer job, I got offered a position and was hired within 2 weeks. > No one believes that anyone can actually code. Quite rightly, most devs can't code. > Extensive homework is now normal. Not been my experience, I've done some homework assignments but none were ever more than 1 hours work (and then even the standard of the tests were…

At times, I have tried to press a contact from a job lead on what I could have done better in my interview. They will not give you even a single bit of feedback--a seemingly innocuous yes or no question is met with dissembling or equivocation, always. What bothers me most is that employers don't seem to be showing equal commitment to the interviewing process. They will ask you to do hours worth of homework for them,…

> They will ask you to do hours worth of homework for them, but then can't be arsed to discuss it with you for five minutes.

This has been my experience with homework assignment interviews (Though I still prefer them to whiteboards).

In no cases, has any interviewer reviewed my homework before the interview. So the homework critique/qa sessions end up being more like a presentation or walkthrough of your solution, like a presentation for a meet-up, even though they are often described as more of a code review/interrogation about your choices.

Which I don't mind honestly. If you know that going in, and are prepared - its an opportunity to impress, if you can be polished.

Talk at them about your solution for the allotted time or until they make you stop :P

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

#133

Post by spamizbad »

haskellandchill wrote: post #68
pg_bot wrote: post #6

Number 2: No One Believes Anyone Can Actually Code It's surprising to see the number of people who interview for lead technical roles that cannot code, or whose work is exceptionally sloppy. Incompetence is more commonplace than the author believes, even at the highest level.

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…

We set our in-house recruiter up with a coderpad question that screens candidates with a simple question:

"Write a function that counts the number of vowels in a string"

Candidates are allowed to run it multiple times and just have to produce a correct result within 10 minutes. It's not a trick question -- the test case in place makes sure you pay attention to case.

Success rate for mid to senior devs? Only 60%.

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

#134

Post by zip1234 »

s2g wrote: post #88
geebee wrote: 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…

> it's there because we have no industry wide, respected entrance exam So you think the person with 30 years experience might be, whats the word... oh right. Lying. You think they are lying. Quit trying to dress it up. Coding tests are exactly you saying you don't believe the experience written on the resume.

I use a coding test not only to see if someone can write basic code, but also to assess general intelligence and see/hear their problem solving process. A resume definitely doesn't tell you all you need to know and experience does not necessarily mean effectiveness.

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

#135

Post by zumu »

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…

> I typically red-flag potential employers who doesn't sufficiently validate the skillset of potential hires.

I'm beginning to take this to heart.

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

#136

Post by reggieband »

crdoconnor wrote: post #55
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…

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.

Maybe just luck? I interviewed someone for a senior position last week and that candidate didn't know what an array was. That was probably the worst case I've seen but by no means the first time I've seen someone struggle with the very basics.

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

#137

Post by jandrewrogers »

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". Something I keep in mind when interviewing candidates is that there is that good understanding of the general design of algorithms does not imply that they should be able to throw together an implementation of an arbitrary algorithm with minimal effort unless they've needed to do it in the recent past. Expecting people to spending many days practicing the implementation of arbitrary and often irrelevant algorithms is unreasonably in my opinion. I am more interested in figuring out if they could given adequate time.

A valuable practice, which surprisingly few tech companies do, is to ask candidates about diverse and orthogonal problem domains, or alternatively, allow the candidate to pick from a diverse set of problem domains. In the former case, you often find that candidates have difficulty writing even simple solutions for some problems but on others they instantly and fluidly can code up a good solution. Because they've had to do it in recent memory and still have the "muscle memory" from doing it previously. You often see bipolar results across the problem set this way.

For senior engineers with deep domain expertise in an area, there is an additional trap in that they use more sophisticated and often very different algorithms in their day to day lives than are applicable to the toy problem domains. Graph algorithms are a good example of this, and they are popular in interviews. The representations most engineers know (e.g. adjacency list or matrix) don't scale but the extremely high scale algorithms operate on a different set of principles that aren't trivial to code and aren't relevant to non-parallel cases; coding up an adjacency list graph traversal algorithm is going to be very unnatural to a software engineer used to doing the same on trillions of edges in real-time. It would be crazy not to hire an engineer on this basis but I've seen it happen, ironically because their expertise caused them to show poorly on the coding exercise.

Interviewing for technical skills is intrinsically difficult but I think that as an industry we are much worse at it than we could be. 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.

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

#138

Post by imron »

diminoten wrote: post #91
time0ut wrote: post #75

Earlier quoted context omitted.

I usually ask a trivial problem like this. Not really to see if they can code (I have had one or two people fail here though), but more to serve as a conversation topic. Why did you do this? How would you do that? etc...

But I don't want to talk about FizzBuzz! It's boring! There's a "right" answer, and not a lot/any real choice or nuance. Ask me about your current problems, problems the person filling the position would need to have opinions about. If nothing else, maybe I could crack a tough issue for you that would have material value. I've given FizzBuzz, and I've done FizzBuzz. It's hard to do it/get it and not feel like there's…

> and not a lot/any real choice or nuance.

Exactly! And people still get it wrong.

It's a low-pass filter to weed out programmers who can't even do FizzBuzz, because despite their lack of coding prowess their résumé will still look similar to yours.

> and not feel like there's some degree of insult involved.

That's just reading far too much in to it.

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

#139

Post by pnathan »

I suspect OP is in a space both professionally and physically where the job market is poor and a ton of cruddy candidates show up.

I relate though, although I'm in Seattle area, which is a great place - I interview really badly. I strongly agree that hoops are getting added.

However, I have found that great companies do compete on hiring process. Microsoft remains the Gold Standard for me in how fast they turnaround their hiring when it gets going.

> The job search takes much, much longer than it used to.

No. I'm picky and I don't practice stupid questions. It's always taken a long time for me. If you hit the right company and have the right skills, it'll be under two weeks for a hire though.

> No one believes that anyone can actually code.

Yes.

> Coding Tests Can Trip Up Even Good Engineers

Yep. Probably 10% of the time I have a "frick, I blanked" moment.

> Extensive homework is now normal.

Nope. Find better companies?

> Every company’s “process” is different

Every company believes they are snowflakes.

> Outsourced hiring “services” are very much in vogue

Yes, but I think this relates to competitive hiring spaces with lots of poor candidates.

> Companies Really Want to Know Your Salary; Don’t tell Them

Sigh.

> Interviews Matter Much, Much More to You Than to the Company

Yep.

> Age discrimination really exists.

I'm definitely not looking as young as I used to and it worries me.

> You’ll never really know why you weren’t hired.

That's because they don't want to be sued.

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

#140

Post by warrenm »

ryandrake wrote: post #113
calcifer wrote: post #78

Earlier quoted context omitted.

> 99% of my candidates can code, as in iterate over collections, write case statements, and call functions. Honestly, that's way too trivial to call "can code". I usually ask something less trivial, yet still extremely easy like "a function to check if a string is a palindrome" (I explain what a palindrome is) or "check if a substring exists in a given string". You wouldn't believe how many people "with 10 years expe…

Problem is: It's hard to judge the difference between someone who doesn't know what they are doing and someone who does but loses it under the extreme pressure of an interview wherein their entire future with the company is being determined by their performance on a 30 minute exercise. Throughout my career, I've been in professional situations where I was under a lot of pressure: Having to explain failures to executi…

While I agree in the abstract ...honestly, it's not that hard to write at least pseudocode for problems like that regardless of the "stress" of an interview

Is it reasonable to ask things like that? Maybe, maybe not.

But as stressful as an interview is, it's still a basic problem (I can English describe it to you in 30 seconds...coding (in C/C++) would take me another 5-8 minutes (and, probably, be pretty damn inefficient ... but it's still a simple problem)

Post reply on HN