HackerTrans
TopNewTrendsCommentsPastAskShowJobs

HervalFreire

no profile record

comments

HervalFreire
·3년 전·discuss
>May I ask, why does this seem to matter so much to you? If you are a bootcamp graduate yourself, that doesn't preclude you from being a good engineer. I am more than happy to believe you are the one-in-a-thousand counter-example.

I'm not a bootcamp graduate engineer. I'm actually quite good at what I do, interviewing (from both sides) and engineering. This topic matters to me because I like to argue online and I have strong opinions.

It's common for people to manipulate their perception of reality to justify their own situation, I assure you I am not doing that here, however I think you are doing this.

>>What I'm saying is that the market is flooded with these false negatives.

>Understood.

A false negative is someone who is GOOD, but appears bad. He is a negative but that assignment is false. I am saying the market is flooded with capable engineers that are good but appear bad due to interview processes and biases. Hence the term false negative.

>Do you have me confused with the other guy?

Nope you guys touched on similar points. You never mentioned syntax, but you're likely testing on algorithms so it's the same result. You get a ton of false negatives. You pay a premium for the guy who does better at the interview when you can get someone who's just as capable at a much lower cost.

The point is someone will hire those false negatives at a cheaper price and that effects the whole market. Companies hire the best they can get.

>Agreed, but that's not how we interview.

That's why a certain segment of the market looks like there's a dearth of people. It's because the interview clouds your perception. You interview the wrong way, you agree. The contradiction here is that although most people like you agree, you still reject people based off the SAME results as the WRONG interview AND you think the rejection is accurate.

That's how the psychology works. Everyone I talk to agrees interviewing is wrong overall but when they use it to judge on individual candidates they think it's accurate.

The contradiction exists even in your own reply. You agree the interview process you use is screwed yet you're really confident about your judgement of the market even though your measurement methodology is SELF admitted to be wrong. It renders your entire argument into question.
HervalFreire
·3년 전·discuss
Hold on. Of course you want to avoid terrible candidates. But brain teaser questions and asking gotcha questions about obscure python syntax or something like that isn't a good correlative indicator. You get a bunch of false negatives this way... people who are good but not good at interviews.

You have to give them some take home exercise. That's the best way to determine if they're not a false negative. Unfortunately many good devs just don't have the time to do a takehome.

Did you hire a candidate who say... didn't know what MRO was, but created a stellar result for a take home project?

What I'm saying is that the market is flooded with these false negatives.
HervalFreire
·3년 전·discuss
[flagged]
HervalFreire
·3년 전·discuss
>Isn't all programming just syntactical tricks?

No. The decorator is really just a syntactic shortcut. There are other facilities in python to do the same thing. The decorator is just a convenient way of doing it. The concept at hand is a function that takes a function and returns a new function. Nothing crazy here.

  decorator: Callable[[Callable[[Any]. Any]], Callable[[Any], Any]] = lambda x: (lambda y: x(y)) #does nothing
  g: Callable[[Any], Any] = lambda x: x #identity func
  decorated_g: Callable[[Any], Any] = decorator(g) #decorator that does nothing to identity returns identity func   
You see? You can just call the function and assign the result to a var and that var is a decorated function. The facility exists, the @ symbol is simply a convenience so you can execute it in the declaration step.

>We have a fundamentally different view of these things. Mine is serving me well. Yours isn't challenging mine.

Exactly see. Just because my view is "better" or more "modern" you still function fine within your role which is my point. Someone could have knowledge far superior to a person with 2 years of experience, functionally speaking, it doesn't matter too much. You still do "fine" at your role. Your view serves you well in the capacity of a "senior" engineer" even though your view points are ultimately wrong and inferior they still work well enough.

Also it isn't a viewpoint. Two of the newest languages to hit the mainstream have eschewed inheritance completely from their syntax. Neither Golang or Rust have the concept. Both use interfaces exclusively to promote the concept of similar types. No inheritance anywhere. I have tons of evidence on this even papers, quotations from prominent people. It's a well known fact inheritance is outdated.

We can agree to disagree, but it's like agreeing to disagree with a child who doesn't know any better. Sure.
HervalFreire
·3년 전·discuss
If we're just talking about the python stack arguably there's not much else on top of it. You get the extra stuff through osmosis in the same 1 - 2 years. The applications for python aren't wide ranging enough to include much else unless you're thinking about data science and ML stuff.
HervalFreire
·3년 전·discuss
Makes sense.
HervalFreire
·3년 전·discuss
>There's also plenty of Python developers two years in (that I've interviewed and rejected) who couldn't write me a decorator or explain MRO.

First off both MRO and decorators can be learned in 1 week max by anyone. And one week is REALLY forgiving. Literally. You have to be mentally deficient not to be able to learn it. They simply didn't encounter the python feature in their experience. You would just reject them for not knowing about those features?

Second off decorators are syntactical tricks. You can get around python without ever using them. If you encounter them in libraries you just need to know what they do at a high level, you don't need to know how to implement them. If you ever do need to implement one just look it up. I don't judge people for not knowing syntactic tricks.

Third, MRO is something that should be not heavily used at all. You should avoid inheritance as much as possible. Additionally you should avoid double inheritance all together. The MRO/inheritance concept is a left over thing from an outdated programming style. At most you should know inheritance, and at most have one level of it if you must and try to use interfaces instead. Nowadays I expect only to see inheritance in existing libraries/tech debt and not newly written code from senior programmers. If someone encounters MRO issues, again, I just expect them to look it up.

I'll actually judge someone who expects others to know MRO given how outdated it is. I won't think they're stupid, or I won't not hire them or anything like that. I just know they aren't up to date with the current methodology but they can easily learn it if needed.

Overall, you're just setting a high bar artificially. It's like hiring janitors who only have phds in chemistry to know what's in the cleaning chemicals.

> Yes but the same timeline can be done for C, C#, Java or anything else.

No Java and C# languages are complex enough that it can be done in a 2 year timeline but these languages are hard enough that they are in a different class then python. C with memory management is harder then both java and C#. Memory management simply isn't intuitive.
HervalFreire
·3년 전·discuss
>I think the point you're missing is that senior engs in Meta do not just write code. Some of the senior engs almost do not write code at all. They design systems and move complex projects forward

I think your getting off on a different topic. Those guys aren't engineers anymore right? They're more technical managers; or architects.

>So yea, deep language knowledge, while an excellent skill, is not something that defines a senior eng (at least in Meta and I presume in similar FAANG companies).

I agree with this, but this is not what the others are talking about. The topic right now is about python developers. The more wider range role you're talking about here isn't a person with the title "Senior python software developer." Meta likely doesn't have that title.

Additionally, if a company works purely within the python ecosystem of web development, the "architecture" actually doesn't get too complex. Most of this stuff is trivial too, I give it an additional year to learn it.

If you're doing stuff with shared memory and utlra low latency applications then it's a completely different scenario, but you wouldn't be working in python if you had that requirement.
HervalFreire
·3년 전·discuss
>But to your point, there is a flood of bad candidates.

How would you know did you hire these candidates to find out? Or did you dismiss them as bad because they didn't pass some brain teaser algorithm interview?

Those candidates go on to get hired at companies with a lower bar for lower salaries and those lower salaries do influence the market.
HervalFreire
·3년 전·discuss
> I hire 10+ Python developers per year. You're wrong.

I've been hiring roughly the same amount for 10 years. I'm actually really extremely good at modern python. My skills with python syntax are so good that I can do in 1 line exclusively with generators what a junior programmer probably needs 10 lines and twice as much mutating state to pull off. My code is also likely more modular and neater then a junior but you have to realize none of this matters that much. My skill level with python is beyond the curve of what is necessary and so is any other developer that goes beyond 2 years with python.

In the end every programmer I ever hired exclusively for python will hit this tier within 1 or 2 years, very few exceptions. Roughly half of the junior programmers I hire are actually already within this tier upon getting hired. Literally before hitting there first job. After two years the only thing left to pick up are some more unique patterns and tricks but that's it.

I am 100% talking from experience.
HervalFreire
·3년 전·discuss
Let me spell it out. A junior dev is 1 or 2 years of experience away from a senior dev for python.

For C++ it takes probably 4 or 5 years.

This is not nonsense. This is real.
HervalFreire
·3년 전·discuss
This^ is true. Arguably though the majority of web development doesn't involve the stuff you mention. Developers simply work within a framework. This Linux stuff is relegated to specialists... devops or security engineers.
HervalFreire
·3년 전·discuss
> As someone who runs a team of Python developers, and has been a professional Python developer for 15+ years, you sound like you don't know what you're talking about.

As someone who's done 20 years of professional C++ development along with 15 years of professional python development, as well as 10 years of professional javascript/react development on a systems that go across the stack from the lowest level of sensors and embedded systems to the browser front end I know what I'm talking about.

I've also done rust, go, erlang, java, and I've also done a ton of haskell as well as lisp. I've been all over the place likely more than you.

>The difference between a junior and senior developer has nothing to do with the language. Regardless of the language the engineering fundamentals are the same.

This is beyond wrong. You've done C, you've done rust, then you must know that the fundamentals of systems programming is much more wider ranging then python. What's a pointer? What's a unique pointer or shared pointer? What's move semantics? What's the difference between stack allocation and heap allocation? What's an R value vs. L value? What's a borrowed value? What's virtual memory? What's an interface (arguably with the advent of annotations types are not more relevant in python but there is huge class of senior python programmers who don't use types)

The above are programming fundamentals that a python programmer never needs to know. A python programmer can go from junior to principal and not need to KNOW any of the above simply because python abstracts these concepts away from the user. The fact that a python programmer doesn't need to know any of these things makes it significantly easier. For web apps a company is most efficient if they hire a mid level python developer over some principle python developer with 10 years of experience.

This is not the case for a language like C++
HervalFreire
·3년 전·discuss
Nobody gets salary cuts. What happens is that devs get laid off then companies hire at lower salaries.

This is indeed what is happening right now.
HervalFreire
·3년 전·discuss
They do qualify. Boot camps generate a lot of noise but there is no doubt that out of that noise there are a lot of good candidates that significantly increase supply by a non trivial margin. Not seeing this is denying reality.

People who can actually engineer in python is becoming more and more common place.
HervalFreire
·3년 전·discuss
Many senior devs over the last decade have been created by boot camps. With the recent lay offs the over supply is becoming more apparent. It is now really easy to hire senior python devs.

Arguably python is so easy that junior devs aren't that far off from senior devs.
HervalFreire
·3년 전·discuss
No. Only niche skills. Python and basic web dev is becoming common place. Supply given boot camps and lack of credentialism and the ease of learning software dev has increased by a lot.

These layoffs don't happen in a really hot market.