Offerzen article about high earning developers

[Suspect99]

Can you explain what an interface, inheritance and method overriding is?

See thats the thing. I'm an engineer, I last did "serious" coding in varsity in 2011. Haven't done much since then. I can answer those questions. But if you ask me to code something in C++ or Java/or whatever now... I dunno if I'll be able to do it. Its not needed for the job I'm doing now. I'd be able to pick it up again probably

But seems like some devs cant answer the question.

So how helpful is being able to answer technical questions like that in a job interview? How does it indicate the employees work performance

 

[Hamster]

See thats the thing. I'm an engineer, I last did "serious" coding in varsity in 2011. Haven't done much since then. I can answer those questions. But if you ask me to code something in C++ or Java/or whatever now... I dunno if I'll be able to do it. Its not needed for the job I'm doing now. I'd be able to pick it up again probably

But seems like some devs cant answer the question.

So how helpful is being able to answer technical questions like that in a job interview? How does it indicate the employees work performance

I senior developer should be able to me what the difference between value and reference types are, talk to me about thread safety etc.

If you tell me you are a senior C# developer and you cannot tell me whether the static constructor or instance constructor executes first or what a sealed class is, or
if you are senior Java developer and you don't know the super class' constructor will be called implicitly by the subclass,
or
inner join vs left join, pros and cons of an index on a database table

In fact, just last week I had a guy with 10+ years experience tell me he can't give me textbook answers when I asked him the difference between value and reference types. I didn't even bother asking him if he knew what a stackoverflow exception is.

Point is, if you consider yourself a senior developer and you cannot answer questions like the above or at least try and get close then what type of senior developer are you really? A Visual Studio Developer? All those questions are relevant in your daily coding life. There's nothing "text book" about them.

No offence to anybody here but the struggle to find people worth the money they ask is real.

 

[schuits]

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

Is that where you try goto stackoverflow to see how to implement a constructor and chrome throws a "aww snap" exception?

(oh no I used a goto)

 

[Hamster]

 

[Suspect99]

I senior developer should be able to me what the difference between value and reference types are, talk to me about thread safety etc.

If you tell me you are a senior C# developer and you cannot tell me whether the static constructor or instance constructor executes first or what a sealed class is, or
if you are senior Java developer and you don't know the super class' constructor will be called implicitly by the subclass,
or
inner join vs left join, pros and cons of an index on a database table

In fact, just last week I had a guy with 10+ years experience tell me he can't give me textbook answers when I asked him the difference between value and reference types. I didn't even bother asking him if he knew what a stackoverflow exception is.

Point is, if you consider yourself a senior developer and you cannot answer questions like the above or at least try and get close then what type of senior developer are you really? A Visual Studio Developer? All those questions are relevant in your daily coding life. There's nothing "text book" about them.

No offence to anybody here but the struggle to find people worth the money they ask is real.

point taken.

I just find it strange the people who code for their daily job and seem to be doing well, but can't answer theory questions

 

[Barbarian Conan]

Constructors, lambdas, abstract functions.... they're about as academic as a for loop.

I had a slow moment right now and couldn't remember what a abstract function is, but after googling I knew what it was.
A nice thing to do in an interview would be to tell them what it is if they can't remember and ask why it would be used.
I find the why is usually more important than the what.

 

[ArtyLoop]

Constructors, lambdas, abstract functions.... they're about as academic as a for loop.

Clearly
However..
When it comes to stuff like interfaces, and the SQL stuff then there's no excuse really. I know why we use indexes, the limitations thereof, and of course why we use joins.

I have been in the situation where I've been asked these things and showed them how to do it in code and why. But because it wasn't the university answer.. boom... no latte for you.

I came from the low level C foundation... and I worked on C++ code where the whole purpose of OOP was a moot point. They created classes by the bucketful, only to override MOST of them not to mention the things they were inheriting from the classes, and we had to live with the bloat of it and poor performance until I ported all that shyte to a more modern language.

So clearly OOP is a double-edged sword and I avoid it where I can. Because if you go down that rabbit hole you can confuse the shyte out of yourself for years. Kind of explains the plethora of crap software we've seen at specific times during the years.

 

[xrapidx]

High salary also has a lot to do with luck, finding the right company, at the right time. Once you have a decent salary, you tend to stay on a decent salary.

I've interviewed tons of people - and the HR side always offers them x% higher than what they're currently getting - so if you come in low - you usually stay low. (same goes for the interviews I've gone for (2) )

I don't think I'd be earning what I earn now if it wasn't for my previous company 11+ years ago - I've interviewed people more skilled than myself earning half of what I do.

 

[animal531]

...
Point is, if you consider yourself a senior developer and you cannot answer questions like the above or at least try and get close then what type of senior developer are you really? A Visual Studio Developer? All those questions are relevant in your daily coding life. There's nothing "text book" about them.

....

I disagree with almost everything you say in that post.

You're not interviewing the candidate about their skills, knowledge, how they code and attack problems, their culture fit etc. Instead you've created an artificial list of questions about what you 'use daily' and what you know (and what you believe a senior should know), and are testing them against that.

Tomorrow you could go for an interview with another company's developer that uses different technology and implementation/coding styles, and you'll only be able to answer a few of his questions...and subsequently fail.

Take your value vs reference type question. Is it important for 99% of developers to know if data is being stored on the stack or heap? Does it matter to them whether there's a difference between structs/classes for the two?

Your question on thread safety is a lot better, because it can be a discussion between the interviewer and interviewee, and you can determine what they know about threaded coding, projects they've used it, where/when they'd implement it etc.

 

[Hamster]

I disagree with almost everything you say in that post.

You're not interviewing the candidate about their skills, knowledge, how they code and attack problems, their culture fit etc. Instead you've created an artificial list of questions about what you 'use daily' and what you know (and what you believe a senior should know), and are testing them against that.

Tomorrow you could go for an interview with another company's developer that uses different technology and implementation/coding styles, and you'll only be able to answer a few of his questions...and subsequently fail.

Take your value vs reference type question. Is it important for 99% of developers to know if data is being stored on the stack or heap? Does it matter to them whether there's a difference between structs/classes for the two?

Your question on thread safety is a lot better, because it can be a discussion between the interviewer and interviewee, and you can determine what they know about threaded coding, projects they've used it, where/when they'd implement it etc.

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

 

[ArtyLoop]

So then what about pass-by-value vs pass-by-reference, and you can answer that in many ways, all of them valid answers!!

 

[rorz0r]

If you tell me you are a senior C# developer and you cannot tell me whether the static constructor or instance constructor executes first or what a sealed class is

Hehe, that reminds me...

"What is an abstract class?"
"It's um, when err, you can't make a new class that uses that class".
"Ok... so then let me ask you, what is a sealed class?" (I live in hope)
Sadly I can't remember the response now, but it was something else...

Totally agree with your post. Knowledge of the theory and the "why" is extremely relevant, and particularly so as a "senior" dev. As a senior dev you should be able to comfortably make decisions as to the design of certain aspects of a system, and should therefore have an in depth understanding of what it is that you're doing. Sometimes this understanding is gained from lots of experience (and sometimes a little, but a lot of dedication), and sometimes people copy and paste, google/stackoverflow, etc for 10+ years and the end result is something that "works" but is buggy as hell, a huge mess etc. That's why we go through this in the interview process, to establish if your contribution would be a positive one, or a negative one where you create more stuff to "fix" than you actually contribute positively. I'd rather have a junior who's sharp, learns quickly and has a good attitude than someone who's "senior" but is stuck in incorrect ways and has to be told not to do something multiple times.

 

[cguy]

I senior developer should be able to me what the difference between value and reference types are, talk to me about thread safety etc.

If you tell me you are a senior C# developer and you cannot tell me whether the static constructor or instance constructor executes first or what a sealed class is, or
if you are senior Java developer and you don't know the super class' constructor will be called implicitly by the subclass,
or
inner join vs left join, pros and cons of an index on a database table

In fact, just last week I had a guy with 10+ years experience tell me he can't give me textbook answers when I asked him the difference between value and reference types. I didn't even bother asking him if he knew what a stackoverflow exception is.

Point is, if you consider yourself a senior developer and you cannot answer questions like the above or at least try and get close then what type of senior developer are you really? A Visual Studio Developer? All those questions are relevant in your daily coding life. There's nothing "text book" about them.

No offence to anybody here but the struggle to find people worth the money they ask is real.

I'm inclined to agree - there are some basic questions that can tell you if the person has actually done any form of "design", or has any idea of how things work "under the hood" in their language. Both of these being important to producing good code, so it separates those people doing more advanced coding vs. those who are "senior" because they may have some expert domain knowledge (or have warmed a chair long enough), but still have beginner level coding ability.

 

[cguy]

So then what about pass-by-value vs pass-by-reference, and you can answer that in many ways, all of them valid answers!!

How is this ambiguous?

 

[cguy]

I have been in the situation where I've been asked these things and showed them how to do it in code and why. But because it wasn't the university answer.. boom... no latte for you.

I've seen this statement a few times before, and although I don't know what your specific case was, the cases that I saw thought that their answer was correct but the "non-textbook" answer, but it was actually just completely wrong. I don't think that these questions are particular subjective - if they are that's a problem with the interview process.

I came from the low level C foundation... and I worked on C++ code where the whole purpose of OOP was a moot point. They created classes by the bucketful, only to override MOST of them not to mention the things they were inheriting from the classes, and we had to live with the bloat of it and poor performance until I ported all that shyte to a more modern language.

So clearly OOP is a double-edged sword and I avoid it where I can. Because if you go down that rabbit hole you can confuse the shyte out of yourself for years. Kind of explains the plethora of crap software we've seen at specific times during the years.

That sounds a lot more like an issue with the developers you were working with than the language. I've seen the "you get a class, and you get class", Oprah anti-pattern before, but this is very much due to having a group of developers who know the syntax, but none of who know anything about software engineering. BTW, OOP can be used in C as well.

 

[cguy]

point taken.

I just find it strange the people who code for their daily job and seem to be doing well, but can't answer theory questions

Sometimes people do the same repetitive work every day. Also, sometimes they obtain advanced domain specific knowledge that legitimately makes them important and "senior" to their company, but they still only have very basic software development abilities and would effectively be at junior level if moved to any other domain.

 

[ArtyLoop]

Lots of ego in this thread... no need to comment further. Apparently I suck at coding (yet my code is being used by others all over)

 

[[)roi(]]

I leave my two cents for what its worth:

• if the understanding of terminology and abstractions were at all truly trivial, then pray tell how do developers actually convey meaningful ideas without these.
• As for the peacocking; isn't that what all these thread categories inevitably evolve into.

 

[cguy]

Lots of ego in this thread... no need to comment further. Apparently I suck at coding (yet my code is being used by others all over)

It is amusing when the guy who thinks that one of the most fundamental and dominant software technologies of the current (and previous) era (OOP) is “academic bullshyte”, is the one to complain about ego.

 

[[)roi(]]

It is amusing when the guy who thinks that one of the most fundamental and dominant software technologies of the current (and previous) era (OOP) is “academic bullshyte”, is the one to complain about ego.

It's not a 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
• ...

Side note:
Plus let's not forget much of OOP today is so because of of flaws in OOP of yesteryears, similarly OOP as Alan Kay intended is not what OOP is today and as much as some OOP programmers are anti other paradigms including FP it's certainly not a sentiment shared by OOP's creator.