Offerzen article about high earning developers

[cguy]

It's not hand without its flaws; it is afterall the single underlying reason for the:

• billion dollar mistake
• flawed flavour of polymorphism
• unnecessary amount of structural complexity in codebases
• incapacity for testable code
• difficulties iro concurrency
• ...

It’s certainly not flawless, and C++ in particular will quite happily give a poor developer enough string to hang themselves with. Properly written OOP code has been instrumental in creating manageable and maintainable code for most of the largest and most inherently complex code bases in the world. It’s not just academic - underlying every construct is a practical concern, and knowing how to using it correctly is the most practical thing in the world.

 

[xrapidx]

I find I'm terrible with terminology unless i'm using it daily. I'm also terrible at articulating something - I work best locked in a dark room, alone.

 

[[)roi(]]

It’s certainly not flawless, and C++ in particular will quite happily give a poor developer enough string to hang themselves with. Properly written OOP code has been instrumental in creating manageable and maintainable code for most of the largest and most inherently complex code bases in the world. It’s not just academic - underlying every construct is a practical concern, and knowing how to using it correctly is the most practical thing in the world.

Nothing that we have really is, hence you'll see that the addition I made to my post, references a statement from Alan Kay earlier this year in preparation for his talk at the CurryOn functional conference; his conclusion is short and sweet:

So: both OOP and functional computation can be completely compatible (and should be!)

The issue is of course that some programmers are as equally anti change as they are for any terminology and abstraction that lies outside of their current comfort zones. Hence I similarly find it strange that there is so much pushback not only against the new or orthogonally different; but so too the false dichotomy that an understanding of terminology and abstractions is secondary in productive coding.

 

[[)roi(]]

I find I'm terrible with terminology unless i'm using it daily. I'm also terrible at articulating something - I work best locked in a dark room, alone.

It's not quite that simple is it?
Writing code is an order of magnitude easier than maintaining it; so unless you're the only one who'll ever work on a codebase it not so simple to just say communication of ideas is secondary to progress.

 

[animal531]

I'm not picking on you guys, the point I was trying to make is that you can have a junior dev just fresh off a 2 week course that has learned all the theory vs a senior dev that knows his stuff (albeit possibly in a limited domain as cguy says). In this case it'll be the junior that passes your theory questions, not the senior. The senior may have a ton of other expert and business knowledge that could be useful to you, but that you've just ignored.

The interview process should be about what you need from them for the role you're recruiting for, and how the interviewee can fill that role. Does it for example need a ton of ML experience? Sure, then ask them about their ML experience, but explore it from their side, not from your rote list of what you think ML comprises. After that explore what else they know and/or are into.

The same goes for any other technology.

 

[_kabal_]

"senior" developers exist because "senior" developers interview them.

I like to start with a "talk to me about this code. how would you refactor it?". I can tell within a minute if they are Real Senior™

How you are able to articulate things is a huge indicator, even if you don't know anything about it.

If you asked me how to "invert a binary tree", I have no clue ,but I can sure as hell have a meaningful discussion about it, assuming the interviewer actually knows what they are talking about

 

[smg22]

I didn't even bother asking him if he knew what a stackoverflow exception is.

He probably was gonna tell you it's an alternative to google.

 

[CamiKaze]

Value vs ref type is first year stuff. There's nothing arb about asking a guy who claims to be an expert in a language about the features of a language. Same goes for simple SQL questions.

I stand by my point - if you can't answer most of those it's a good indicator that you've got many years of mediocre experience. You are not a senior developer

You make a valid point, but i see that in this thread, we are also leaving out the possibility of people that can talk the talk but not walk the walk.
If people can answer questions about the difference between value type, reference type, thread safety, etc (where they googled the definition the previous night) then they get the job and you are still stuck with a useless case that can't walk the walk.

Hell, there are people in my company that are getting promotions for doing admin work like booking meeting rooms for other departments of the organisation, but if you ask them to sort an Array then they run to google.

 

[smg22]

"senior" developers exist because "senior" developers interview them.

I like to start with a "talk to me about this code. how would you refactor it?". I can tell within a minute if they are Real Senior™

How you are able to articulate things is a huge indicator, even if you don't know anything about it.

If you asked me how to "invert a binary tree", I have no clue ,but I can sure as hell have a meaningful discussion about it, assuming the interviewer actually knows what they are talking about

When going to an interview I prefer that approach as well, not everyone is brilliant in knowing exact explanations for terms. I think development interviews should be flexible in a way that the interviewee is not restricted to answer according to the interviewers requirements.

 

[cguy]

I'm not picking on you guys, the point I was trying to make is that you can have a junior dev just fresh off a 2 week course that has learned all the theory vs a senior dev that knows his stuff (albeit possibly in a limited domain as cguy says). In this case it'll be the junior that passes your theory questions, not the senior. The senior may have a ton of other expert and business knowledge that could be useful to you, but that you've just ignored.

If people can answer questions about the difference between value type, reference type, thread safety, etc (where they googled the definition the previous night) then they get the job and you are still stuck with a useless case that can't walk the walk.

Just to be clear, I (and I am pretty certain [MENTION=17702]Hamster[/MENTION], too) was talking about necessary conditions for a senior developer to pass an interview, not sufficiency. If someone shows up for a driving test, and doesn't know what a steering wheel is, one should send them on their merry way, however, knowing what a steering wheel is, doesn't mean that you can drive, and we certainly don't think it does.

The actual interview we typically give is an extensive, and a coordinated effort from multiple (up to 8) people with different types of specialties and experience. Everyone who interviews a senior developer has typically given over 1000 interviews (I've given between 2000-3000).

 

[Hamster]

I'm still baffled that people think value vs ref types, constructors, lambdas and access modifiers is "theory".

 

[biometrics]

I'm still baffled that people think value vs ref types, constructors, lambdas and access modifiers is "theory".

So glad I'm not dealing with you corporate drones.

 

[[)roi(]]

I'm not picking on you guys, the point I was trying to make is that you can have a junior dev just fresh off a 2 week course that has learned all the theory vs a senior dev that knows his stuff (albeit possibly in a limited domain as cguy says). In this case it'll be the junior that passes your theory questions, not the senior. The senior may have a ton of other expert and business knowledge that could be useful to you, but that you've just ignored.

It should be a given that what differentiates a senior dev from junior is a level of mastery and / or specialisation that cannot be simply studied for in the week prior to the interview. With that in mind I'd expect anyone trying to masquerade as a "senior dev" to be stumped by the first question that couldn't be found in a typical "how to prepare for an X language interview" book, blog post and/or video.

As for terminology and abstractions; for a senior dev a lack of understanding is surely is not something that can be simply be ignored, because really what's the likelihood that for example a senior dev who can't explain the differences between:

• adhoc polymorphism
• parametric polymorphism
• subtype polymorphism / inclusion polymorphism

...would have mastered generic programming let alone more complex polymorphic abstractions -- more so how effective would such a senior dev be in a team with junior programmers when there's minimal to no ability to reason about code in terms of terminology and the abstractions it employs.

 

[Hamster]

So glad I'm not dealing with you corporate drones.

Erm...not working at a corporate. Small team, multiple releases a day, no CAB meetings....

In fact, some of the more prestigious corporates care more about you being a culture fit than whether or not you can code. 5+ interviews over a month and no real tech questions.

 

[[)roi(]]

I'm still baffled that people think value vs ref types, constructors, lambdas and access modifiers is "theory".

Exactly... imagine a heart surgeon that couldn't explain what a pericardial tamponade is; would you trust him to fix it?


Side note: this also reminds of a guy who in that last few weeks has been posting up a storm on a language evolution thread focused on the merits of adding higher-kinded polymorphism. The painful part is that whilst he insisted he was OOP "specialist", he clearly didn't have the most basic understanding of generics, let alone the added complexity and affordances of higher-kinded types (~"generics on generics").

 

[biometrics]

Erm...not working at a corporate. Small team, multiple releases a day, no CAB meetings....

In fact, some of the more prestigious corporates care more about you being a culture fit than whether or not you can code. 5+ interviews over a month and no real tech questions.

So you're looking for a new job? So much for that.

 

[Hamster]

So you're looking for a new job? So much for that.

My wife went through it....geez dude

 

[_kabal_]

I'm still baffled that people think value vs ref types, constructors, lambdas and access modifiers is "theory".

Meh, all you need is a 6 month bootcamp.... #FullStackz

Joking aside, you mentioned culture. I would say this is probably our number one criteria. Morals, work ethic, will to learn and teach, etc. Don’t really want brilliant *******s working with us.

 

[[)roi(]]

Joking aside, you mentioned culture. I would say this is probably our number one criteria. Morals, work ethic, will to learn and teach, etc. Don’t really want brilliant *******s working with us.

How ever do you achieve the teach part if nobody's a brilliant *******s. Joke's aside how exactly do you quantify a culture match in an interview? psychometric testing?

 

[crackersa]

Is offerzen only for South Africa?