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

451–460 of 766 posts

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

#451

Post by irundebian »

luch wrote: post #141
ryandrake wrote: post #82

Earlier quoted context omitted.

It's such a weird hiring market. 1. There are a lot of imposters out there applying for programming jobs who can't program, and 2. There are a lot of very talented programmers out there who are being rejected by overly picky companies. Both can be true, and I'd argue that both are true. I don't know what the solution is. Current interviewing methods don't seem to be solving the problem. I'd suggest a widely-accepted…

certifications are plentiful in the infosec sector. They absolutely do not solve the hiring problem.

I agree, but in theory that can mean that we haven't found good certifications yet.

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

#452

Post by irundebian »

AnimalMuppet wrote: post #437
ryandrake wrote: post #82

Earlier quoted context omitted.

It's such a weird hiring market. 1. There are a lot of imposters out there applying for programming jobs who can't program, and 2. There are a lot of very talented programmers out there who are being rejected by overly picky companies. Both can be true, and I'd argue that both are true. I don't know what the solution is. Current interviewing methods don't seem to be solving the problem. I'd suggest a widely-accepted…

That might solve half of the problem. But then we need certifications for employers - something that says, "Yes, I have a real job opening; I'm not just wasting your time." It needs to have real penalties if an employer violates it, too.

I'm not sure this is working, since employers not only search for general software developers but maybe also developers with domain-specific knowledge. It would be very time consuming develop a certification for every domain.

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

#453

Post by amag »

Balgair wrote: post #330
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…

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…

That would still not level the playing field for several reasons:

1) Some people may find Fortran easier to understand than others even if they haven't touched it before. This was the case when my University decided to use Haskell* as the first language to teach students in order to level the playing field. It did help somewhat, it leveled the field for those with little and those without any prior programming knowledge. But to those who had already come to terms with recursion etc it was a very tiny stumbling block.

2) Some people need to dive deeper and gain a greater understanding of things before they feel at ease using them, but once they have reached that level, they will often outperform most other people.

* This was 20+ yrs ago and Haskell was not so well known back then.

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

#454

Post by eecc »

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.

I guess the numbers should be primes... 4+1=3+2

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

#455

Post by jmagoon »

efields wrote: post #185
busterarm wrote: post #108

Earlier quoted context omitted.

I'm a "Ruby engineer" but tend to avoid Rails teams because most of those large Rails apps are a giant pile of technical debt. They're looking to hire senior talent to clean up the mess but aren't willing to make the organizational commitments needed to make that effort succeed. No thanks. Edit: My 'favorite' experience was the few months of consulting work I did with a team building Rails apps to deal with medical r…

I'm in the midst of maintaining/fixing one of those and I find it a great opportunity if you A) want to learn outside your comfort zone, B) enjoy figuring out problems that aren't just technical (talking to people, design, organization), C) want to get out of a coding-grind lifestyle. Our organizational structure isn't immutable, it just moves slowly. After about a year, my team's effort resulted in measurable improv…

That sounds really fun. I've done greenfield Rails projects and I've learned that what I really like and find rewarding is this kind of slow reorganization of something that already exists. It's like remodeling a house--maybe it was well built initially (and maybe not!), but you get to spend a lot of time inside of someone else's mind. You know, when they had good days and things just clicked, when shit was on fire and they just had to make it work. The results of seeing meaningful improvements to something like that is just fantastic, to the point where you're now excited to add on to the codebase.

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

#456

Post by irundebian »

hermitdev wrote: post #176
crdoconnor wrote: post #55

Earlier quoted context omitted.

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.

I remember interviewing a candidate that didnt even know what a binary tree was (context was big-O complexity of algorithms). That interview was really bad. Left the candidate in tears (which was not intended, but I think of their realization they werent going to get the job), and me annoyed at the waste of my time (should have been caught in phone screen instead of on site).

At least, for sure I know I wouldn't hire you as a recruiter.

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

#457

Post by khedoros1 »

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…

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

How about "Google is giving tests in these 25 languages"? They could even choose languages that are purposefully dissimilar from any language that you've claimed familiarity with.

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

#458

Post by hoorayimhelping »

falcolas wrote: post #223

I have a theory of why most of these changes in the job hunt came about: people became afraid of firing. I further theorize that this is an indirect consequence of primarily technical folks filling management roles. How does a fear of firing impact hiring procedures? If you are afraid of firing, you're afraid that you won't be able to get rid of a toxic individual; that a single individual will act as a poison to the…

I agree that it's related to firing, but I don't think it's fear of interpersonal drama.

The simple explanation is that it's really expensive to fire someone without cause. It takes months because the company has to produce a paper trail proving they fired the person for a valid reason to protect themselves from litigation. That's months of paying an individual who may be incompetent or toxic, months of paying people who put together the paper trail, all the morale damage the individual causes, the damage that might arise from firing someone, even if it's someone no one really liked.

All of those things are costly, probably much more costly than not hiring the right candidate. At least so the reasoning goes.

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

#459

Post by mywittyname »

pfarrell wrote: post #361
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…

"That guy didn't have 20 years of experience with db2... He had 2 years of experience, 10 times." One of my mentors said that about an interview he conducted a while back. I found a lot of truth in that line. I run my tech interviews by starting very green and let the candidate dictate how fast I ramp it up. I've gotten pushback from managers before that you can't start with basic questions, but I've equally gotten p…

This is a brilliant approach because everyone has more context, meaning answers can be more pointed and exact. When the questions start small and build incrementally the next topic of conversation becomes much more natural. The candidate knows that they can use a technique because it's already been discussed and the interviewer is has more control over the flow because there are fewer tangential topics.

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

#460

Post by 1812Overture »

spamizbad wrote: post #133
haskellandchill wrote: post #68

Earlier quoted context omitted.

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

I applied for an analytics position that unexpectedly had me take a Python coding test like this (I know a bit of PHP and Java but no Python) and I was able to google everything I needed to pass the test in the time limit. Apparently I got one of the higher scores too. Got the job. It has not required me to write a single line of Python, lol.
Post reply on HN