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

301–310 of 766 posts

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

#301

Post by exelius »

slgeorge wrote: post #266
exelius wrote: post #230

Yeah, the entire HR process at most companies is so incredibly broken for technical candidates. One of the problems IMO is that HR doesn’t know shit about tech, and dev managers don’t know shit about HR. A dev manager who needs a person tells HR “I want to interview 10 people for this open job req” — which is likely just some bullets vaguely describing job responsibilities. HR, having very little idea what any of the…

> "HR doesn’t know shit about tech, and dev managers don’t know shit about HR" This is the cause of a significant amount of waste, friction and general anger for both sides in my experience. Technologists are well-known for their TLA's, and HR teams have their own obfuscating discipline-specific terminology, assumptions and values. The incentives for external recruiters are obviously a problem and even for internal r…

Right to all of these; which is why you have to make it the hiring manager’s job to be very involved with the process. HR should be involved for governance purposes, but the manager and the team need to be involved with hiring new team members.

Part of the problem is that no matter how careful you are, it seems whenever you bring in 10 candidates to interview, 1 is obviously overqualified and has higher salary expectations than you can offer, 2 are about right (but likely also have other offers), and the other 7 are varying shades of “sorry, not right now...” to “why did we even let you in the building?”

It’s entirely normal to interview 10 candidates, make 2 offers, and get no accepts. That’s a huge waste of time on everyone’s behalf. But I have yet to see anyone find a way to significantly improve on this process, because as the OP states, everyone figures out to just start googling the answers to the questions.

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

#302

Post by softawre »

eanzenberg wrote: post #234
cortesoft wrote: post #149

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…

I think that is the point. If your business relies on importing csvs that cannot be imported with pandas then explain that, explain the edge cases where pandas has failed, and I will understand. If your business relies on having the best fucking palindrome product then that becomes super relevant. They can definitely ask a complicated problem. On-sites are 4 hours long these days.

You sound like somebody who would derail all of the technical discussions and pat himself on the back for it because he was "technically correct" while still missing the point altogether.

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

#303

Post by lainga »

hermitdev wrote: post #167
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…

Also, expectations of coding tests should be upfront. E.g. we're looking for the most optimal solution, not the one that is most convient. I was declined for a position at a trading shop for a C# backend role because I used linq to do something. I didn't have unlimited time for the tests, so I went with expedient over performant, for which they did not care. Fuck that, set clear expectations for interview "tests".

Were you able to talk to them and ask questions during the test?

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

#304

Post by mindhash »

seanmcdirmid wrote: post #197
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…

Would it be better to have the interviewer provide take home context a few days before the interview that will be related to the coding problems during the interview? Somewhere between the take home coding problem and the whimsical toy problem solving by during the interview?

I usually like sending take home assignment for graduates.And having a discussion about the approach taken, and do a peer programming session to add features.

However, don't see how well take home can work for senior engineers. In fact, its unfair and delays interview process to expect take home assignments from working folks.

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

#305

Post by twodave »

ryanianian wrote: post #254
twodave wrote: post #83

Earlier quoted context omitted.

I'm not going to speak to the homework type of problem (because honestly I think you should be paid for that sort of thing), but I always ask people programming questions in on-site interviews, not strictly because I want them to prove they can program (although that's one useful side-effect), but because I want to observe the candidate's problem-solving process. I can't deduce anything like that from your Github or…

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…

I want to know how resourceful the candidate is, how quickly they make mental leaps and whether they'll play nicely with others in the team under the context of the work we're trying to get done. If the choices are a) find out first-hand by (gasp) asking for a demonstration of skill while I watch or b) try to decipher these things by shaking a tuning rod at their GH repository--then I guess we'll have to agree to disagree :)

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

#306

Post by jaggederest »

d1zzy wrote: post #250
vthallam wrote: post #122

Earlier quoted context omitted.

Or you could do top 100 questions on leetcode or hackerrank and you would have solved the question in a minute. It's kinda sad that you could remember the top 100 solutions and clear interviews in almost all big tech companies.

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"

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

#307

Post by munchbunny »

s2g wrote: post #92
octorian wrote: post #58

Earlier quoted context omitted.

> ...who nodded gravely as the CEO talked about the desperate shortage of software developers. This comment is exactly why reading about "interview gymnastics" like this really pisses me off. Its also why I wonder how many big tech companies are somehow able to hire so many people... With processes like these, you'd think that they either have a "secret backdoor" or never managed to actually hire more than a dozen or…

Volume. Huge volume. Google has a completely broken interview process, to the point where they pretty much brag about how ridiculous their false negative rate is, but they make up for it on volume. When people will throw themselves at you two or three times in hope of getting that lucky set of algorithm wankery questions that they can answer, then you will keep interviewing like that.

I'm not so certain that Google's process is more broken than anyone else's. The thing the giant companies have going for them is that they tend to be more consistent, so at least you can get a good sense of what they'll ask, how to prepare, and how they're measuring you.

With small companies, it often comes down to "were you charming enough?" They won't admit it, but it's a clear subconscious bias.

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

#308

Post by notyourloops »

spamizbad wrote: post #175
notyourloops wrote: post #145

Earlier quoted context omitted.

What's your process like after that screening measure? Because to me, that's honestly trivial, and a lot nicer than dealing with an extended (8+ hours) homework problem as an introduction to a company's hiring process.

A ~4 hour on-site (or google hangout) technical interview and discussion. The first 30-45 minutes is usually us selling you on the company, followed by 2-3 hours of technical stuff. We do throw a few more coding questions at you (ones that are technically trivial, but made more difficult with interview jitters etc), but go beyond that and ask how would you design an API, how would you think about the technical requir…

That sounds like a nice process. I don't know anything about your company, but I'm thankful that you keep it sane and reasonable for prospective developers.

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

#309

Post by zimou13 »

munchbunny wrote: post #300
cema wrote: post #89

Earlier quoted context omitted.

Quote: a large majority of candidates lie on their resumes Is it really true? I do not think it has been my experience (some, but not the majority).

I've definitely seen people stretching the truth to various degrees. I do it too, because you're in for unnecessary difficulty getting past the recruiter screen if you don't do _some_ spinning. The key is to only stretch it to the extent that you can explain your background in detail to the hiring manager and be able to openly admit where you don't know much if those areas come up. Generally speaking a hiring manager…

Having a plan to write a postmortem once a job is landed might actually be useful, since it forces seekers to track their data, analyze the results of what they did, and carefully consider what they could have done better. see: https://luckypatcher.pro/ https://kodi.software/ https://showbox.software/

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

#310

Post by ChuckMcM »

cableshaft wrote: post #90
ChuckMcM wrote: post #33

I find the coding thing interesting as well, in part because there is coding and there is coding. I suspect it is the difference between "coding ability" and "coding fluency." In the former a candidate can apply known patterns of a give language to a problem and with just a few searches on StackOverflow get it working. A person who has code fluency can create the algorithm in the language of your choice, pretty much…

> A person who has code fluency can create the algorithm in the language of your choice, pretty much on the spot. I've professionally used each for a year or more C#, Python, Javascript, Objective-C, Java, PHP, Visual Basic, and ActionScript over the years. But if you asked me to write a function in anything but the first three languages, I will almost undoubtedly stumble a bit in producing them (hell, I still have t…

> I've professionally used each for a year or more C#, Python, Javascript, Objective-C, Java, PHP, Visual Basic, and ActionScript over the years. But if you asked me to write a function in anything but the first three languages, I will almost undoubtedly stumble a bit in producing them (hell, I still have to look up syntax for Python periodically).

It is for exactly this reason that if I'm interviewing you and want to know if you can code or not I will ask you to write up an algorithm rather than a program. I might say, "Show me the algorithm for locating a node in a binary tree, now do the same for a hash table. Now how would you insert into each of those?" And then, as many programming languages do, I try to tie one of your hands behind your back, "Ok so the language you're going to use doesn't have pointers" or "memory allocation" etc.

But I only interview that way because I see computer programming languages as an impediment to expressing what you really want the computer to do. And people who can code, first and foremost understand exactly what needs to be true for the code to work, then when they run into limitations of the language figure out ways to express those same concepts given the limitations.

If you were being mean you could add limitation after limitation until you were down to a minimally touring complete system. And if they can still make it do what you're asking, then they really deeply understand how to get computers to do what ever they want them to do.

I agree with every criticism that "coding tests" should not be about whether or not your syntax is accurate or you have the standard library memorized. I explained to a colleague at Google once that having total mastery of English grammar doesn't make you a writer.

I wouldn't think you incompetent if you didn't have the syntax at your fingertips.

But here is the rub, if the interviewer doesn't know how to code they can't reliably test for that ability in others. When I hear or read stories like yours I wonder about who the company has put in charge of interviewing these candidates and what biases are they bringing to the situation.

Post reply on HN