Live data from Hacker News

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

fuzzyblog.io

721–730 of 766 posts

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

#721

> no one actually believes that anyone can code. [..] When did an entire industry of people get pre-judged as lying? I've been hiring recently for a senior developer and I have had a dozen or more candidates not be able to explain composition and inheritance or the differences between an Object Oriented or Functional language. One person started describing how to define functions and another couldn't really explain i…

I agree with the idea of a certification program. Even a full-on curriculum. At the end, you walk away with something approved by the industry in general as something of value. Something that indicates "This person knows how to, bare minimum, fizzbuzz" or regex fizzbuzz with your choice of wording.

I'm trying to get opinions from developers (myself being one) on what kinds of things that kind of program would have to include. I'd love to hear some ideas if you have any.

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

#723
post #710

Earlier quoted context omitted.

Surely getting them to talk you through the code would solve that problem. If its is their own code it shouldn't be a problem. If it isn't their code and they can still talk you through it, even better - they have managed to understand code that someone else wrote which is probably an even more valuable skill.

You realize that your third second contradicts your first, right? And no, having somebody who's an energetic fraud on the team is poisonous. Having somebody who's so good at it that they're hard to catch is worse, not better.

If people are genuinely a fraud they won't be able to talk about the code in a sensible manner.

I didn't write the monstrosity that I am working on just now, but I could explain how it works and I know where to look to fix bugs. I don't know why some crappy design decisions were made. Does that make me a worse programmer than if I had written it myself? Is harder to understand someone else's code than stuff you have written yourself. There are far more jobs working on existing code bases than on new new projects.

(My guess is that you have never worked with anyone who has claimed ownership of someone else's code, have you?)

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

#724
post #722
post #655

Earlier quoted context omitted.

10 = 5 + 5 = 7 + 3

that's right... even prime isn't enough

Prime is ok if it’s multiplied (there is one and only one prime factorization of a number).... but that can get to absurdly large numbers.

Still, consider the word ‘abe’ with a = 2, b = 3, c = 5, d = 7 and e = 11.

abe would then be 2^1 * 3^1 * 5^0 * 7^0 * 11^1. ‘abba’ would be 2^2 * 3^2. Each anagram would have a distinct value.

See also Gödel numbering and FRACTRAN.

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

#725
post #550

Earlier quoted context omitted.

> Do you have 10 positions and 10 potential candidates? Hire all 10 folks, and fire the one bad person; your company will be better off for the decision. Much better off than it would be if you instead overwork your existing team because you haven't found your unicorn hires yet. Even if you hire two do-nothings and a negative-performing person (consumes half an FTE's day in questions), you still end up with 6.5 produ…

"For negative performing people, I usually give them something kind of busy-work that doesn't involve the rest of the team." Why waste time? Why not just fire them?

In my case, I do not have the authority to fire someone.

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

#726

Earlier quoted context omitted.

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

Screw it, everyone else is posting code examples: def vc(s): return len([c for c in s if c in ['a','e','i','o','u']])

Probably s.tolower() or whatever it is in Python.

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

#727
post #424

Earlier quoted context omitted.

After college, I was interviewing with the company I eventually ended up with. This was the second technical interview (and we eventually had a third). The very first question I was asked was to write a function that prints out a triangle like: . .. ... .... At the time I thought this was an attack to my honor. I literally felt terrible, and thought the interviewer was mocking me, for some reason. I also thought mayb…

no offset for the triangle, not too bad

[deleted]

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

#728

Senior level dev here (6+ years). My last job search was brutal. I aced my interviews but still got a lot of rejections. The feedback included * the team thinks you’re a great engineer, but you didn’t show enough excitement about the company * we think you’re a solid engineer but not quite at the senior level yet, it’s ok though, we reject 98% of our candidates * we do a lot of code story telling at our team (I kid y…

Code telling? What is that? I'm sorry about the job but that sounds hilarious.

It was stupid. They gave me a project to do and during the onsite I had to walk through the code in the project. I thought I was pretty thorough given the time constraint. I figured it was just a bad personality-fit and they had to make up something so they said "not a good code story teller".

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

#729

Earlier quoted context omitted.

Point number 2 doesn't really land for me. I can see how a dev of 10 years might never have needed to think about tuples, depending on what code she was responsible for. Some folks aren't really curious about deep internals, they care more about the bigger picture. Scalability, system maintainability, ease of deployment, monitoring, ease of iteration, etc. If pressed, they can dig in and understand the internals, but…

> Point number 2 doesn't really land for me. I can see how a dev of 10 years might never have needed to think about tuples, depending on what code she was responsible for. i'm sorry but i don't agree there. in this specific case, tuples and lists are really different and there's specific reasoning for using one or the other. it's a core feature for the language. it would be like saying someone that is a Java dev and…

Perhaps I come from a different land, but in my field, knowing a specific language intimately is not as important as knowing the wider scope of software engineering and distributed system design.

I'm not a developer who is down in the weeds optimizing specific algorithms though, and I can see how a mastery of language-specific data structures and how they are represented in memory might be required for such a person.

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

#730

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…

I noticed that quite a few programmers have the following attitude: If there is something (a programming language, framework, library, paradigm, design pattern, tool...) that they know and use, then they believe that familiarity with it is essential to call yourself "senior". On the other hand, if they do not use it, because they do not know it, they believe that it is useless and anyone studying it is just wasting their time. They may not be aware that this is the algorithm they are using to evaluate others.

Imagine a programming ecosystem with e.g. 5 approximately equally popular frameworks. Suppose that someone with this attitude is familiar with frameworks F1 and F2, but never used F3, F4, F5. Put such person in charge of an interview, where equally skilled candidates (i.e. knowing 2 of the 5 frameworks) apply. They will only classify 10% of them as "senior-level" (those knowing F1+F2), and additional 60% as "somewhere between junior and senior level" (those knowing one of F1,F2; and one of F3,F4,F5). So they would hire literally themselves, but probably not someone on the same level.

Post reply on HN