Live data from Hacker News

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

fuzzyblog.io

371–380 of 766 posts

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

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

Not all technical roles require coding skill. Unless you meant “lead software engineering role” in which case yes, you are right.

Most of my day as a lead was on the phone putting out fires, not coding. I hated it and the politics and blame shifting that came with it.

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

#372

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.

I briefly mused about just summing the ASCII codes for each letter in the strings. But quickly discarded the idea for this reason :)

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

#373
post #250

Earlier quoted context omitted.

I would say that if you know the answers to 100 top coding questions (and understand them, a good interviewer will poke you to determine that) then you are a pretty good coder and you should be hired. Seems working as intended :) For many tech companies where they get a lot more candidate applications than they have positions for, the goal of the interview process isn't to avoid losing good candidates, it's to not hi…

That's like saying that if you can retype The Great Gatsby, then you're a great writer. So much more goes into software engineering than "Can solve tiny example problems in an examination system"

Like I said, a good interviewer ensures you understand the solutions of those problems (the problem might even be formulated in a different form than the exact form you learned) not just typing out text verbatim. If you do understand the solutions of top 100 coding questions, I think you have a good start. Part of solving the problem in an interview will also be being able to code, so it's also testing your coding ability in a given programming language.

True that software engineering is more than that, but those other things largely depend on in-house company processes, tools and policies so you would learn them afterwards.

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

#374

Earlier quoted context omitted.

So what is the interviewer supposed to do to find out if you can code? They want to give you a simple, straightforward task to see how you code. Of course, every simple, straightforward task is going to have an existing tool to do the job, but they aren't looking for a solution to parsing CSV, they are looking to see you code. They can't ask you a complicated problem, because they don't have the time (nor do you) to…

They want to give you a simple, straightforward task to see how you code. Overgeneralized at best, LOLworthy at worst. Does this include palindrome questions for Ruby that require the use of linked lists? Because I had that from a CTO of a couple-hundred person company not two months ago.

What would make a good programming challenge for an in person interview?

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

#375
One thing that grinds my gears is study guides are pretty much useless in the tech industry. They all say the same thing -- literally everything. Leetcode, HackerRank, or very very broad topics like algorithms, data structures, etc.

The worst ones I think are actually frontend engineer interviews because it's a coin flip if they are asking you fundamentals or very focused topics in frontend. I've actually been meaning to make a Youtube series on how to succeed in the frontend interview (which also implicitly sets expectation of what a frontend engineer interview looks like) but haven't gotten a chance.

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

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

And on top of all this, many will then turn around and claim to regulators that there is a labor shortage! When it's obvious their behavior is only sustainable when they have a glut of applicants.

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

#377
post #191

Earlier quoted context omitted.

How is proving self study ability relevant to a job? Doesn't my resume of wildly varying projects and my ability to competently talk about them prove that? It sounds to me like a way to weed out pesky applicants who have families or who are simply older.

> How is proving self study ability relevant to a job? Doesn't my resume of wildly varying projects and my ability to competently talk about them prove that? People usually trust their own assessment of a candidate much more than that of others. While your projects might help generate interest in you and get you an interview, the actual interview process is meant to be an assessment by the Company conducting the inte…

While your projects might help generate interest in you and get you an interview, the actual interview process is meant to be an assessment by the Company conducting the interview. So you shouldn't automatically assume you have the jobs simply based on your past projects alone.

That's insane. If you brought me in because you liked what's on my resume, your number one priority should be determining if I really did what I said I did. Your priority shouldn't be arbitrary, unrelated questions or coding challenges pulled off some website.

I'm not aware of any other industry that behaves like this.

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

#378

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…

Agreed. I wouldn't even mind so much if they picked "better for the job". So often, it seems like the criterion is "better at doing things that never actually come up in the job".

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

#379

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…

I got this CSV question at some nameless large company in the bay area.

I asked "Do you want me to do the simple thing, and use a library, or write code to do this?"

They preferred the latter. So I did.

As happy as it might make you to be snarky for the often silly questions you are asked, people are, if they are smart about it, looking to see your thought processes.

I recently got a question that I didn't know how to answer, so I started thinking through it aloud. I think they liked it, because they engaged with me during the process. Redirected my thought processes.

Again, good companies will do that. Look for every question, no matter how silly, as a way to show how you deal with situations, even ones you may not like. These are the moments for you to shine.

And after you get home, tell your SO/friends/etc. how wacky they are.

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

#380

Earlier quoted context omitted.

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…

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.

Post reply on HN